The first 30 days as an interim Head of Product

2 min read

What I actually do in month one — before touching the roadmap, before reorganising anyone, and before anybody asks me for a strategy deck.

Every interim engagement starts the same way: someone hands me a roadmap and asks what I’d cut. That’s the wrong first question. A roadmap is a symptom — it tells you what a team decided six months ago, under pressure, with information they no longer have.

So month one isn’t about the roadmap. It’s about finding out how decisions actually get made here. That diagnosis is most of what the first thirty days of an interim engagement are for.

Week 1 — Listen, and write everything down

I book 30 minutes with everyone who touches the product: engineers, designers, support, sales, the two people who’ve been there longest. Same three questions every time:

  • What’s the last thing we shipped that you were proud of?
  • What’s the last thing we shipped that you thought was a mistake?
  • If you could delete one meeting, which one?

The third question tells you more about the operating model than any org chart. By Friday I have a document nobody else in the company has: the same story from twelve angles, with the contradictions left in.

Week 2 — Follow one decision end to end

I pick a feature that shipped in the last quarter and trace it backwards. Who asked for it? What evidence did they have? Who could have said no, and did anyone try?

This is where the real problem usually surfaces. A common answer is that nobody could say no — every request from a named enterprise customer went straight into the sprint. The roadmap wasn’t badly prioritised; there was no prioritisation step at all. Cutting items would have fixed nothing, and neither would a better prioritisation framework, which is the usual first suggestion.

Week 3 — Ship something small

Credibility in a product role is not granted by a title. I find something that’s been stuck for structural rather than technical reasons — an onboarding step nobody owns, a pricing page that contradicts the docs — and get it shipped.

It matters less what it is than that it demonstrates the thing I’m asking the team to do: decide, ship, look at the result.

Week 4 — Write the one-pager

Only now do I put anything on paper. One page:

  1. What we’re optimising for this quarter, in a single sentence.
  2. The three bets, each with the evidence behind it and what would make us stop.
  3. What we’re explicitly not doing, with names attached so it doesn’t creep back.

If it doesn’t fit on a page, I don’t understand the business well enough yet, and another week of listening is cheaper than a quarter spent on the wrong bet.

The pattern underneath all of this: diagnose the decision-making before you change the decisions. Teams rarely fail because they picked the wrong feature. They fail because nobody could tell you why that feature was picked.