P-Stage Cycle-Time Benchmarking
Stage-gate every initiative (PStrat→P0→P1→P2), size it S/M/L, and benchmark cycle time against yourself like golf.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 88%
Miro tracks product velocity by running every initiative through named stages — PStrat (strategy), P0 (problem definition), P1 (solution definition), P2 (post-ship metric check) — while classifying each as small, medium, or large. Cycle times per stage are collected across 50+ teams and made openly available, so any team can see the average, median, and variance for its project size and spot where it's slow (e.g. 'I spent too long in problem definition') or fast (and share why). Velocity is framed as golf: you compete against yourself, not others.
Origin
Built at Miro under Varun Parmar, run by an internal 'product excellence' (product ops) function. Parmar credits some inspiration to practices he learned at Box.
Core principles
- 01Velocity is a game against yourself — the only question is how much better you can get.
- 02Stage-gates make cycle time decomposable, so you can locate the specific slow step.
- 03Sizing work S/M/L makes cross-team benchmarking apples-to-apples.
- 04Openly shared data lets teams self-diagnose and learn from faster peers.
How to run it
- 1
Define the stage-gates
Route every initiative through PStrat (strategy), P0 (definition of the problem), P1 (definition of the solution), and P2 (post-ship check against the metrics defined up front).
- 2
Size each initiative S/M/L
Classify each project as small, medium, or large so cycle-time comparisons are fair (e.g. a small thing should take less than a month).
- 3
Collect and expose cycle times
Have a product-ops / product-excellence function record time-in-stage across all teams and make it openly available with averages, medians, and variance by size.
Watch out Data from meetings and Slack is uneven — getting reliable cycle-time data is the hard part; invest in capture.
- 4
Self-diagnose and cross-pollinate
Teams compare their stage times to the benchmark, find where they over-ran (e.g. problem definition), and go talk to teams that did it faster — or share their own speed-ups.
Pro tip Frame it as improving against your own baseline, not ranking teams against each other.
In the wild
Parmar describes a PM realizing 'I took way more time in the problem definition stage' by comparing against the benchmark, then going to talk to another product team that did that stage much faster — or, when fast, sharing the reason with the broader org.
→ Cycle-time transparency turns velocity into a learnable, shareable competency across 50+ teams.
Common mistakes
Turning benchmarks into inter-team competition
Parmar's golf analogy is deliberate — the comparison is against your own baseline. Using the data to rank teams against each other undermines the learning and sharing behavior it's meant to create.
Assuming the data is clean by default
Because signals live across meetings and Slack, reliable cycle-time data is hard to capture. Without investing in the product-ops recording function, the benchmarks are unreliable and the whole loop breaks.
Is it for you?
Best for
Scaling product orgs (dozens of teams) that want to measure and improve delivery speed without vibes-based judgments.
Not ideal for
Small teams where lightweight coordination suffices and stage-gate tracking would add pure overhead.
From the transcript
“which starts with with the p strad which is a strategy and then we go into P0 which is uh you know definition of the…”
“velocity is more like the game of golf uh uh where you're just playing against yourself”
“it seems like I took way more time in the problem definition stage let me actually try to go talk to this other product team…”
From the episode
An inside look at how Miro builds product: Lessons on outmaneuvering competitors, team structure, product quality, and moving fast
Varun Parmar (CPO of Miro)