Framework
VPOM: the Value Product Operating Model.
Three layers, three cadences, three sets of decision rights. Strategic alignment runs quarterly. Bet scoping runs in six-week cycles. Delivery flow runs continuously. Most product operating models fail because those three run at the same speed, so strategy collapses into sprint planning and delivery becomes a status meeting.
The problem it solves
Most operating models are ritual catalogs.
Ask a struggling product organization what its operating model is and you get a list of meetings. Quarterly planning, monthly business review, sprint ceremony, roadmap readout. The list is real. The model is not, because nothing in it says who decides, at what cadence, on what evidence.
The symptom is recognizable. Strategy sessions turn into sequencing arguments. Delivery teams relitigate priorities every two weeks because the priority was never funded, only ranked. The roadmap is current and nobody believes it. Leaders respond by adding a ritual, which is how the catalog grows.
The cause is almost always cadence collapse. A company that decides strategy at the same frequency it plans delivery has no strategy layer at all, it has a long backlog with quarterly punctuation. A company that reviews delivery at the same frequency it reviews strategy starves teams of the autonomy that makes flow possible.
VPOM fixes the clock speeds first and the artifacts second. It is not a larger process. In most installs it removes more meetings than it adds.
The three layers
Different clock speeds, different decision rights.
Each layer owns a decision the other two are not allowed to make, and each produces one artifact. If the artifact does not exist, the layer is not running.
Strategic alignment
Quarterly
- Owner
- CEO and CPO
- Produces
- A written investment posture: the outcomes for the period, the bets funded, and the bets declined.
- Decides
- What the company is willing to be bad at this quarter.
- Diagnostic
- Can anyone in the product org name the three bets you said no to?
Bet scoping
Six weeks
- Owner
- Product, design, and engineering leads together
- Produces
- A shaped bet with an appetite, a named decision-maker, the evidence required to continue, and the condition that stops it.
- Decides
- How much of the company you are willing to spend before you learn something.
- Diagnostic
- For the work in flight right now, who is allowed to cancel it, and on what evidence?
Delivery flow
Continuous
- Owner
- The team doing the work
- Produces
- Shipped increments, a visible constraint, and an honest count of what is in progress.
- Decides
- Nothing strategic. That is the point.
- Diagnostic
- Does the weekly review change a decision, or does it report status?
Rituals
Four meetings, and no others by default.
Every ritual in VPOM exists to make a decision that belongs to its layer. A meeting that produces no decision is a report, and reports should be written. The test for keeping any existing ceremony is simple: name the decision it makes and the person who makes it.
- Quarterly bet review. Ninety minutes. The only agenda is what to start, what to continue, and what to kill. Status is read beforehand, not presented.
- Six-week shaping session. Product, design, and engineering shape the next bet together before capacity is committed. Nothing enters delivery unshaped.
- Weekly flow review. The team looks at the constraint, not the burndown. One question: what is the oldest thing in progress and what is holding it.
- Monthly evidence read. What did the last cycle teach. Written, short, and circulated. This is the artifact that makes the quarterly review fast.
Scorecards
Measure the layer, not the org.
Most product dashboards mix velocity, revenue, and satisfaction into one board slide, which makes every number unactionable. VPOM keeps one scorecard per layer, each answering whether that layer is doing its own job.
Strategic
Share of engineering capacity on funded bets. Number of active bets. Time from decision to first shipped increment.
Bet
Appetite consumed against evidence gained. Bets stopped on purpose versus bets that quietly ran out of energy.
Flow
Work in progress, age of the oldest item in progress, and the proportion of shipped work traceable to a funded bet.
AI-assisted delivery flow
Assistance raises the price of a bad bet.
The delivery layer is where AI assistance actually lands. Research synthesis, first-draft shaping input, prototypes that make a debate concrete, test and eval generation, edge-case exploration. Teams running this well compress the distance between a question and a usable answer from weeks to days.
That compression changes the economics of the other two layers. When output gets cheaper, unfunded work gets cheaper to start and just as expensive to maintain. An organization that speeds up delivery without tightening bet scoping does not ship more value, it accumulates more surface area.
So the rule at the delivery layer is narrow: assistance may draft, explore, and test. It may not decide. The named decision-maker on a bet is a person, the evidence that stops a bet is read by a person, and anything an agent produces enters the flow as input, not as commitment. This is the same discipline the control plane argument applies to customer-facing systems, turned inward on the product org itself.
Worked example
A composite install, four tribes, one quarter.
The example below is illustrative rather than a client account. A B2B SaaS company, roughly two hundred people, four product tribes, a two-year roadmap and a board asking why AI features had not moved retention.
The diagnostic took a week. Eleven initiatives were in flight against a stated capacity for four. Every tribe could name its roadmap items and none could name a bet the company had declined. Two of the eleven had no owner senior enough to stop them. The quarterly business review was a ninety-slide readout with no decision on the agenda.
The first quarterly bet review funded three bets and stopped four initiatives outright, two of which had been running for over a year on inherited momentum. The remaining four were moved to maintenance with a named owner and no roadmap presence. Nothing about team structure changed.
The first six-week cycle exposed the real failure. Two of the three funded bets had no stated appetite, so shaping ran until it was comfortable rather than until it was bounded. The second cycle set an appetite before shaping started, and one of the three bets was stopped at week four on evidence, which was the first deliberate stop the company had made in two years.
By the end of the quarter, the visible change was not velocity. It was that the weekly flow review took twenty minutes, the board deck had three bets in it instead of eleven initiatives, and the product leaders could answer the question the board had actually been asking: what are you not doing, and why.
When to use it
The conditions that make this worth doing.
- More initiatives in flight than the organization has capacity to finish.
- Strategy and delivery decided in the same room at the same cadence.
- Nobody can name the bets that were declined this quarter.
- AI assistance has raised output and the board has not seen the outcome move.
- A capable product leader is in place and the operating model is what is blocking them.
When not to
Cases where an operating model is the wrong fix.
- The company has one product, one team, and one decision-maker. Cadence separation adds nothing.
- The constraint is engineering throughput or reliability, not decision-making.
- The founder is the product owner and will not delegate the bet decision. Install the model and it will be overridden in week three.
- Product-market fit is genuinely unresolved. Search first, operate second.
What an engagement produces
Artifacts, not a deck.
- A decision-rights map: every recurring product decision, the layer it belongs to, and the single person who makes it.
- A funded bet list with appetites, named owners, and the stop condition for each.
- A ritual inventory showing what was removed, what was kept, and the decision each surviving meeting makes.
- Three scorecards with current baselines, reported to the board in one page.
- A written operating doctrine the team can run without the advisor in the room.
The measure of a finished install is that the second quarter runs without help. If the model depends on the person who installed it, it was consulting, not an operating model.
Proof
Operating model work, and what moved.
Context
European automotive retail SaaS, four product tribes, dealer and OEM customers.
Situation
AI, machine learning, and conversational AI work was running across product lines without a shared thesis or a single owner.
Intervention
Consolidated the AI work behind a smaller set of product bets and named an owner for each.
Outcome
A single AI thesis with a named owner behind each bet, and a shorter list of committed initiatives.
Context
Scheduling software company repositioning from consumer utility to product-led B2B.
Situation
Product, design, product marketing, and support were aligned to the old consumer motion.
Intervention
Reset the roadmap around the B2B thesis and rebuilt the partner and integration strategy behind it.
Outcome
A roadmap, a partner strategy, and a go-to-market motion all pointed at the B2B buyer rather than the consumer one.
Context
Healthcare workflow company moving from tech-enabled services to enterprise B2B SaaS.
Situation
Core platforms and the partner network needed relaunching while delivery continued.
Intervention
Installed the operating cadence, decision rights, and coaching that let the team run discovery and delivery in parallel.
Outcome
Discovery and delivery running in parallel under one cadence, with decision rights held by the team rather than escalated.
Questions
Common questions about VPOM.
- What does VPOM stand for?
- Value Product Operating Model. It aligns strategy, product bets, and AI-assisted delivery flow so that customer value creation, portfolio decisions, and the teams executing them run on one model rather than three disconnected ones.
- How is VPOM different from a product operating model like SAFe or Shape Up?
- Scaling frameworks specify ceremonies. VPOM specifies cadence, decision rights, and the artifact each layer must produce. It borrows shaping and appetite from Shape Up at the bet layer, but it does not prescribe how a team runs its week. The constraint is that the three layers must run at different clock speeds and must not trade decisions across layers.
- Does VPOM require AI tooling?
- No. The three layers work without a single model call. AI-assisted delivery flow is a property of the third layer: research, shaping input, prototyping, and test generation move faster with assistance, which raises the value of good decisions at the first two layers and raises the cost of bad ones.
- How long does it take to install?
- One quarter to run the full loop once. The first quarterly review and the first two six-week cycles are where the model is actually tested, because that is when something gets declined and someone has to hold the line on it.
- Does this replace an existing VP Product?
- No. VPOM gives a VP Product the decision rights and the artifacts to lead with. Most of the time the operating model is the thing standing between a capable product leader and a functioning org, not the leader.
More on how engagements run is on the FAQ.
The first step
Ninety minutes on the decision you are actually stuck on.
Most advisory relationships start with a discovery call that discovers nothing. This one starts with work. Send the context beforehand — the roadmap, the org chart, the three AI initiatives nobody owns. We spend ninety minutes on the single decision blocking the others. You leave with a written point of view: what you should stop, what you should own, and what the next ninety days look like.
Format
90 minutes, one decision
Deliverable
Written point of view within 48 hours
Price
$1,500, credited against any engagement
Not a fit if you want a vendor evaluation, a staffing plan, or a deck to circulate. If ninety minutes shows this is not a fit, Kevin will say so and point you somewhere better.