It's okay to go slow at first. You have to walk before you can run.
Even though you have experience in the domain, don't rush in and start trying to change everything, first understand why it is the way it is.
Gain your engineers' trust through active listening, kindness, empathy, and engagement on critical topics. Don't be afraid to say "let me do that for you" in the early days. It's both a learning opportunity and a trust building technique.
Meet every stakeholder and peer you can. Ask them about themselves, the company, and their perspective on the opportunities for your product. Set up regular 1:1s with key stakeholders.
Understand what your teams and your mgmt wants from you. They may conflict. If they do, see if you can figure out a way to address both needs. If you can't, you'll need to figure out a way to manage one group's needs while meeting the other's.
Ask for feedback from the engineers you work with and your peers, especially on your first couple of initiatives but I find it's worth doing all the time. If you don't get any meaningful feedback just assume you've done a good job and keep going.
When you use a product for the first time, write down your feedback as you go through it. Identify what you think is confusing or frustrating, but also what you think it working well. Take screenshots or videos as necessary to further illustrate your perspective. Most of the people who work on the product already have probably internalized these faults and no longer see them the way you will with fresh eyes. Discuss your findings with the team.
You'll want to speak with as many customers/users as possible, but unless you're already an expert in the product, not right away. Gain basic competency in the product, develop a hypothesis about what you think needs to be done, and then go speak to users. You'll quickly find out if you're on the right or wrong path.
One thing I've learned is that many founders actually suck at talking to users in a way that gives them actionable information. If that's you, and perhaps why you're not a founder any more (not saying this is you), then quickly learn how to do interviews well. There are plenty of books and videos on this topic.
Celebrate your team's wins and understand that you are there to help your teams win, not the other way around.
Understand that PMs are judged on outcomes not inputs. No body cares if you worked really hard on something or if you cruised into it. The results will speak for you.
Be prepared to say "no" a lot. That's one of the primary jobs of a PM, but be wary of saying it a lot right away. If you're unsure of something in the early days get council from your team or mgmt.
Your teams want you in the problem space, not the solution space. Unless you have some keen insight on a solution or are part of a solution brainstorming session, don't tread into the engineer's domain. Conversely though, embrace engineers that want to get a deeper understanding of the problem space.
Look for leverage points. That is, look for opportunities with low effort and high impact. I've been able to make seemingly big strides in a product early on just by identifying the right leverage points.
I can keep going but I'll stop for now. I hope this helps you on your journey. Best of luck!