Output as the Leading Indicator of Outcomes
Outcomes are the goal, but shipping rate is the only early signal you'll get that you'll hit them.
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 92%
The industry over-corrected into outcome obsession, and teams now produce beautiful briefs, crisp OKRs, and no shipped software. Miller's correction: output is an indicator of outcome, because the more shots you take at a problem the likelier you are to get it right. The framework is a diagnostic — separate velocity of decision-making from velocity of execution, then use non-punitive questions to make teams see their own cycle time.
Origin
Nikita Miller's own reversal after, by her account, swinging too far toward outcomes herself while advising and coaching companies. She nods to Frank Slootman's 'Amp It Up' (raised by Lenny Rachitelli in the interview) on never letting off the gas, but the decision-velocity vs. execution-velocity split and the questioning technique are hers.
Core principles
- 01Outcome thinking is correct and insufficient: the right goal with no shipping still fails.
- 02More attempts at market = higher probability of getting it right; shipping rate is therefore a probability lever, not vanity.
- 03There are two distinct velocities: decision-making (mostly the PM's) and execution (shared PM + engineering).
- 04Urgency is structural — someone else is likely doing something similar, better, faster.
- 05'Show me a list of everything you shipped' is an accusation; 'what did you deliver and how long did it take' is an inquiry.
- 06Vague articulation of the problem by the PM is a root cause of engineering's inability to break work into small tickets.
How to run it
- 1
Identify which velocity is actually broken
Before pushing anyone, work out where the drag is. Decision velocity: how long from 'we need to do a thing' to defining it to actually deciding whether and how to do it. Execution velocity: how long from decision to production. They have different owners and different fixes.
Pro tip Decision velocity is the one Miller finds takes a long time at most companies, and it lands on the PM most often.
- 2
Run the cycle-time question ladder, non-defensively
In sprint reviews, ask a chain of genuinely curious questions: What did you deliver this sprint? Okay — what did you deliver to production? How long have you been working on that? What was the cycle time? The goal is to let the team see its own throughput, not to be caught out.
Pro tip Frame every question as seeking to understand — you know the work is complex, and saying so up front is what stops the defensiveness.
Watch out Do not open with a demand for a shipped-things list. It makes people feel bad about their work and shuts the conversation down.
- 3
Interrogate the experimentation backlog instead of the people
Shift the conversation to the artefact: what's in our experimentation backlog, and how quickly are we getting those things out? This makes throughput a property of the system rather than an accusation against individuals.
- 4
Use competition as the urgency source
Keep a live pulse on competitors and reference it as a friendly reminder that others are thinking about this problem the same way. The question then becomes how quickly can we get many ideas to market and differentiate — not 'work harder'.
Pro tip Distrust founders who say they have no competition; the competitors you failed to recognise are the ones shipping great product two years later.
- 5
Audit the optimisation-vs-big-bet mix and the 'small thing' latency
As a smell test, ask how much time goes into optimisations versus bigger bets, and how long that takes. Then watch the small things: if a task that one person could do heads-down in a week or two resurfaces unfinished two quarters later, ask what happened in between.
Pro tip Bug fixes are the cleanest probe: how long does it take us to recognise something is broken and actually fix it?
Watch out There is no universal ratio for optimisations vs. big bets — a 30-year-old business with many acquisitions is not a growth-stage startup. Set it locally.
In the wild
Miller describes teams doing all the ideation, making decisions, and producing the right product briefs, design briefs, and experiment briefs — every artefact of good product development. But they aren't getting things to market quickly enough.
→ Her verdict: it just doesn't matter that much. The process quality is real but the missing output means the outcome will not land.
A team discusses a task most people would call simple — the kind of thing someone goes heads-down on for a week or two and finishes. Two quarters later, someone mentions it again and it still isn't done. Miller uses that as the opening: what did we do in between that made this not happen?
→ The gap becomes a concrete artefact for a prioritisation and velocity conversation rather than an abstract complaint that the team is slow.
Common mistakes
Swinging fully to outcomes and dropping output entirely
'Outcomes, outcomes, outcomes' is right about direction and blind about motion. Miller includes herself among those who swung too far and forgot that output is the indicator that the outcome is coming.
Blaming engineering for oversized tickets
Breaking work into small pieces is an engineering skill many teams need a refresher on — but if the PM hasn't articulated clearly enough what the team is trying to do, the work cannot be decomposed. The velocity failure is shared.
Turning velocity into a scoreboard
Demanding a list of everything shipped makes people defensive and doesn't make them faster. The questions must be genuinely curious about complexity, or the team will spend its energy on excuses instead of cycle time.
Is it for you?
Best for
Product leaders whose teams have great strategy documents, healthy OKRs, and a suspiciously empty release log.
Not ideal for
Teams already shipping fast into the wrong problem — there, the outcome conversation is the one that's missing, and pushing output will just accelerate the waste.
From the transcript
“myself included at certain points like swung way too far on the outcome strain and forgot that uh output is an indicator of that”
“Market quickly enough then it just doesn't matter that much so that conversation is one that I think we often have to revisit on teams…”
“need to do a thing to defining it potentially and then deciding are we actually going to do it or how and that I think…”
“just ask a bunch of questions what did what did you deliver and the more questions okay fine but what did you deliver to production…”
“let's talk about our experimentation backlog like what do we have in there how quickly are we”
From the episode
Driving alignment and urgency within teams, work-life balance, and the changing PM landscape
Nikita Miller (The Knot, Trello)