You're here when: Someone has requested a feature, a customer, a teammate, your own gut, and you need to decide whether it's worth building.
The Heuristic
Run the request through four gate questions. All four must pass.
- Does it serve a job your users already hire you for? If you can't connect it to a real job customers are using your product to accomplish, it doesn't belong. Christensen's Jobs-to-be-Done framing helps here: people don't buy products, they hire them to make progress. A feature that serves an adjacent job, not the one they hired you for, dilutes the product. But there's a second lens worth applying: does this feature reduce anxiety or habit (the forces that block switching) or does it increase pull? The best features do one of those three things for your core job. A feature that makes onboarding less scary reduces anxiety. A feature that imports data from a competitor reduces habit. A feature that adds a capability your competitor lacks increases pull. If a feature doesn't move any of the four forces in your favor, it's not making adoption easier, it's just adding surface area.
- Can you explain it to a stranger in one sentence? If explaining why this feature exists requires context about your roadmap, architecture, or a specific customer's workflow, it's too niche.
- What would you cut to make room? Every feature has an opportunity cost. If you can't name what you'd deprioritize, you're pretending your capacity is infinite.
- What's the cost of NOT building it? If the answer is "nothing much changes," you have your answer.
Decision Tree
Quick Example
Basecamp deliberately refused to add Gantt charts, the most requested feature in their category. Gantt charts served a real use case but not Basecamp's core use case (simple project communication). Adding them would have pulled the product toward enterprise complexity and away from the simplicity that defined it. Twenty years later, they're still profitable and still don't have Gantt charts.
Des Traynor's Addition: Does It Pass the Frequency Test?
Des Traynor (Intercom) adds a filter the gate questions above don't cover: who will use this, and how often? Plot your features on two axes, audience size and usage frequency. The top-right quadrant is your product's core, the thing people actually use it for. Features that land in the bottom-left (few users, rarely) are clutter, no matter how clever they are. A feature that passes all four gate questions but lands in the bottom-left is still a bad investment. Big audience + high frequency = core product. Small audience + low frequency = cut it or don't build it.
The Anti-Pattern
The Cheap Feature Fallacy. "It'll only take a day to build" bypasses all scrutiny. Quick-to-build features skip the gate questions because the effort feels negligible. With AI-assisted coding, building features has become cheaper than ever, which makes this fallacy even more dangerous. When anything can be built in hours, the temptation to say yes to everything skyrockets. But the permanent costs remain regardless of build time:
- Maintenance burden (forever)
- Cognitive load on users
- Support overhead
The cost of a feature isn't the sprint to build it. It's the forever of maintaining it. The cheaper building gets, the more important it becomes to say no.
Written with ❤️ by a human (still)