Head of Product Interview Questions

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.