What should a product manager do in their first 90 days?

Days 1-30: learn, and resist proposing

Talk to customers. Ten conversations in the first month. Not demos — ask about their work and where the product fails them.

Read support tickets. A few hundred. It is the least glamorous and highest-yield activity available, and it will contradict at least one thing you were told in onboarding.

Use the product as a customer. Sign up fresh, pay if you can, go through the whole flow. Note every point of friction, because in three months you will have stopped noticing them.

Learn how decisions actually get made. Not the documented process — the real one. Who has to be convinced, what evidence moves them, where things quietly die.

Read the graveyard. Ask what has been tried and abandoned, and why. This is the single best defence against proposing something that failed for a reason still true.

Days 31-60: one small useful thing

Pick something small, visible and genuinely useful, and ship it. Not a strategic initiative — a fix, a clarification, a piece of friction removed.

The purpose is credibility. You want the team's first experience of you to be that things get slightly better, not that there is a new person with opinions. This is also where you learn how the machine actually works: how long a change really takes, where it gets stuck, who has to sign off.

Choose something the engineers already wanted to do. You get the win and they get the thing they have been asking for.

Days 61-90: form a view and say it

Now you have earned the right to a direction. Write it down: what you believe the biggest opportunity is, what evidence you have, what you would stop doing to pursue it.

Include the second part. A proposal that only adds is not a strategy, and the willingness to name what you would drop is what distinguishes a plan from a wish.

Then socialise it before presenting it. The people who will have to support it should have seen it and had a chance to argue with it in private first.

The mistakes that cost the most

Arriving with the answer. Every product has obvious improvements that were tried. Digg's v4 is the cautionary tale about changing something users depended on without understanding why it was as it was.

Ignoring the graveyard. Repeating a failed initiative with fresh enthusiasm is the fastest way to spend all your credibility at once.

Overcorrecting into pure listening. Ninety days of learning with nothing shipped reads as passivity. The small win in month two exists to prevent this.

Rewriting process first. New PMs often reach for rituals because process is the thing you can change without domain knowledge. It is also the change teams resent most from someone who has not yet been useful.