Head of Product First 90 Days: Observe, Assess, Learn

What should a head of product do in the first 90 days?

A new head of product has three jobs in the first three months: point the product org in the right direction, make sure the right people are on it, and remove whatever stops them shipping. Gibson Biddle, former VP of Product at Netflix and Chief Product Officer at Chegg, uses a cannon to describe it in his Ask Gib essay on the first 90 days: "Is it pointed in the right direction? Does it have the right people to load and fire it? Are there enough cannonballs and gunpowder for rapid-fire blasts?"

The pace is the hard part. "If I work too quickly, I'll get some things wrong. If I act too slowly, I lose my ability to inspire change," Biddle writes. People expect change from a new leader in the first weeks and resist it later, so the 90 days are a window, not a grace period.

The plan below splits that window into observe (weeks 1 and 2), assess (weeks 3 to 6) and act (weeks 7 to 13), with the specific outputs each phase should produce.

How is a head of product plan different from a new PM's 90-day plan?

A new product manager's plan is about learning one product area and earning trust with one team. The first 90 days plan for a new PM and the first 90 days PM template cover that version well.

A head of product inherits several teams, a set of C-level peers, a CEO with expectations, and usually a few people problems nobody has resolved. Three things change:

Dimension	New PM	New head of product
What you learn first	One product area and its users	The whole org: people, strategy, history, politics
Who you align with	Your manager and one squad	The CEO, every C-level peer, engineering leadership
What "early win" means	A small shipped improvement	A visible decision that changes how the org works
Hardest call by day 90	What to prioritise next	Whether each report is right for their role

If you have just moved up from senior PM, the head of product vs product manager guide covers the shift in more detail.

What should you do in the first two weeks?

Sriram Krishnan's playbook for a new executive in First 30 days is the most direct version of this phase: "Spend your first two weeks doing only 1:1 meetings and being a quiet observer in team meetings." In each 1:1 he asks the person how they fit into the org, the three things going well and the three that need fixing, and a couple of names of people you should meet next.

Write up each conversation the same day. After a dozen or so of them, themes repeat: the same project described as stuck by three different people, the same quiet analyst praised by everyone. Krishnan's target is a list of three things the org needs to change and three it should double down on, within two weeks.

Two habits from the same piece are worth starting on day one:

• A weekly written update to the whole org, same day, same format, covering who you met and what you are noticing. It builds trust faster than any all-hands.
• Frequent check-ins with your own manager. "Most new exec failures are because there's no early alignment," Krishnan writes. Agree on what success in your job looks like before you agree on anything else.

How do you diagnose what is slowing the product org down?

Biddle names four reasons a product org ships slowly: lack of focus, lack of resources, lack of tools (such as data or A/B test systems), and lack of management systems (how teams work together, share learnings and make decisions). Each one has a different first move, so sorting what you heard in weeks 1 and 2 into these four buckets is the core of the assess phase.

Cause	What you hear in 1:1s	First move
Focus	"Everything is priority one." Teams cannot name the company's top goal.	Draft a rough product strategy and test it in 1:1s
Resources	Critical work waits for one overloaded engineer or designer	Re-scope, move people, or open hires
Tools	Nobody trusts the dashboard; experiments are run by hand	Fund the data or experimentation fix before new features
Management systems	Decisions get reopened; teams learn nothing from each other	Set up a regular strategy review and a decision log

Consider a hypothetical: you join a B2B invoicing company with four product teams. Every PM tells you the roadmap changes weekly, and two of them blame sales requests. That sounds like a focus problem, but the sales VP tells you the product team never explains why deals are lost to missing features. The real cause is a missing management system: there is no forum where sales evidence and product priorities meet. A new strategy document would not fix it; a monthly review with sales in the room would.

What should you know about the org by day 30?

By the end of the first month, you should be able to answer five questions without looking anything up. Any you cannot answer tell you where to spend the next two weeks:

1. Customers. Which customers matter most to the business, and what did the last few you spoke to (or watched use the product) struggle with?
2. People. For each report, what are they best at, what do they want next, and are they in the right seat?
3. Power and process. Who actually makes product decisions today, and which decisions keep getting reopened?
4. Numbers. Which metrics does the leadership team trust, and which ones start arguments?
5. Past bets. What did the company try before and abandon, and why? Old failures explain a lot of current resistance to new ideas.

What does a stakeholder map look like for a new head of product?

Every C-level peer judges product through their own targets, so the fastest way to earn trust is to know those targets before the first meeting. The table below is a starting hypothesis to confirm in each 1:1, not a rule; titles and priorities vary by company.

Peer	Likely measured on	What they usually need from product
CEO	Growth, fundraising milestones, board confidence	A strategy they can explain to the board, and no surprises
Engineering leader	Delivery predictability, system health, team retention	Clear priorities, stable scope, time for technical debt
Sales or revenue leader	Pipeline, win rate, expansion revenue	A credible roadmap story for prospects, and a way to feed deal evidence in
Marketing leader	Acquisition cost, conversion, launch impact	Launch dates they can plan around, and positioning input early
Finance leader	Budget against plan, return on investment	A business case for large bets, and honest forecasts
Operations or support leader	Ticket volume, resolution time, customer satisfaction	Fixes for the issues that drive the most tickets

Ask each peer the same question at the end of the 1:1: "What would product have to do this quarter for you to call it a good quarter?" The answers become the raw material for your strategy draft and show where peers' goals conflict. The stakeholder management glossary entry covers the day-to-day techniques.

Which changes should you make early, and which should wait?

Make the obvious people changes early. Krishnan argues that people expect a new leader to act on them with a fresh slate, and that the org "will judge your standards if you don't." Biddle goes further: by the end of his first three months he has told each report whether he plans to upgrade their role. He notes that most heads of product put those conversations off, and he acts early so the right team is in place by the end of his first year.

Pick one early win that people can see. It should be small enough to finish within a few weeks and visible enough that the team sees how you work: unblocking a stuck launch, resolving a long-running dispute between two teams, or personally handling a customer escalation.

Wait on anything that is not obvious. Reorganising teams, rewriting the roadmap from scratch, or replacing the planning process before you understand why it exists tends to confirm the org's fear that the new leader is running a copied playbook. Biddle is explicit on this point: "I'm also careful not to apply a playbook from my last job."

What does a week-by-week plan look like?

Weeks	Phase	Outputs
1 to 2	Observe	1:1s with every report, peer and key IC; first weekly update sent; success criteria agreed with your manager
3 to 6	Assess	Diagnosis sorted into focus, resources, tools and management systems; stakeholder map confirmed; rough strategy tested in 1:1s
7 to 10	Act	Early win delivered; obvious people decisions made; one operating ritual introduced (strategy review, decision log or planning cycle)
11 to 13	Consolidate	Strategy shared with the company; hiring plan agreed; a written 90-day review sent to your manager and the org

Treat the week numbers as a default. In a company in crisis, the assess phase may shrink to a week; in a stable, well-run org it can stretch.

What is the strongest argument against moving fast?

The case for patience is real: a new leader who acts in week three acts on the loudest voices, not the full picture, and a wrong people decision early is expensive to reverse. That is why the plan above keeps the first two weeks free of decisions and separates obvious changes from judgement calls.

The case against waiting is stronger, though. Biddle's point that people resist change once a leader has been there a while means the cost of delay compounds. The answer is sequencing, not speed: listen fully, decide the obvious things quickly, and put the non-obvious ones behind evidence you collect on purpose.

How can you prepare for the role before you start?

The Head of Product bootcamp is a 2-week programme in the Product Leadership Track, with 4 live sessions and 8 self-paced microlessons, directed by Andre Albuquerque. Its public curriculum covers product vision, strategy and portfolio thinking, roadmap governance, stakeholder management, building and leading product teams, and operating cadence. The head of product leadership week challenge puts you in the seat for five days where each decision shapes the next. Once your team is in place, the product manager performance review template covers the first review cycle.

Builders Camp runs live and self-paced bootcamps in product management and AI product building. See the Head of Product bootcamp for the next cohort and the self-paced version.