How do you set product vision and strategy across multiple product lines?

I start with the company's overall strategy and work out where each product line fits: which ones are the growth engine, which ones defend an existing revenue base, and which ones are bets we are still validating. That framing changes what good looks like for each line, so I am not applying the same growth expectations to a mature line and a two-year-old one. I run a structured planning cycle twice a year with each product line lead, where we agree a one-page strategy covering the target market, the metric that matters most, and the trade-offs we are explicitly choosing not to make. I then stress-test those against each other for resourcing conflicts before anything goes to the CEO. At my last company this process surfaced that two lines were both quietly building similar workflow automation, so we consolidated the effort into a shared platform capability rather than duplicating engineering spend, which freed up roughly four engineer-months a quarter.

How do you structure a product organisation as it grows, and how do you decide how many PMs you need?

I size the team against the surface area of problems worth solving, not against a fixed ratio to engineers, though I do use engineer-to-PM ratio as a sanity check once the team passes a certain size. I group PMs around coherent user or business problems rather than around individual features, because feature-level ownership fragments too quickly as the product grows and creates constant re-org churn. When I inherited a nine-PM team organised around individual features with no clear owner above them, I regrouped into three pods, each owning a full customer journey with a lead PM accountable for that pod's outcomes, and reporting to me. That gave me three people I could develop into product leaders rather than nine direct reports I could barely coach properly. I revisit the structure roughly once a year, tied to the strategy planning cycle, rather than reorganising reactively every time a new priority appears.

How do you report product strategy and results to the CEO and the board?

I bring the board a small number of things every cycle: progress against the strategic bets we agreed last time, the health metrics for the product portfolio as a whole, and one clear ask, whether that is budget, a hiring decision, or a trade-off I need air cover on. I avoid walking the board through feature-level detail, because that is not the altitude they operate at and it buries the decision they actually need to make. I am direct about what is not working. When a board member asked why a major initiative was six months behind its original plan, I walked through the specific resourcing decision that caused the delay and what we changed as a result, rather than reframing the delay as a scope change after the fact. That kind of transparency is what earns the trust to get investment approved the next time I ask for something significant.

How do you decide whether to build, buy, or partner for a new capability?

I start with how differentiating the capability actually is for us commercially, not how interesting it is to build. If a capability is not something customers choose us for, I default to buy or partner unless the cost of integration and ongoing vendor risk outweighs the build cost, which I model over a three-year horizon rather than just the first year. I involve engineering leadership and finance in this decision early, because build costs are almost always underestimated on the product side and the true cost includes the ongoing maintenance burden, not just the initial sprint estimate. When we needed fraud detection capability, I ran a structured evaluation against three vendors and an internal build estimate, and chose to partner despite an internal team wanting to build it, because the vendor's model was trained on a dataset we could never replicate internally and the switching cost if we chose wrong was low. Eighteen months later that decision freed an entire pod to work on a differentiating feature instead.

Tell me about a time you had to kill or deprioritise a product line despite internal resistance.

We had a product line that had been a founder's original vision for the company and still had a small, vocal group of internal champions, but it had flatlined at under 5% of revenue for two years while consuming close to 20% of engineering capacity. I built the case slowly rather than announcing a decision: I pulled the unit economics, interviewed the handful of customers who still relied on it, and modelled what that engineering capacity could do if redirected to our two growth lines. I presented the analysis to the founder privately before any wider conversation, because I wanted him to hear the reasoning directly from me rather than through a general announcement. We agreed to sunset new investment, support existing customers through their contract terms, and redeploy the team over two quarters rather than overnight. It was not a clean or fast decision, but revenue on the two lines that received the freed capacity grew 30% over the following year, and the founder later told me he respected that I brought him the case before the decision was final rather than after.

Describe a time you had conflict with sales or engineering leadership over product strategy.

Sales leadership wanted us to commit to a set of custom features for one large prospective account, arguing it would close a deal worth a significant chunk of the quarter's target. I pushed back because those features did not serve any other customer segment and would have consumed a quarter of our platform team's capacity. Rather than simply saying no, I asked sales to bring me the actual contract value and probability of close, and I modelled what saying yes would cost us against our committed roadmap for the rest of the base. We agreed a smaller subset of the request that also had broader applicability, and sales accepted a longer sales cycle on that account rather than the full custom build. The deal closed four months later than sales originally wanted, but the compromise features shipped to the whole customer base and were adopted by 40% of accounts within two quarters, which sales later cited as helping close two other deals I had not anticipated.

Tell me about a time you had to coach an underperforming PM on your team, or make a difficult call about their fit.

I had a PM who was strong analytically but consistently struggled to bring engineering and design along with her; her specs were technically sound but she was making unilateral calls that left both teams feeling unheard, and adoption of her features lagged as a result. I gave her direct, specific feedback tied to actual incidents rather than a general impression, and we agreed a 90-day plan with concrete behaviours to change, including having her co-write the next two specs with her lead engineer rather than alone. I checked in every two weeks rather than waiting for the plan's end date, because I wanted to catch drift early. She made real progress on the collaborative process but the underlying pattern of unilateral decisions on high-stakes calls persisted, so at the end of the 90 days I made the call to move her to an individual contributor track on a smaller, lower-stakes product area rather than continuing to manage a team, which she initially found difficult but later told me was the right call for her career.

How do you make resourcing trade-offs when engineering capacity is constrained across competing product priorities?

I treat engineering capacity as a single shared pool I am allocating against the whole portfolio, not a set of fixed teams each product line owner can claim as their own. Every quarter I run a forced-ranking exercise across the product line leads, where each brings their top asks with an explicit estimate of engineering weeks required and the expected outcome if funded. I then make the allocation call myself rather than letting it default to whoever argues loudest, because that is the actual job. I protect a fixed percentage, usually around 15%, for platform and technical debt work regardless of the product pressure in a given quarter, because I have seen what happens two years later when that gets deprioritised every single cycle. When two lines both needed the same specialised engineering skillset last year, I brought both leads and the engineering director into one room to negotiate a staggered sequence rather than each pushing an isolated case to me separately, which surfaced a dependency neither had flagged on their own.

How do you balance near-term roadmap delivery against longer-term platform investment?

I hold both budgets visibly separate rather than letting platform work get silently absorbed into feature timelines, because if it is not named as its own line item it always loses when a deadline gets tight. I typically aim for a rough split, adjusted by product line maturity, and I present that split explicitly to the CEO so platform investment is a decision made in daylight rather than a default I have to defend after the fact. When we needed to migrate a core piece of infrastructure that would consume real capacity with no visible feature output for two quarters, I framed it to the executive team not as a technical nice-to-have but as a direct constraint on our ability to hit next year's roadmap commitments, with a specific list of features that would be materially slower or impossible without it. That framing got it funded without a fight, because I connected the investment to commercial outcomes rather than asking the business to trust engineering judgement alone.

How do you measure the health of the product organisation as a whole, not just one product?

I track a small portfolio-level scorecard alongside the individual product metrics each pod owns: overall roadmap predictability, meaning the percentage of committed initiatives that actually shipped in the quarter they were planned for, PM retention and internal promotion rate, cross-team dependency friction reported through a quarterly pulse survey with engineering and design, and the split between reactive and strategic work each pod is spending time on. Any single product's metrics can look healthy while the organisation underneath it is fraying, for example a pod hitting its numbers by working unsustainable hours or by skipping discovery entirely, and the scorecard is designed to catch that before it shows up as attrition or a burned-out lead PM. When roadmap predictability dropped sharply two quarters in a row, I dug in and found we were consistently underestimating dependency work across pods, which led me to add a dependency-mapping step to planning that fixed the pattern within two cycles.

Head of Product

Head of Product interviews test whether you can own an entire product organisation, not just a single roadmap. Boards and CEOs want a leader who sets product strategy across multiple lines, builds and runs a team of PMs, defends resourcing decisions in front of engineering and sales leadership, and can explain the health of the whole function in language the executive table understands. This guide covers the questions that come up most often at this level and the answers that show you operate as a business leader who happens to run product, not a senior individual contributor with a bigger title.

For general interview preparation tips, read our guide to common interview questions.

Prepare further

How to ace the behavioural interview (STAR method)How to prepare for a technical interview

Common Head of Product Interview Questions

Behavioural Interview Questions for Head of Product Roles

Technical Questions for Head of Product Candidates

What Hiring Managers Look for in Head of Product Interviews

What hiring managers really look for in Head of Product candidates:

Portfolio-level thinking. Can the candidate talk about trade-offs across multiple product lines, not just one roadmap? Anyone still describing a single feature backlog is not ready for this level.
Real organisational design experience. Ask them to walk through how they have grouped or regrouped a team of PMs and why, not a hypothetical org chart.
Evidence of a hard call made and owned. Killing a product line, moving someone off a team, or saying no to sales all cost something. Listen for what the candidate actually did, not just what they would do.
Board and executive fluency. The candidate should be able to explain product health and strategy in commercial terms a CFO or a board member would recognise.
Honesty about coaching outcomes that were not clean wins. A leader who has only ever turned people around is not describing the full range of people decisions this role requires.

Questions to Ask Your Interviewer

→How is the product function represented at board level, and who does this role report to?
→How many product lines does the team currently own, and how is the product organisation structured across them?
→What is the current split between near-term roadmap delivery and platform investment, and who owns that trade-off?
→How does product work with sales and engineering leadership when priorities conflict?
→What would make this hire a clear success from the board's perspective after the first year?

Practise These Questions Before Your Interview

The mock interview tool builds a practice session around a specific job posting and your background, so you rehearse the questions most likely to come up.

Start Practising

Free to start. No commitment.

Related Roles

Available in Other Languages

Français Español