Flow Distribution: The Flow Metric Product Managers Own

In 2021, I was one of the founding board members of the Value Stream Management Consortium, the organization that has since become Flowtopia (flowtopia.io), representing Plutora alongside people from Digital.ai, HCL, ServiceNow, and Tasktop, with Helen Beal as our chair. We spent the next few years making one argument to engineering organizations over and over: stop measuring only how fast you ship, and start measuring how value flows from idea to outcome.

The reason project-to-product stalled was the operating model

What I keep running into is that many companies, especially larger ones, still run projects. Strategy gets decided at the top, sliced into initiatives, funded for a fixed scope and timeline, and handed down to a team assembled to deliver it, then dispersed when it's done. Mik Kersten named this the project model in Project to Product back in 2018, and he named the alternative right next to it: durable product teams that own a long-lived value stream rather than a one-off initiative. That alternative has a name now: the product operating model, an organization built around durable product teams and the outcomes they own instead of projects scoped to a date.

I cared about this enough to build an event around it. A few years back I created and ran the Project to Product Summit, the largest event Planview had ever hosted, fifty-three speakers, each of them there to make the same case: take the top-down model apart and push decisions down into product teams that can actually move.

What still surprises me, even after years of this, is that people in one model are certain they understand the other, and they don't. A project person hears "product team" and pictures a project team with a friendlier name and a standup. A product person looks at the project world and can't fathom why anyone would run software that way. They are genuinely different worlds, and you can't half-cross. You either decentralize the decisions or you don't.

Hersh Tapadia, our CEO at Allstacks, put the root of it better than I can:

"I'm always amazed at people's lack of imagination."

The job titles give away which world you're in. A project manager optimizes the iron triangle: scope, schedule, and budget, or the way I usually say it, the team, the time, and the deliverables. Move one, and you trade against the others. It's a model built entirely around output. Did we ship the agreed scope, on time, on budget? That's the definition of success, and it's a definition that never once asks whether the thing was worth building, or whether, once it shipped, it returned any value at all.

Plenty of product owners and scrum masters are project managers in product-sounding clothing. If what you ultimately answer for is scope, schedule, and budget, you're running a project, whatever it says on the org chart.

A product team is measured on something else. Outcomes. Not "did we ship the feature" but "did the feature move the thing it was supposed to move." Marty Cagan and the team at Silicon Valley Product Group have spent three books on this, Inspired, Empowered, and Transformed, and the definition they keep returning to is that empowered product teams "are cross-functional (product, design and engineering), are focused on and measured by outcomes rather than output, and are empowered to figure out the best way to solve the problems they've been asked to solve." It isn't only the Silicon Valley crowd saying it. Carlos Gonzalez de Villaumbrosia built Product School into the largest community of product managers by teaching the same thing: measure impact, not launches, and especially in the AI era, outcomes over output. The transition the industry actually needs isn't more AI. It's project managers giving way to product managers, and project teams giving way to product teams that own the result.

What product managers measure when they own outcomes

The moment a team owns outcomes instead of deliverables, it has to watch how value actually moves, the whole way, from idea to result. Engineering has a decade head start here, and also a blind spot.

If you run engineering, you know DORA. It's the de facto standard for delivery performance, now five metrics split into throughput and instability: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. It's genuinely good, and I'd never tell a team to drop it. But look at where it measures. Change lead time, in DORA's own words, runs "from committed to version control to deployed in production." Commit to deploy. That's the middle of the stream, the build-and-ship stretch. It says nothing about whether you were building the right thing, and nothing about whether what you shipped ever turned into a result.

Measuring the whole stream isn't only a metrics change. It's an org change. You can't run a value stream on an org chart built for projects, and that's the core argument of Team Topologies: structure teams around the flow of value, with stream-aligned teams that own a slice end to end, supported by platform and enabling teams. The measurement change and the team change are the same change.

The value stream runs from the moment someone has an idea to the moment that idea produces an outcome, and there's a set of flow metrics for it. Worth being honest about one thing, though. Flow metrics come out of Lean, and at their core most of them are about speed and efficiency, not outcomes. Flow velocity, how many value-bearing items finish in a period. Flow time, how long an item takes start to done, including the waiting. Flow efficiency, active time versus wait time. Flow load, how much is in progress at once. Four different ways to ask how fast and how cleanly work moves. Those matter to product, but mostly insofar as speed serves the outcome, and they're genuinely shared with engineering. Then there's the fifth one, flow distribution, and it's different in kind. It isn't about speed at all. It's about what you spend the capacity on. That's the one that should be product's alone.

Flow distribution is the dial product owns

Start with a question that sounds simple and isn't. What does it even mean to ship the right thing?

Everyone's reflex is that the right thing is a feature. Sometimes it is. But the right thing this week might be fixing the bug that's quietly churning your best account. It might be the code rework that cuts your infrastructure bill in half. It might be the security hardening that keeps you out of the headline. Every one of those is the right thing, and not one of them is a feature. So the real question is, where and how would you even see that? How do you look back on a quarter of work and know whether you spent it on the right mix of things? That is what flow distribution is for.

Flow distribution is the ratio of the different kinds of work you complete in a period. Not how much you ship. What kind. Every item moving through your stream is one of four kinds:

• Feature. New value. The work customers adopt and the reason anyone buys, expands, or renews.
• Defect. Protecting what you already shipped. The fixes that keep the experience customers already trust.
• Debt. The speed you keep. The refactors, platform, and tooling work, the kind that cuts that infrastructure bill, that keeps the next build cheap and fast.
• Risk. The disaster you avoid. The security, compliance, and resilience work that prevents the incident you never see.

Flow distribution is the balance across those four. And it belongs to product, only product, because setting it is a prioritization decision. Deciding that this quarter runs seventy percent features, fifteen defect, ten debt, five risk, because that's what the business needs right now, is about the most product decision there is. Engineering can price each kind of work for you. The PMO can hand you the schedule. But the mix itself, what the company spends its scarce build capacity on, is product's call. It's the dial, and product's hand should be the only one on it.

Starve a category, and it finds you

The mix matters because each of those four pays for something, and starving one doesn't make the cost go away. It defers it, with interest. I've watched this play out enough times that I treat it as a rule: starve a category, and it finds you.

• Starve risk. Security problems in production. Breaches, outages, the failed audit you never budgeted for.
• Starve defect. The bugs pile into incidents, and the work of triaging and explaining them swallows the team.
• Starve debt. Building quietly slows down, every change costing more than the last, until velocity bleeds out of the system.
• Starve feature. Nothing new pulls customers forward, so adoption flattens, growth stalls, and renewals soften.

Not one of those shows up on a throughput chart. You can ship like crazy and be starving three of the four the whole time. The mix is the management decision, and product owns it whether or not anyone has bothered to instrument it.

You can't AI your way out of a project

The industry's answer to all of this, right now, is to take teams that are still being run like projects, still measured on delivering a scope by a date, and tell them to use AI to do it faster. Ship more, ship sooner, same operating model.

That doesn't work, and it can't, because speed was never the constraint product faces. Pour AI into a project team, and you get more output, faster, in whatever mix gravity already picked, which is almost always all features, because features are what the top-down roadmap asked for. You accelerate straight past the two questions that actually decide outcomes: are we building the right thing, and did the last thing work? Shipping faster just means you reach the unanswered question sooner.

A team will never get where it needs to go if we keep driving it like a project and handing it AI as the fix. The real answer is quieter and harder: a product team that owns its outcomes, watches the whole stream from idea to result, and treats flow distribution as a dial it sets on purpose instead of one that gets set for it by whoever asked loudest.

That isn't a faster project team. It's a different thing entirely.

Where Product Studio fits

This is the part of the value stream we've been building for at Allstacks. Product Studio is a workbench for the whole stream, the product definition, the evidence behind the bet, and the outcome on the far side, in one place, so the mix you chose and the result you got aren't things you reconstruct from memory after the fact.

If you want to see what owning the whole stream looks like when it's built on purpose, sign up for Product Studio and put it on your own work. And if you want to trade notes on moving a team off the project model and onto outcomes, I'm around on LinkedIn at linkedin.com/in/jeffdkeyes.

References and further reading

• DORA, the four (now five) keys and their commit-to-production scope: https://dora.dev/guides/dora-metrics-four-keys/
• Flow metrics definitions (the Flow Framework, Mik Kersten): https://flowframework.org/ffc-discover/
• Mik Kersten, Output to Outcome: An Operating Model for the Age of AI (IT Revolution, July 2026): https://itrevolution.com/product/output-to-outcome/ (and the original, Project to Product, 2018)
• Marty Cagan / Silicon Valley Product Group on empowered product teams, outcomes over output: https://www.svpg.com/empowered-product-teams/
• Carlos Gonzalez de Villaumbrosia / Product School on outcomes over output and the AI-era PM: https://productschool.com/
• Matthew Skelton & Manuel Pais, Team Topologies, organizing teams around the flow of value: https://teamtopologies.com/
• The project management iron triangle (triple constraint): https://en.wikipedia.org/wiki/Project_management_triangle
• The Value Stream Management Consortium, now Flowtopia: https://flowtopia.io/

‍