The first 90 days as a new PM are a minefield. You're new, you want to prove yourself, you have ideas, and you have just enough context to be dangerous. The temptation is to start changing things immediately. The right move is almost always to slow down.
I've started at two companies now. The first time I got this badly wrong. The second time I got it mostly right.
What I got wrong the first time
I joined a team that had been working on a product for two years. I came in with fresh eyes, saw things that looked like problems, and started proposing solutions in my second week. Some of my observations were correct. My solutions were almost all wrong, because I didn't understand why things were the way they were.
Here's a specific example. The team had a manual review step in their seller onboarding flow - a human had to approve each new seller before they could list products. It looked like obvious technical debt. I proposed automating it with a rule-based system. The engineers looked at me like I'd suggested something dangerous, which I had. What I didn't know: the manual review step existed because automated onboarding had been tried before and resulted in a wave of fraudulent sellers that took months to clean up. The "inefficient" manual step was load-bearing. It was doing real work that wasn't visible in the code.
There's always a reason things are the way they are. Sometimes the reason is bad - actual technical debt, a decision made by someone who left, organizational dysfunction. But often the reason is good: a constraint you don't know about, a tradeoff that was made deliberately, a failure mode that was discovered the hard way. When you propose changes without understanding the reasons, you break things that were working and create problems you didn't anticipate.
The engineers on that team were patient with me. They explained why my proposals wouldn't work. I learned, eventually. But I wasted weeks of everyone's time and started my tenure with a credibility deficit that took months to recover from.
What I did differently the second time
I spent the first month listening. Not passive listening - structured listening with a specific set of questions I wanted to answer before I touched anything.
The most useful question I asked engineers: "What decisions has this product made that I should understand before I propose any changes?" This is different from "what's wrong with the product?" It signals that you understand there are reasons behind things, and it gets you the institutional knowledge that isn't written down anywhere. Engineers know where the bodies are buried. They know which parts of the codebase are fragile, which architectural decisions were compromises, which features are held together with duct tape. If you ask, they'll tell you.
I also asked: "What did the previous PM do that made your job harder?" This is uncomfortable to ask, but the answers are invaluable. Engineers have clear opinions about what makes a PM good or bad. Vague specs that require multiple rounds of clarification. Changing requirements mid-sprint without understanding the cost. Not understanding the difference between a synchronous API call and an async job, and therefore writing specs that assume instant responses for operations that take seconds. Asking early signals that you care about their experience, and the answers give you a roadmap for what not to do.
I spent time reading support tickets, not to validate ideas I already had, but to understand what was actually breaking for users. Support tickets are underrated as a discovery tool. They're specific, they're real, and they show you the failure modes that users actually hit - not the ones you'd predict from looking at the product.
The 30-60-90 structure
First 30 days: learn everything. Don't propose changes. Don't have opinions in public. Ask questions, take notes, build relationships. The goal is to understand the system - the product, the team, the users, the technical constraints - well enough to know what you don't know.
Days 31-60: start forming hypotheses. Share them as questions, not proposals. "I've noticed that our order cancellation rate spikes on weekends - is that something the team has looked into?" is different from "we should fix the cancellation rate." The first invites collaboration. The second invites defensiveness, especially if there's already a known reason for the pattern that you're not aware of.
Days 61-90: start proposing. By now you have enough context to know what you don't know, which is the most important thing. Your proposals will be better because they're informed by the reasons things are the way they are. You'll also have built enough trust that when you do push back on something, people will take it seriously rather than dismissing it as a new person not understanding the situation.
The credibility thing
New PMs often feel pressure to prove themselves quickly. The instinct is to ship something, change something, make a visible impact. This is understandable and usually counterproductive.
Credibility in a new role comes from being right, not from being fast. If you make a change in week two and it works, you get some credit. If you make a change in week two and it breaks something - or worse, if it breaks something three months later because you didn't understand the downstream effects - you've damaged your credibility in a way that takes a long time to repair.
The PMs who build credibility fastest are the ones who ask good questions, listen carefully, and make their first few moves count. Patience in the first 90 days pays off for the next two years. The engineers who've seen a dozen PMs come through can tell within the first month whether you're going to be someone they trust or someone they have to work around. Make it easy for them to trust you.