Celebrate Adoption, Not Shipping
Replace hours and feature counts with customer-adoption outcomes teams can actually steer toward
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 92%
Remote teams are told to 'focus on outcomes, not hours', but most then substitute deliverables (ship 20 features, close the bug) which are just hours in disguise and are trivially gameable by slicing features smaller. DeSanto's fix is to define the outcome at the level of customer adoption of a portfolio area, and let teams decide the mix of features, bug fixes and usability work required to get there.
Origin
David DeSanto's operating answer at GitLab to the practical failure of 'outcomes over hours' — GitLab has historically been obsessed with shipping speed (149 monthly releases in 12+ years), and this is the deliberate correction toward what customers actually do with what ships.
Core principles
- 01Fixing a bug is a deliverable, not a business outcome.
- 02Feature counts are gameable — break a feature into tiny features and the metric inflates.
- 03A real outcome names a target state of customer behaviour ('60% of our customer base using this part of the portfolio').
- 04A good outcome implicitly scopes effort, so you never have to police hours.
- 05Sometimes the outcome needs no new feature at all — just making the existing one more usable.
- 06The hardest transition for people entering product is moving from bits and bytes to use case and pain point.
How to run it
- 1
Kill the hours conversation
Stop tracking whether someone did 40 hours or more than 40 hours. Replace the question entirely with an agreed outcome.
Watch out Removing hour-tracking without installing a real outcome leaves a vacuum that managers fill with deliverable-counting.
- 2
Write the outcome as a customer-behaviour target
Frame it as adoption or usage of a part of the portfolio by a proportion of the customer base, then ask 'now what do we do to get there?'. This gives a measurable target that a team can steer toward with any combination of tactics.
Pro tip The target should be one a team can influence within an iteration cycle but not hit by a single trivial deliverable.
Watch out Avoid targets like 'ship 20 features next month' — that could take a day and a half if you subdivide features, or more than a month if you don't.
- 3
Push the how down to the team
Leadership sets the outcome and the priorities; the group decides whether this milestone is 100% new features and the next is 100% bug fixes. That is the efficiency value in practice: drive responsibility to the lowest level.
- 4
Ship at 'good, not yet great' and let feedback close the gap
Get it out, start the flywheel, take the customer feedback, iterate. The outcome metric — adoption — will tell you whether the thing you shipped actually worked, which a ship-date metric never will.
Pro tip Ask 'what pain point or use case did we solve?' rather than 'did we ship on time?' in the review.
- 5
Re-scope mid-iteration when the outcome lands early
If three days into a one-month iteration the outcome turns out to be a week's work, don't wait — reach back out and ask for the next thing. Outcome framing only works if the loop is closed the moment reality changes.
Pro tip This is why 'don't wait' is inseparable from outcome framing: the outcome frame is what gives you the standing to renegotiate scope immediately.
Watch out The failure mode is an outcome achieved in week one and a team quietly gold-plating for three more weeks.
In the wild
Instead of assigning a feature list, GitLab frames the goal as getting 60% of the customer base using a given part of the portfolio, then asks the team to work out what gets them there. The team may conclude the answer is usability work, not new features.
→ A measurable target that ties loosely back to effort scoping without ever counting hours, and that redirects effort toward the customer's pain point rather than the shipping ceremony.
GitLab has always been proud of shipping speed — 12 releases a year for over a decade, 149 consecutive monthly releases. DeSanto notes that shipping cadence is not how customers experience the product.
→ A conscious company-level shift toward asking what pain point or use case was solved and whether the customer adopted it, rather than how fast the release went out.
Common mistakes
Calling a deliverable an outcome
'Fix this bug' and 'ship 20 features' feel like outcomes because they're concrete, but they measure activity. DeSanto explicitly separates the deliverable from the business outcome — the outcome is what the customer did afterwards.
Never leaving the bits and the bytes
DeSanto identifies this as the single biggest challenge for people moving into a product role from another discipline: they keep optimizing the artifact rather than the use case, so they always reach for a new feature when a usability fix would have produced the outcome.
Is it for you?
Best for
Product and engineering leaders in remote or async orgs who have said 'we focus on outcomes' but whose teams are still measured by tickets closed and features shipped.
Not ideal for
Pure infrastructure, platform or compliance work with no directly attributable customer-adoption metric, and very early-stage products with too few users for adoption percentages to be meaningful.
From the transcript
“we want to have 60% of our customer base using this part of the portfolio now what do we do to get there”
“celebrate the adoption not the the shipping”
“it's more about what paino or use case did we solve”
“sometimes you actually don't need to ship a new feature per se sometimes you just have to make it more usable”
From the episode
The GitLab way: Kindness, transparency, and short toes
David DeSanto (CPO)