The Utility Curve
Use the S-curve of effort-to-value to decide whether a feature is under-invested or already maxed out
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 95%
Every feature or product follows an S-curve: early effort produces little value, then a magic threshold produces enormous value, then continued investment barely pays off. Use it to diagnose whether a struggling feature is under-invested (still on the flat part) or has hit diminishing returns, instead of treating features as binary have-it-or-not decisions.
Origin
Butterfield describes teaching this at Slack as the core lens for prioritizing product work, layering on Jeff Bezos's 'divine discontent' — the observation that the value bar keeps rising as users' standards go up.
Core principles
- 01Value is not binary; a feature can exist and still deliver near-zero value because it's on the flat part of the curve
- 02Before killing a feature, ask: have we under-invested, or have we captured all the available value?
- 03The threshold moves over time — as users get familiar, their standards rise (divine discontent), so old features silently decay in relative quality
How to run it
- 1
Plot the axes for the specific feature
Horizontal axis = cost or effort or quality invested; vertical axis = value, convenience, speed, or utility delivered. Pick the dimension that actually matters for this feature.
Pro tip Utility is the best general term for the vertical axis, but substitute quality, convenience, or speed depending on the feature.
- 2
Locate where the feature currently sits
Decide whether you are on the first shallow part (effort not yet paying off), the steep climb, or the second flat part (diminishing returns).
Watch out A half-built feature on the first flat part adds complexity but no value, so users give up and you wrongly conclude the feature isn't worth doing.
- 3
Make the invest-or-abandon call
If you're below the threshold, push harder to reach it. If you're past it, stop polishing and redeploy resources. If you'll never reach the threshold with reasonable effort, cut it.
- 4
Re-audit mature features against the rising bar
Because standards climb, revisit core flows (search, login, checkout, forgot-password) that were 'implemented once and never improved' — they may have slid back down the relative curve.
Pro tip The most-neglected flows are the essential-but-boring ones: account creation, sign-up, forgot password.
In the wild
A hammer with a handle that breaks on any impact is useless; making it slightly stronger keeps it useless — 'junk junk junk junk junk, okay, good, great' — and then extra strength stops mattering. Value only appears at the threshold.
→ Illustrates that early quality investment yields nothing until the threshold, and investment past it is wasted.
The iOS Google Calendar app lists every time zone in the world alphabetically even while searching, so typing 'east' surfaces Eastern Australia variants before US Eastern. It's been broken for years despite hundreds of millions of users.
→ A neglected flow that never got pushed up its curve, eroding the emotional connection and word-of-mouth that drive adoption.
Common mistakes
Treating features as binary
Assuming you either 'have' a feature or don't ignores that a feature can exist yet deliver no value because it never reached the threshold.
Adding a feature to the flat part and giving up
Shipping something not-good-enough adds complexity, users don't adopt it, and the team concludes the whole idea isn't worth doing when the real problem was under-investment.
Is it for you?
Best for
Product managers and founders deciding where to allocate limited engineering and design resources across competing features
Not ideal for
Very early prototypes where you don't yet know which features matter and are still searching for the value proposition
From the transcript
“the first bit of effort you put into something doesn't result in a huge amount of value, and then there's some magic threshold where it…”
“usually features are thought of as as binary. Like you you either have this feature or you don't”
“once people are familiar with a piece of software or the way a feature is (10:30) implemented or something like that, their standards go up”
From the episode
Slack founder: Mental models for building products people love ft. Stewart Butterfield