Prioritize Feature Requests Before You Know Your Customer

Several users are asking you for different features, the advice says protect the roadmap, while you can't yet say who your product is for.

In the 90s I built one of the first dating web apps. Profiles, photos, browsing, matching. We thought we were in the introductions business.

Then we found out what our users actually wanted: to write to a potential match without revealing their real email address. Fair enough. Your email address back then was your identity, often your real name at your employer's domain (readable, if the sysadmin felt curious).

I implemented it in a couple of days. Messages passed through the platform, real addresses stayed hidden. Usage surged.

That memory comes back whenever someone asks how to prioritize feature requests in a young product. You probably know the situation from inside: real users, several plausible customer groups, each asking for something different, and a quiet fear that saying yes to everyone turns the product into a junk drawer.

The standard advice has an answer. I think it arrives too early.

The Advice Assumes You Already Know the Customer

The consensus on handling customer feedback is remarkably consistent. A feature request is a proposed solution, so investigate the underlying problem instead of building what was asked. Rob Fitzpatrick compressed it into a rule in The Mom Test: customers own the problem, you own the solution.¹

The frameworks stack neatly on top. One VC-published formula scores each request by how many customers asked, how urgent they sound, and how large their companies are.² Aha!'s prioritization guide starts from measurable goals aligned with your product vision, then scores the backlog against them.³

Sound advice. Now follow its assumptions.

Weighting by company size assumes you know which company sizes you want. Scoring against strategy assumes a strategy exists. Prioritizing requests from your ideal customer profile assumes you can describe your ideal customer without laughing nervously.

In the stage where feature requests hurt the most, none of those exist yet. The strategy is the thing you're trying to find. The advice works at the stage it was written for. You're earlier than that.

What works earlier is treating requests as instruments instead of obligations.

A Request Is a Probe

Judged by every rule above, my dating app decision was malpractice. We built the literal solution users described. No product discovery interviews, no scoring model, no strategic alignment check. All our sophistication had gone into the matching algorithm.

It was the most informative thing we ever shipped. The surge told us something no interview had surfaced: we thought we were selling introductions, and our users were also buying early-stage anonymity. People wanted to meet strangers. They feared what a stranger could do with their real identity.

The market kept confirming the lesson. Match.com launched in 1995 with double-blind email as a signature feature, and thirty years later every dating app still routes messages so that strangers never see contact details.⁴ The request we treated as a quick favor turned out to be a load-bearing wall of the entire category. The matching algorithm that held all our sophistication wasn't the whole picture.

Here's the two-stage rule I wish someone had handed me. 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, reverse the polarity: prioritize the requests that repeat inside that segment, and let everything else go.

One asterisk on the rule before the mechanics. It talks about finding your customer, and the email probe answered a bigger question: what we were actually selling. A probe pointed at who sometimes comes back with what. Take both answers seriously.

A probe pays either way. If adoption surges, you've found pain worth a second look. If it lands with a thud, you've eliminated a hypothesis for the price of a few days (nowadays, with AI, probably a few hours). Interviews tell you what people believe they would do. A shipped feature shows you what they do.

Sometimes the requested solution really is an underlying problem wearing clothes, as ours was. Sometimes it's a decoy. You can't tell from the request alone, and reversibility is what makes it safe to find out. This is market discovery, run through your codebase instead of a survey.

That still leaves the queue. Four requests, all cheap to reverse, one of you. Here the standard advice inverts one more time: before you know your customer, you're not prioritizing for value, you're prioritizing for information. When two of your plausible customer groups ask for the same feature, building it teaches 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. Count votes at this stage and you'll keep building the features that keep you confused.

What to Write Down Before You Build

Generosity without records is just motion. A request becomes an experiment the moment you write down what it's supposed to teach you.

Before building, four notes:

1. Who asked, and what were they doing when the need appeared?
2. What pain sits underneath the requested solution?
3. What would shipping teach you that a conversation wouldn't?
4. What condition removes this feature later?

After shipping, three observations:

5. Who adopted it, and how fast?
6. Did money, retention, or urgency follow?
7. What does it cost to keep alive, against what it's still teaching you?

Seven lines per request. Call it the probe record. It has one job: to stop a temporary experiment from quietly becoming permanent scope.

Here's mine for the email feature, filled in thirty years late:

1. Users deep enough into a match to want to write to them.
2. Writing to a stranger meant handing them your real name and your employer.
3. Whether fear of exposure, not the quality of our matching, was what held conversations back.
4. Remove it if people keep trading real addresses anyway.
5. Everyone, fast.
6. We never checked. We weren't keeping records, which is why this list exists.
7. It became an essential part of the product. The question expired.

Watch the two who-lines hardest, who asked and who adopted. When three probes surge and their adopters all look alike, the probes have done their real work. They've drawn you a picture of your customer.

Generosity Needs an Expiration Date

Everything above can be misread as permission to become a feature factory (an indie hacker proclivity). Read it again: every probe carries an exit condition, written before the first line of code.

The trap that catches most builders wears a suit. One large customer offers real money for something only they need, and a probe looks identical to custom services work from the outside. One question separates them: would a second, similar customer use this unchanged? If yes, the big customer may be pulling forward a feature the whole segment wants, and you can thank them for the deposit. If no, you're bending the product around one account, and the true price includes every future year of maintaining their private branch.

Build probes so they can leave. Feature flags, isolated code paths, a scope you could delete in an afternoon. None of this requires code, either. A service business can run the same probe: pilot the new offering for one client, with an agreed end date, priced as an experiment rather than printed into the permanent menu. Reversibility is what separates learning from debt.

One more temptation deserves naming. Shipping someone's request in days creates real goodwill, and sometimes that goodwill turns into public advocacy. Enjoy it when it happens, and write it in the record as evidence about that segment. But if the main reason to build something is the hope that the requester will promote you, you're spending real development time on a reward they never agreed to give.

The subtlest trap catches the builders who follow every rule in this essay. Probing feels like progress. Each shipped request earns a thank-you, fills another record, costs only a few reversible days.

Every probe is defensible on its own. Together, they can become a very disciplined way of never deciding anything. The reversibility that makes probes safe also makes them comfortable, and comfort is how a research phase turns into a personality.

So the phase needs an expiration date too, not just each feature. Count it in probes rather than months: pick a number of filled records before you start, ten is plenty, and when you hit it, name the segment you believe in most and act as if you're right.

And if the records refuse to converge, if probes keep surging but the adopters never look alike, that isn't a failure of the method. It's a verdict. No segment is waiting to be discovered, and your customer will have to be chosen instead of found.

Choosing is scarier than finding. It's also a decision you can now make with seven lines of evidence per option, which is more than most builders ever get to hold.

The Product Gets Smaller After the Signal Gets Stronger

The generosity phase has a purpose, and the purpose is its own ending.

Once you can describe the user who adopts fastest, pays most and soonest, and returns most often, responsiveness changes jobs. Requests from inside that segment, the ones that keep arriving in different words, are pointing at your core product. Requests from outside it get a polite no, delivered with a confidence you didn't have before, because now the no has a reason.

Then comes the part almost nobody does: removal.

I met this half of the discipline years later, owning a courier service. We added prepaid labels and priced them below our regular ones. Only a few clients wanted them.

A cheaper option, declined. On paper everyone prefers paying less, and no survey would have predicted the thud. It turned out most of our clients simply weren't used to prepaying for anything in the B2B world of that time. The labels taught us how our market thought about money, and then they stopped teaching anything at all. We removed them.

Walk your probe records with that same coldness. A feature that taught you something and now sits unused by your real segment is rent you keep paying on a lesson you already own. The exit condition you wrote before building gives you permission to collect.

This is also the moment the standard advice turns correct. You have a strategy to align against and an ICP to weight by, so the scoring formulas finally compute. They were waiting for stage two all along.

Thirty years later, I wonder what a prioritization scorecard would have done with that email request. Probably ranked it beneath features we felt strategic about, on a roadmap we had invented in a vacuum.

Before you know your customer, responsiveness is a research method. Afterward, it's a focusing lens. Build the request, watch who shows up, and have the nerve to shrink.

Rabbit Hole

More on this subject

• Critical Demand Signals Nobody Talks About: Rank feature requests against workarounds and other stronger evidence of urgent demand.
• Your Signups Are Lying to You: See why early interest can hide whether you found the right customer.

See this concept in another subject

• The AI Moat You Can't Buy: Follow the same feedback loop from customer discovery into competitive advantage.