Questions to Ask Chief Product Officer
Questions for a product manager or designer interviewing with the CPO they would report to, covering how decisions actually get made, what shipped recently, and where product authority really sits.
The questions
Open any question for the note
What shipped in the last quarter?
Why ask it
Open here rather than with strategy, because it is checkable. A CPO who lists three or four things with the reasoning behind each is describing a working organisation. Long answers about what is nearly ready usually mean release cycles that stretch and slip.
Who decides what goes on the roadmap?
Why ask it
Ask for names and a forum. In many companies the answer is the founder, the largest customer, or whoever escalates most persistently. None of those is disqualifying, but you should know which one you are joining before you accept a product title.
What did you decide not to build this year?
Why ask it
Roadmaps show what was chosen; this shows the trade-offs. A CPO who can name a significant thing they declined, and say why, is exercising judgement. One who has said yes to everything is running a queue rather than a strategy.
How much of the team's time goes to new work versus keeping things running?
Why ask it
Ask for a rough split. Anything under half on new work means a maintenance role whatever the job description says. Note whether they know the number at all, since teams frequently discover it only when someone measures.
When did you last talk to a customer yourself?
Why ask it
Not the research team, them. A specific answer from the past fortnight means customer contact is normal at that level. "We have a research function for that" is an answer about the organisation chart, and it tends to describe how far product sits from users.
What is the last thing you got wrong, and how did you find out?
Why ask it
How they found out is the more revealing half. Learning from usage data within two weeks is a different organisation from learning from a customer complaint eight months later. Candidates for the role should be assessed the same way.
How do you decide something has failed and should be turned off?
Why ask it
Most companies are much better at launching than at killing, and dead features accumulate as maintenance load. Look for a stated threshold and a recent example. A claim that everything shipped is still useful is very unlikely to be true.
How would you describe my role to the engineers I would work with?
Why ask it
Their framing tells you where product authority sits. Descriptions built around writing tickets and coordinating sprints mean a delivery role. Descriptions built around deciding what problem gets solved mean something else. Ask the engineers separately if you can.
What happens when engineering says a thing will take three times longer than expected?
Why ask it
You want the mechanics: whether scope gets cut, the date moves, or people are asked to work weekends. This single answer predicts more about your working life than any statement about culture, and it recurs constantly.
How does a design change get approved?
Why ask it
Ask who has veto and how often it is used. Where the chief executive reviews screens personally, timelines depend on their calendar and designers work to taste rather than to evidence. Common in founder-led companies and worth knowing in advance.
What is the largest customer able to demand?
Why ask it
In business software the answer is often a great deal, and it shapes the roadmap more than any strategy document. What you are listening for is whether there is a mechanism for saying no, or whether every renewal cycle rewrites the plan.
Which metric would you resign over if it went the wrong way?
Why ask it
Forces a single answer where most people would list several, and reveals whether they distinguish the outcome that matters from the dashboard. Retention and activation are serious answers; signups and page views are usually the answer of someone reporting upward.
How much of the roadmap is dictated by technical debt?
Why ask it
Ask directly, because it is rarely volunteered. A CPO who can talk specifically about a migration or a rewrite, and how it is being sequenced against feature work, is dealing with reality. Silence on the subject usually means the bill is still growing.
What is the disagreement you keep having with the sales team?
Why ask it
Product and sales conflict over commitments and timelines in almost every company. The answer shows whether the tension is managed openly or whether promises are made to customers that product finds out about afterwards.
How do people here find out why a decision was made?
Why ask it
Written documents, a recorded forum, or word of mouth. In organisations where reasoning is not recorded, the same arguments get relitigated every few months and newcomers cannot contribute for a long time. Ask to see an example if they mention documents.
Where would I have real authority, and where would I be recommending?
Why ask it
Ask plainly and get the boundary in words. The common disappointment in senior product roles is discovering the decisions were already made elsewhere. Better to hear the limits described honestly now than to infer them over six months.
What experiments have you run recently, and what happened to the losers?
Why ask it
Anyone can describe a testing culture. The useful detail is whether losing variants get shipped anyway because someone senior preferred them, which is the most common way experimentation becomes theatre.
How has the product organisation changed in the past two years?
Why ask it
Frequent restructuring means ownership keeps moving and long projects rarely finish. Ask how many reorganisations there have been and what prompted the last one. Two in a year is a substantive warning about the level above them.
What do you need from someone in this role that you have not had?
Why ask it
Turns the interview into a discussion of the actual gap rather than a general profile. A precise answer, someone who can hold a difficult customer relationship, someone who will write things down, tells you what the job is for.
What would make you leave?
Why ask it
A better close than asking about vision, because the conditions they name are the conditions under which this becomes a bad job for you too. It also shows how candid they are willing to be once the formal part of the conversation is over.
Working out what the role really is
Practical guidance for the conversation itself
How to use the conversation
Use the product first
Sign up, get to the point of value, and note where it breaks. Then ask about a specific rough edge. It shows preparation and it usually produces the most candid ten minutes of the interview, because you have named something they already know about.
Ask for the last instance, not the philosophy
"How do you prioritise" gets a framework. "What did you cut from the last release, and who objected" gets the truth. Rewrite each question you plan to ask into that form.
Talk to an engineer and a designer too
Ask them how decisions reach them and how often direction changes mid-build. Where their account differs from the CPO's, theirs is usually the one you will be living in.
Get scope in writing before you accept
Which surfaces, which teams, what you can decide alone. Undefined scope is the most common reason senior product hires end early, and it is much easier to settle before the offer than after.
Reading the answers
Signs product has real authority
- Can name something significant they declined to build, and why
- Has turned features off and can say what the threshold was
- Talks to customers personally and did so recently
- Distinguishes clearly between decisions they own and ones they influence
Signs it is a delivery function
- The roadmap is described as coming from sales, the board or the founder
- Your role is explained mainly in terms of tickets, ceremonies and coordination
- No recent example of a decision that went against a senior stakeholder
- Experiment results are overridden by preference and nobody finds that odd
Mistakes candidates make
Asking about frameworks
Whether they use one scoring method or another tells you very little and is easy to answer well. What matters is who decides and what happens when the plan meets a date it cannot make.
Being impressed by the vision
Product leaders present for a living and the long-term story is the polished part. Weight the checkable answers, what shipped, what was cut, what was turned off, far more heavily.
Not asking about maintenance
The split between new work and keeping the lights on determines what your year looks like. Candidates almost never ask, and it is among the most predictive questions available.
Leaving the reporting line vague
Reporting to the CPO and reporting two levels below them are different jobs with the same title. Confirm who you report to, and who they report to, before the offer stage.