Onboarding a PM in 90 days:
the plan to write before you sign

Every time a company hires its first Product Manager, it spends weeks finding the right profile, runs five interviews, negotiates the package, then leaves them alone on the first Monday with a Slack login and a cheerful "good luck". The hiring was careful; the arrival, improvised.

That is the most expensive mistake, because it is invisible. A bad hire shows within a month. A good hire sabotaged by a bad onboarding takes six months to show, and when it shows, everyone concludes they picked the wrong person.

They did not pick the wrong person. They skipped the plan.

I have already described how to hire that first PM: the profile, the eighteen questions, the signals that make you hire fast. But hiring is only half the work. The other half is a ninety-day plan you should write before you sign, not improvise once the person has arrived. Here is the one I use.

1. Why is a PM's onboarding decided before day one?

Because the trust a PM needs is won or lost in their first few weeks, on the basis of tiny signals. A developer you onboard badly loses time; a PM you onboard badly loses their legitimacy. The difference comes from the nature of the role: a PM has almost no formal authority. They move forward because the organisation trusts them to make the calls, not because an org chart grants them the right.

The trap is that those signals are sent by the organisation well before the PM arrives. If nobody has decided who they report to, which three topics actually matter, and who will protect them while they learn, then no personal quality will make up for that void. They will spend their first weeks looking for their place instead of understanding the product.

Hence the rule I apply: a PM's onboarding is not a document you write in the first week, it is a decision you make before you make the offer. If you cannot write the plan for the first ninety days, you are not yet ready to hire.

A bad hire shows within a month. A good hire badly onboarded takes six months to show, and it is always blamed on the wrong person.

2. The three milestones: observe, propose, deliver

The plan fits in one sentence, and I keep it deliberately simple so it survives contact with reality: the first thirty days to observe, the next thirty to propose, the last thirty to deliver a first measurable result.

This split is not a magic formula, it is a contract of patience between the PM and the organisation. It tells the PM: you are allowed to deliver nothing for a month, your job is to understand. And it tells the organisation: do not ask them for results before they have understood, or you force them to guess.

Most failures come from inverting this rhythm. The PM is put on a roadmap to hit from the second week, before they have spoken to a single user. They then deliver fast, and they deliver the wrong thing, because a PM who produces before understanding is only giving a professional shape to the assumptions of the people who hired them.

The three sections that follow unpack each milestone. But none of the three holds if the work before day one has not been done.

3. Before day one: the four accesses that decide everything

There are four things to lock down before the PM walks through the door. None of them depends on them; all of them depend on you. They are what makes a good PM succeed or burn out.

• A named sponsor in the leadership. Someone, ideally a founder or an executive, who said yes to this hire and who will protect the PM while they learn. Without a sponsor, the first prioritisation conflict is settled against the PM, and their legitimacy collapses.
• Operational data access from day one. Not "we will give you the access later": the dashboards, the analytics, the customer feedback, the support queue. A PM who has to go through three people to get a number will never decide on facts.
• A written scope, even an imperfect one. What they own, what they do not, and who decides when it is unclear. A fuzzy scope is not freedom offered to the PM, it is a zone of daily friction with everyone else on the team.
• A direct path to users. The names of five customers they can call in the first week, without asking for permission. It is the rarest and most valuable resource, and it is almost always the one nobody prepared.

If you cannot assemble these four accesses, the problem is not the PM: it is that the organisation is not ready to welcome one. Better to know that before you sign than three months in.

4. Days 1 to 30: observe without promising anything

The first month has a single objective, and it is counter-intuitive for everyone: understand, without delivering. It is the hardest phase to hold, because the PM wants to prove their worth and the organisation wants a return on its investment. Both are wrong at the same moment.

What a good PM does during those thirty days looks a lot like a product audit run from the inside: they listen, they map, they note the gaps between what people say and what the data shows. They talk to developers, to support, to sales, and above all to users. They propose nothing yet, because a proposal made too early is just an opinion in disguise.

A few non-negotiable rules for this phase:

• Talk to ten users before touching the backlog. Not personas, real people on the phone. It is the only way not to inherit the certainties of the team already in place.
• Write down what you observe, not what you plan to do. A beginner's notebook beats a premature roadmap: it keeps a record of the fresh eye, which disappears within a few weeks.
• Resist the first "urgent" request. There will be one from the second week. Giving in means accepting the role of an executor; declining it cleanly establishes that you make the calls on facts.

The organisation's role here is simple: hold the line. Do not judge the PM on their short-term productivity when their real work is to build an understanding that nobody else has yet.

5. Days 31 to 60: propose, and own the trade-offs

By the second month, the PM has understood enough to propose. This is when they move from observer to actor, and when their first real competence becomes visible: prioritisation. Not the ability to produce a long list, but the ability to defend a small number of bets and to refuse the rest without making enemies.

What I ask of a PM at this stage is not a twelve-month roadmap. It is a short note, two pages at most, that says: here is what I have understood, here are the three problems worth tackling, here is the one I propose to address first and why. That note is the PM's first real deliverable, and it is what turns their observation into a decision.

This is also the phase where their relationship with the developers is decided. A PM who arrives imposing processes burns out their credit; a PM who arrives asking "what is stopping you from moving forward today?" and fixes one concrete irritant within a fortnight earns a trust worth more than any org chart. A PM's legitimacy is not declared, it is observed.

6. Days 61 to 90: deliver a first measurable result

The third month is there to prove, through a fact and not a speech, that the PM changes something. The trap here is the mirror image of the first: after two months of patience, the temptation is to aim big to make an impression. That is a mistake. The first result must be small, chosen to be achievable in thirty days, and measurable without ambiguity.

Small does not mean unimportant. A good first result has three properties: it solves a problem users genuinely feel, it is deliverable within the window, and its effect shows up in a number everyone understands. Cutting the back-and-forth on a sign-up step, shortening a journey that was driving customers away, unblocking a feature that had been waiting for months for a decision: it does not matter, as long as it is clear-cut.

That first result is not really there to improve the product, even though it does. Its purpose is to install a loop: the PM observes, proposes, delivers, measures, then starts again. Once that loop is visible, the organisation stops wondering whether the hire was the right one. It has the proof in front of it.

7. The mistakes that kill a good PM, and how to avoid them

Most failed onboardings are not the PM's fault. They are the fault of organisational patterns that recur so often you can list them. Here they are, with their antidote.

• Putting them on a roadmap from week two. That is demanding a decision before understanding. Antidote: protect the observation phase as a deliverable in its own right.
• Leaving them without a sponsor. At the first contested trade-off, a PM with no protector loses, and an early defeat is very hard to recover from. Antidote: name the sponsor before the arrival, not after the first conflict.
• Judging them on their activity. Counting their tickets or their meetings measures the noise, not the work. Antidote: agree from the start that the outcome of the ninety days is a loop that runs, not a volume produced.
• Confusing a PM with a project manager. If you expect them to execute decisions made elsewhere, you hired an executor and wasted a PM. Antidote: leave them the "what" and the "why", not just the "when".
• Not preparing the handover from whoever held the role before. Often a founder wore the product hat. If they let go of nothing, the PM stays an assistant. Antidote: decide explicitly what the founder delegates, and stick to it.

Each of these mistakes has the same root: treating onboarding as an administrative formality rather than as the second half of a hiring decision. The ninety-day plan is precisely what stops you from falling back into it.

What really matters here

Hiring a PM and onboarding them are two halves of the same decision. The first is prepared with interviews; the second, with a plan written before you sign. Without that plan, even the right candidate fails, and the organisation draws the wrong lesson.

• Write the plan before the offer: if you cannot describe the first ninety days, you are not ready to hire.
• Lock down the four accesses: a named sponsor, data from day one, a written scope, a direct path to users.
• Hold the observe, propose, deliver rhythm: thirty days to understand, thirty to propose, thirty for a first measurable result.
• Protect the observation phase: a PM who delivers before understanding quickly delivers the wrong thing.
• Aim small for the first result: the point is not the feat, it is installing a visible loop.

A good onboarding does not make a mediocre PM good. But a bad onboarding makes a good PM invisible, then suspect, then gone. The ninety-day plan costs an afternoon to write. Not writing it costs six months and a hire.

Further reading

• Hiring your first PM: the 18-question grid, the first half of the decision: how to choose the person this plan will onboard.
• Why your product audit changes nothing (and how to fix that), because a PM's first thirty days are an audit run from the inside.
• How to say no to a feature request (and write the refusal), the method to hand over to the PM before their first trade-offs.

In the organisations I work with, a PM's arrival almost always goes well when the plan exists, and almost always badly when it is improvised. It is not a matter of individual talent, it is a matter of collective preparation. Co-building this plan, scoping the four accesses and securing the first ninety days is exactly the kind of short consulting engagement that prevents a long mistake, and you can read what the teams I have supported say about it.