INNOVATIONWeeks to result

Digging Beneath Feature Requests

Uncover the real motivation behind what customers say they want you to build

Problem it solves

stagnant innovation

Best for

Product managers and founders who are overwhelmed by feature requests and need to prioritize based on underlying customer needs rather than surface-level demands

Not ideal for

Situations where the customer is a domain expert making highly technical, specific requests that require specialized knowledge to evaluate

Overview

Why this framework exists

Digging Beneath Feature Requests is a technique for extracting genuine customer motivations from the surface-level solutions they suggest. When customers request specific features, they are doing your job for you and usually doing it poorly. They know what their problems are, but they do not know how to solve them. Your job is to understand the underlying motivation so you can design a better solution.

The technique involves asking 'why do you want that?' when a customer suggests a feature, and then continuing to dig until you reach the root motivation. A customer who requests a way to export data to a specific file format might actually need to share reports with a colleague who uses different software. The feature request is a proposed solution; the real need is seamless collaboration, which could be solved in many better ways.

This framework also applies to ideas that customers volunteer during good conversations. When a prospect gets excited and flips to your side of the table, they will start suggesting possibilities and features. Write these down but do not rush to implement them. Instead, dig into why they want each thing. The motivations and constraints behind feature requests are critical; the specific requested features are almost always wrong.

Core principles

5 total
  1. Customers own the problem; you own the solution
  2. People know what their problems are but do not know how to solve those problems
  3. Feature requests are just the customer's proposed solution to an underlying need
  4. The motivations and constraints behind requests are critical; the specific features are not
  5. Startups are about focusing and executing on a single scalable idea, not jumping on every good suggestion

Steps

4 steps
  1. Capture the feature request
    When a customer suggests a feature or idea, write it down. This shows you are listening and respecting their input. Do not dismiss it outright, but do not commit to building it either.
  2. Ask why they want it
    Dig into the motivation behind the request. Ask why they want that specific feature, what problem it would solve, and how they are currently dealing with the situation. The goal is to separate the symptom from the disease.
  3. Understand the constraints
    Explore what prevents them from solving the problem themselves. What have they tried? What obstacles exist? Understanding constraints helps you design solutions that actually work within their real-world limitations.
  4. Synthesize the underlying need
    Translate the feature request into a need statement that is independent of any specific solution. This gives you the freedom to design a better approach while still addressing what the customer actually cares about.

Checklist

Saved in your browser

Examples

1 cases
The finance team messaging tool

Finance professionals were spending hours daily emailing spreadsheets to each other and requesting better messaging tools. When asked why they bothered with all this emailing, they revealed the real motivation: ensuring everyone was working from the latest version of each spreadsheet. The requested solution was a messaging tool; the actual need was version control for shared documents.

OutcomeBy digging beneath the feature request, the founders realized the solution was more like Dropbox than a messaging app, which was a fundamentally different and more effective product direction.

Common mistakes

2 traps
Building exactly what customers request
This is product-by-committee and produces mediocre results. Customers are describing solutions through the lens of their own limited knowledge. Your job is to understand the underlying need and design something better.
Dismissing feature requests entirely
While you should not build exactly what is requested, feature requests are valuable signals. They indicate that a customer cares enough about a problem to think about solutions. Dismissing them means missing the motivation behind them.

Origin story

How this framework came to be

Fitzpatrick observed that when founders started having good customer conversations, they would often over-correct by building exactly what customers requested, effectively creating products by committee. He recognized that customers are excellent at describing problems but poor at designing solutions, and developed this digging technique to bridge the gap between what customers say they want and what they actually need.

Source

Traced to primary
Source · BOOK
The Mom Test
Rob Fitzpatrick · 2013
Open source →

Related frameworks

Browse all Innovation →