Pull up your last release notes. For every feature on that list, ask one question: why did we actually build this. Not the polished answer from the planning doc. The real answer.
Most product managers cannot answer cleanly. The feature got built because an executive liked it, because a competitor shipped something similar, or because it was fun to design. That fuzziness is exactly what Adam Nash's three feature buckets framework was built to kill.
Where this framework actually came from
Nash published the idea on his personal blog on July 22, 2009, in a post called "Guide to Product Planning: Three Feature Buckets." He was not writing from the sidelines. Nash had spent years in product leadership at Apple and eBay before becoming VP of Product Management at LinkedIn, where his teams shipped a new release every single week.
That weekly cadence matters. Nash was not designing a framework for a single splashy launch. He needed a way to sanity check a constant stream of smaller releases, fast enough to use every week without turning into a bureaucratic exercise. He later went on to become COO, then President and CEO of Wealthfront, and today runs Daffy, a fintech nonprofit. The framework survived all of it because it is simple enough to use in fifteen minutes and sharp enough to matter.
The rule is blunt. Every feature you ship falls into one of three buckets, and a single feature almost never belongs to more than one.
Bucket one: metrics movers
These are the features designed to move the number your team gets judged on. Growth, engagement, retention, revenue. Not "might help." Move it, visibly, on a dashboard someone else is watching.
Here is the uncomfortable part for a product manager. In any given release, only a handful of features genuinely qualify. The rest are supporting work, maintenance, or bets that will not show up in a metric for months, if ever. Nash's own framing is that very few features are true metrics movers, and that is by design, not failure.
The job of a PM is to name those few explicitly before the release ships. If you cannot point to which one or two features are supposed to move the number, you have already lost the ability to explain a miss later.
Bucket two: customer requests
This bucket is the most emotionally loaded of the three, because ignoring it is how trust erodes. These are the features your support tickets, sales calls, and community forums keep surfacing without you asking.
You do not owe every customer request a yes. Some requests conflict with each other, some are one loud user speaking for nobody else, and some would quietly wreck the product for everyone else. But you do owe customers a real listening process, and you owe yourself honesty about which requests you are choosing to skip and why.
A roadmap that never ships a requested feature is not being strategic. It is telling customers their feedback goes nowhere.
The clearest real-world example of this bucket is also one of the most famous omissions in consumer tech history: the original iPhone shipped in 2007 without copy and paste. Users asked for it constantly, loudly, for two straight years.
Bucket three: customer delight
Delight cannot be requested, because customers cannot ask for something they cannot yet imagine. Nobody wrote into eBay in 2005 demanding a feature that did not exist yet. Delight lives entirely outside the request queue.
Nash's framing requires three ingredients at once for a delight feature to land: genuine understanding of the customer's underlying pain, a real read on what current technology makes newly possible, and design good enough to make the combination feel effortless rather than gimmicky. Miss any one of the three and you get a novelty nobody remembers using.
For a product manager, this is the bucket that gets starved first when a team is under pressure. Metrics movers get funded because finance demands them. Customer requests get funded because support escalates them. Delight has no natural internal advocate, which is exactly why it needs one.
The release that proves the framework works: iPhone OS 3.0
Nash points to Apple's iPhone OS 3.0 as an example of a release that hit all three buckets in a single package. It shipped June 17, 2009, packed with over 100 changes.
Cut, copy, and paste finally arrived, closing out the most requested missing feature since the original iPhone launched. That is bucket two, delivered two years late but delivered. In-App Purchase, a new API letting developers sell digital goods inside their apps, opened a durable new revenue channel for the platform. That is bucket one, a genuine metrics mover, not just for Apple but for the entire app economy that followed. And Spotlight search, letting users instantly find contacts, emails, and apps from one screen, was the kind of feature nobody had been clamoring for by name but that immediately felt indispensable. That is bucket three.
Three buckets, three different reasons, one coherent release. That is the pattern Nash is asking every product manager to reproduce, even at a fraction of that scale.
The missing bucket always points at something broken
Look across a few of your team's last releases. If one bucket is consistently empty, that gap is diagnostic.
No customer requests ever ship. Your feedback loop is broken somewhere between the support team and the roadmap, or requests are being logged and never revisited. No metrics movers ship. The team's work is not tied to outcomes leadership cares about, which is a dangerous place to be during the next budget review. No delight ever ships. Innovation has quietly stalled, usually because the team is permanently in reactive mode, clearing tickets instead of imagining what customers do not yet know to ask for.
The common mistake is assuming a busy roadmap is automatically a balanced one. Volume is not the same as coverage. A team can ship fifteen features in a quarter and still have a completely empty delight bucket, because volume-driven planning defaults to whatever is easiest to scope, which is almost always a known customer request or a small metrics tweak.
A practical playbook for your next roadmap review
Before your next planning cycle, run this as a fifteen-minute exercise instead of a philosophy debate.
List every feature currently in the roadmap or backlog for the next release. Next to each one, write which single bucket it belongs to, and force a single answer, not two. If you cannot decide, that ambiguity is itself useful information; it usually means the feature does not have a clear enough reason to exist yet.
Then count. If one bucket has zero entries, do not panic and stuff something in to check a box. Ask why it is empty. That answer, not the bucket count itself, is what you bring to your manager or your team.
How to apply this
- Before shipping, label every roadmap item as a metrics mover, a customer request, or a delight feature. Force a single label per item.
- Track your customer request backlog by source (support, sales, community) so you can prove, or disprove, that the feedback loop actually works.
- Protect a small, explicit allocation of team capacity for delight work each quarter, since it has no natural internal advocate fighting for it.
- When a bucket goes empty for two releases in a row, treat it as a team health signal, not a coincidence.
- In interviews, be ready to walk through a release you shipped using this framework. It signals structured product thinking fast.
Sharpening this kind of product judgment is exactly what gets rewarded in PM interviews. Practice it with 4,000+ mock PM interviews, run a mock interview straight from a real job description, or get your resume reviewed against a JD at allthingspm.app.
References
- Guide to Product Planning: Three Feature Buckets (Adam Nash, 2009)
- Adam Nash's 3-Bucket Product Planning Guide
- Former Greylock EIR And LinkedIn Product VP Adam Nash Joins Wealthfront As COO (TechCrunch)
- Building products that delight customers: Adam Nash (First Round Review podcast)
- Adam Nash Bio (General Assembly)
- iOS 3 (Wikipedia)
- iPhone 3.0 adds Copy & Paste, MMS, global Spotlight search (AppleInsider)
- iPhone 3.0: Push Notifications, Copy and Paste, MMS, and More (ReadWrite)
