How is this different from the Mom Test advice to investigate problems, not solutions?

Rob Fitzpatrick's rule (customers own the problem, you own the solution) is sound but presupposes you know which customers to listen to. When several plausible segments each describe different problems, the probe approach uses shipped features to surface which segment matters most before you commit to any single problem framing.

Does building the literal solution users describe always work?

No. The dating app example succeeded partly because the requested solution exposed a deeper, previously invisible pain. Other times the request is a decoy. The safeguard is reversibility: build so you can remove the feature in an afternoon, and write an exit condition before you start.

When should you switch from probing to standard prioritization?

Once the adopter profiles across several probes start to converge and you can describe a segment with conviction, switch to conventional frameworks: score by alignment with that segment's needs, filter out requests from outside it, and start saying no with a reason behind it.

Feature Requests as Probes: Prioritizing Before You Know Your Customer

Standard advice for prioritizing feature requests assumes you already know your customer. Score by company size, align with strategy, filter through your ideal customer profile. When you are early enough that the strategy is the thing you are still trying to find, none of those inputs exist yet. The frameworks work at the stage they were written for. You are earlier than that.

Requests as Instruments, Not Obligations

What works earlier is treating each request as a probe: a cheap, reversible experiment designed to reveal which users carry the strongest pain. A probe pays either way. If adoption surges, you have found pain worth investigating further. If it lands flat, you have eliminated a hypothesis for the cost of a few days of work.

The distinction matters because interviews tell you what people believe they would do, while a shipped feature shows you what they actually do. Sometimes the requested solution really is an underlying problem wearing clothes. Sometimes it is a decoy. Reversibility is what makes it safe to find out.

The Two-Stage Rule

Before you can name your ideal customer, build only the requests that are cheap to reverse, and treat each one as a probe into which users have the strongest pain. Once a segment emerges from the pattern of adoption, reverse the polarity: prioritize the requests that repeat inside that segment and let everything else go.

One important wrinkle: a probe pointed at who your customer is sometimes comes back with an answer about what you are actually selling. In the mid-1990s, an early dating web app built anonymous message relay because users asked for it. The team thought they were selling introductions. The surge in adoption revealed they were also selling early-stage anonymity, a fear of identity exposure that no interview had surfaced. Match.com launched with double-blind email as a signature feature in 1995, and thirty years later every dating app still routes messages so strangers never see contact details. The quick favor turned out to be a load-bearing wall of the entire category.

Prioritize for Information, Not Value

Before you know your customer, the queue should be ordered by how much each request teaches you, not by how much value it delivers. When two plausible customer groups both ask for the same feature, building it tells you nothing about which group is yours. The request only one group would ever use is the better probe, even if fewer people asked for it. Counting votes at this stage builds the features that keep you confused.