A product organisation runs on a small number of mechanisms, and a product leader either owns them or is run by them. Here is the method I use to connect strategy, portfolio decisions, team delivery and reviews.
Enterprise strategy sets the themes and the metrics the company will track. Product lines write narratives that connect to them — the three-year plan for the arc, the annual operating plan for the year's goals, headcount and funding. At a pharmacy operation I wrote the theme that moved the plan from AI-assisted to AI-primary; at a payer I made the case for a substantial platform cycle.
Portfolio prioritisation is where strategy meets capacity. I run it with weighted shortest job first: business owners and product score each epic on value, time criticality and risk reduction; job size divides the total; the ranking falls out. The argument is then about the inputs — is this really more time-critical than that? — instead of about the list, which is the only kind of prioritisation argument worth having. Enabler work, the platform and data investments nobody sees, is funded explicitly next to business-value features, or it never gets funded at all. For safety work the risk-priority score plays the same role: alert optimisations were ranked by failure-mode risk, not by how many alerts they would remove.
Program increment planning connects objectives, dependencies and risks. A useful pattern is to gather teams around the ranked features, make dependencies visible on a program board, and resolve, own, accept or mitigate risks before committing. I led product work across multiple scrum teams and portfolios, and earned Product Owner/Product Manager, Agilist and Lean Portfolio Management credentials and completed DevOps training. I expect a system demo to show integrated working software. The rhythm and ceremony should fit the team and delivery context.
Teams run two-week sprints for planned work, and my preferred rule is that a story should not enter a sprint without acceptance criteria written given, when, then, in the operator's language. Demos go to stakeholders every sprint. For work that arrives on its own schedule — compliance requests, support, on-call — a sprint is the wrong container, so those flow across a Kanban board with columns as states, work-in-progress limits and aging made visible. Half of running a portfolio is knowing which work belongs in which container.
Where feature flags are available, customer release can be separated from deployment and expanded after the go/no-go. A bounded pilot, then evidence-based expansion. The launch announcement reports against the criteria set before build.
And then the loop closes upward, through business reviews at every altitude. Weekly for a channel: funnel, onboarding time, partner pipeline — I owned the insights for a large enterprise integration channel that way. Monthly with partners: pilot status, API changes, joint pipeline. Monthly for a portfolio: the product review I created, the portfolio on one page, highlights with the number moved, lowlights with the cause and the fix, decisions needed stated as options. Quarterly with executive stakeholders: portfolio goals across regions, the numbers behind each, the asks. The same three families of metric — inputs, outputs, defects — run through all of them; only the altitude changes, and commentary appears only where a line moved.
Two ideas sit underneath the whole system. The first is the door. Some decisions are two-way: a dial percentage, a feature toggle, the scope of a prompt, an agent version deployed as an immutable snapshot. Those get decided fast, by the person closest to the data, and reversed cheaply if wrong. Some are one-way: synchronous versus asynchronous architecture, the key a safety task is attached to, cancel versus hold when a check fails, the legal criterion a compliance position rests on. Those get the full gate — the design document with alternatives, the review, the signatures. Most of the judgement in this job is telling the two apart, and most of the damage I have seen came from treating a one-way door as a two-way one, or freezing at a two-way door as if it were one-way.
The second is the flywheel: a strategy in which each turn should make the next one easier. In safety work, cleaner data and fewer false alerts can support pharmacist trust, capacity and better feedback. In an integration channel, better onboarding and a useful purchasing experience can support adoption and further partner investment. These are intended causal loops to test. When I evaluate a strategy, I ask where that compounding effect could come from and what evidence would establish it.
Tools in this chapter Scaled Agile — program increment planning, WSJF, release trains · Jira · Jira Align · Kanban boards · OP1/OP2 planning · weekly, monthly and quarterly business reviews · a monthly product review · two-way / one-way door classification · flywheel design