01
Interview
Structured conversations across the full delivery chain — from where demand originates to who inherits the problems after release.
FREE TEMPLATE
The Product Operating Model Playbook.
A practical framework for defining how your team prioritises, decides and delivers work — built around interviews with your own people, so what comes out fits your organisation rather than someone else’s.
- →An interview map covering the full delivery chain
- →Seven questions that surface what is really blocking delivery
- →Tables for roles, decision rights, operating rhythm and standards
- →A deliberate "what we left out" section to keep it proportionate
Get the template
Sent to your inbox as a PDF. No sales calls — the file arrives whether or not you opt into anything else.
Why most product operating models get ignored
A product operating model only works if it fits the organisation it sits in. Most fail because they start from a framework — someone else’s ceremonies, someone else’s role definitions — and then ask the team to conform to it. People nod at the document once and carry on as before.
The alternative is to start from evidence. Interview the people who do the work and depend on it, find what is genuinely getting in the way, then design the smallest practice that addresses it. Every ceremony, role and standard should be traceable to something a real person said.
The four steps
02
Synthesise
Separate root causes from symptoms. Share the findings back before designing anything, so the team recognises the picture.
03
Design
Build the lightest practice that resolves what you found — and write down what you deliberately chose to leave out.
04
Review
Re-test after a quarter against the original findings. Drop anything that is not earning its place.
Who you need to interview
Cover each position in the delivery chain. In a small business one person may hold several — the point is that no part of the chain goes unheard.
→
Demand origin
How requests are raised, and what happens to them next.
→
Decision authority
Who can say no, and whether that holds in practice.
→
Delivery
What actually blocks the people building the thing.
→
Domain expertise
The operational reality the product has to survive.
→
Downstream support
Who inherits the problems once something ships.
→
The user, or their proxy
Whether any of this improves the thing they use.
The seven questions
Ask everyone the same core set, so answers can be compared across roles. They are about lived experience, not about what people think good practice ought to look like.
- Walk me through the last piece of work that went well. What made it work?
- Now the last one that went badly. Where did it come apart?
- How does work reach you, and do you find out early enough to do anything about it?
- When priorities conflict, who decides — and does that decision hold?
- What do you spend time on that you believe adds nothing?
- What do you know about this business that the people planning the work do not?
- If one thing changed about how we deliver, what would you pick?
Would rather someone ran this for you?
Building the model is part of a Product Strategy & Operating Models engagement — interviews, synthesis and the finished model, designed and run with your team.