1. Outcomes since last review (15 min)
What shipped, the metric each release was supposed to move, and what actually happened. One line each. No demos.
Product operating toolkit
Product operating templates and standards
What this is
Four working templates used inside fractional CPO engagements: the monthly product operating review agenda, the roadmap decision packet, the discovery cadence standard, and the product spec standard. Readable in full on this page — no email gate, no PDF. Take them, adapt them, run them.
Tool_01
Use freely · attribution welcomeThe product operating review agenda
A monthly ninety-minute meeting where product performance is read and decisions are made. It replaces the status update that generates no decisions.
How to use it: Run it monthly with product, engineering, and one commercial leader. Same six blocks, same order, every time.
2. Adoption and retention read (15 min)
Activation, adoption, and retention by segment. Only the numbers that would change a decision.
3. Customer evidence (15 min)
What we learned from customers this month and which roadmap assumption it strengthened or killed.
4. Prioritization changes (20 min)
What entered the roadmap, what left it, and the trade-off named out loud. Nothing enters without something leaving or a date moving.
5. Risks and dependencies (15 min)
Technical, commercial, and AI-feasibility risks with an owner and a next check date.
6. Decisions and owners (10 min)
Written decisions with owners and review dates. If the meeting produced none, it was a status update.
Where it usually fails: It becomes a demo showcase. The fix is holding block 1 to outcomes against a pre-agreed metric, not features.
Tool_02
Use freely · attribution welcomeThe roadmap decision packet
A one-page format for any non-standard product decision, so it can be resolved without a meeting and without routing through the founder.
How to use it: The person surfacing the decision fills it out. If it can't be filled out, the decision isn't ready to make.
Decision needed
One sentence. Two sentences means it's two decisions — split it.
Options considered
Two or three named alternatives, each with the customer or commercial consequence. A single option is an update, not a decision.
Recommendation and reasoning
The author commits to one path and says why. Removes the 'what do you think' loop.
What changes if we're wrong
Reversibility and cost of being wrong. This is what tells an executive how much scrutiny the decision actually deserves.
Deadline and decision owner
When it must be decided and who decides. Undated decisions default to no.
Where it usually fails: It grows into a five-page brief. Cap it at one page — the constraint is the point.
Tool_03
Use freely · attribution welcomeThe discovery cadence standard
A minimum standing rhythm of customer contact, so the roadmap is informed by evidence rather than internal advocacy — without slowing delivery.
How to use it: Adopt as a team standard. It is a floor, not a ceiling, and it should survive a busy quarter.
Weekly
At least two customer or prospect conversations per product area, run by product, not routed through sales.
Per conversation
A short written note in one shared place: who, the problem in their words, current workaround, and the assumption it tests.
Bi-weekly
A fifteen-minute synthesis: which assumptions strengthened, which weakened, what the roadmap should do about it.
Before any significant build
A named assumption set with evidence for each, plus the one assumption that would kill the build if false.
Quarterly
A review of who we're not talking to — churned accounts, non-buyers, and the segment you keep assuming instead of asking.
Where it usually fails: Notes accumulate and nobody synthesizes. The bi-weekly synthesis is the only non-negotiable block.
Tool_04
Use freely · attribution welcomeThe product spec standard
A consistent minimum for what a product manager writes before engineering commits, so quality doesn't depend on which PM picked up the work.
How to use it: Apply to anything larger than a week of engineering effort. Below that, the decision packet is enough.
Problem and evidence
The customer problem in their language, with the discovery evidence that supports it.
Who it's for, and who it isn't
The segment and use case. Explicitly out-of-scope users prevent the scope drift that arrives in week three.
Success measure and review date
One primary metric, its current value, the expected change, and the date it gets read. Agreed before the build starts.
Scope: in, out, and later
Three lists. The 'later' list is what stops the build growing quietly.
Risk, feasibility, and data implications
Technical unknowns, dependencies, and — for AI features — data quality, evaluation approach, and failure behaviour.
Rollout and rollback
How it reaches customers, who is told, and what happens if it needs to be turned off.
Where it usually fails: The success measure gets filled in after launch. If it isn't set before the build, the spec isn't complete.
Want to know which of these to install first?
Take the free Product Operating Score — it returns your two weakest dimensions, which maps directly onto which tool matters most this quarter.