A feature request sounds precise. It often is not.

“Add team permissions” may mean a buyer needs approval controls. It may mean an evaluator cannot invite a colleague. It may mean your product has reached a larger company than it was built to serve.

If you build the sentence you were given, you may miss the problem underneath it.

Treat every request as evidence. Treat no request as an order.

Begin with the last real attempt

Ask the customer to show you what happened before they asked for the feature.

  • What were they trying to finish?
  • What started the work?
  • Who was involved?
  • Where did the current product stop them?
  • What did they do instead?
  • How often does this happen?
  • What does the workaround cost?
  • What happens if nothing changes?

Past behavior is stronger than an imagined future. “We would love a dashboard” is light evidence. A finance lead exporting three reports every Friday, joining them in a spreadsheet, and sending the result to twelve managers is heavy evidence.

The customer interview guide goes deeper on asking for events rather than approval.

Translate the request into a job

Write the request in three layers:

Requested object: “Give us a PDF export.” Blocked job: “Send a stable weekly result to people without accounts.” Required outcome: “Twelve managers can review the same approved numbers on Monday morning.”

The object is one possible solution. The job and outcome are the durable parts.

A scheduled email, shared read-only page, spreadsheet export, or API may solve the same job better. You cannot see those choices while the customer’s proposed object remains the requirement.

Do not correct the customer. They know their work. Your task is to separate what they need to accomplish from the first implementation that came to mind.

Record the evidence, not only the vote

A vote count strips away the facts that make a request useful.

For each request, keep:

  • the user and account;
  • the job they were performing;
  • the frequency and consequence of the block;
  • the current workaround;
  • the product stage where it occurred;
  • whether it stopped activation, payment, continued use, or expansion;
  • what commitment the customer offered;
  • links to the original conversation and observed session.

Two requests with the same label may describe different problems. Ten votes may come from free users who never reached the core result. One request may reveal why every serious buyer fails the same security review.

The record should preserve these differences.

Separate defects, missing table stakes, and expansion

Not every request belongs on one roadmap.

A broken promise

The product claims to perform the job, but the customer cannot complete it. This is usually a defect, confusing interaction, or reliability failure. Diagnose it before calling it a new feature.

If a user asks for bulk retry because ordinary processing fails each afternoon, the priority is not bulk retry. The priority is making ordinary processing dependable.

Missing table stakes

The product solves the core job, but a standard condition blocks adoption for the intended customer. Examples include account recovery, basic exports, accessible keyboard use, or the permission boundary required by the buyer you chose to serve.

“Expected” does not mean universally required. Front cofounder Mathilde Collin described launching an early product without many normal email features in YC’s discussion of feature prioritization at Front. The point was to learn whether the new collaborative behavior was valuable enough to overcome the omissions.

A deeper core job

The request helps the intended user get the same important result more often, faster, or with less risk. These requests can strengthen the product rather than widen it.

A new market

The request serves a different user, workflow, buying process, or risk level. It may be a good opportunity. It is still a strategic choice, not maintenance.

A private exception

The request reproduces one customer’s internal process and is unlikely to help others. Price it as custom work, support it deliberately, or refuse it. Do not hide it inside the shared product.

Judge requests against the product promise

Use six questions:

  1. Does this remove a proven block in the core job?
  2. Does it help the customer segment we have chosen?
  3. Have we observed the problem, not merely heard the solution?
  4. Will the change improve activation, retention, payment, or expansion?
  5. Can we support the new promise after launch?
  6. What more important work stops if we do this now?

The sixth question prevents a common lie. A feature is never “only two days” when it displaces two days of reliability work, customer learning, or distribution.

YC’s advice from first-time founders includes a blunt lesson about distraction: activity that does not improve growth or understanding can consume the company. A busy roadmap can be one form of that distraction.

Weight commitment more than enthusiasm

Ask what the customer will do if the product solves the problem.

Useful commitments include:

  • paying now for a bounded pilot;
  • supplying realistic data and access;
  • introducing the actual users or buyer;
  • agreeing to test by a fixed date;
  • replacing an existing paid tool;
  • expanding the account after a successful result.

Do not turn this into a trick. A customer may have a serious need but no authority to prepay. The commitment simply tells you how much behavior supports the request.

An independent SaaS founder described the hard version of this mistake in a 2025 Hacker News discussion: prospects promised to buy after a feature was built, then disappeared or found another reason not to purchase. A request attached to a present commitment deserves more weight than a conditional compliment.

Look for repeated problems, not repeated wording

Three customers asking for “folders” can create false confidence. One wants personal organization, one wants client separation, and one wants legal access boundaries.

Conversely, customers may describe the same problem with different requests: folders, tags, workspaces, permissions, and separate accounts. The repeated pattern is that they cannot keep one client’s work apart from another’s.

Review requests by job, user type, and consequence. Then read them beside product behavior. If people ask for organization but rarely create a second project, the request may be weaker than it sounds. If active teams invent the same awkward naming system, the behavior supports it.

The startup analytics guide shows how to connect what users say with whether they reached value, failed, and returned.

Do not let one large customer rent the roadmap

Large prospects create gravity. Their logo is familiar. Their contract looks substantial. Their requests arrive with meetings and deadlines.

Before agreeing, write down:

  • the revenue and learning available;
  • the share of engineering capacity required;
  • whether the capability is reusable;
  • whether it changes hosting, security, support, or compliance duties;
  • whether the rest of the target market needs it;
  • the exit cost if the customer leaves.

One customer can fund useful product work. One customer can also turn a startup into a poorly priced development agency.

YC’s guide to balancing early B2B sales describes this exact tension. Early customers teach the company what to build, yet following one or two customers too closely can produce consultancy work instead of a product.

The answer is not “never customize.” It is to know what you are buying with the customization: revenue, market evidence, reusable capability, or merely relief from saying no.

Answer without making a false promise

“Great idea, we’ll add it to the roadmap” feels kind. It creates a debt the customer may plan around.

Use a truthful answer:

I can see that the current export forces your team to rebuild the report each week. We are investigating that job with two other teams. We have not committed to a PDF export or a date. May I contact you when we have a narrower solution to test?

This response proves you understood the problem, states the actual decision, and keeps the learning path open.

Public roadmaps are dangerous when guesses look like promises. A Hacker News discussion about product roadmaps contains a useful operating rule: do not promise a feature or date at the moment the request arrives. Write it down, compare it with other evidence, and reply when the decision changes.

Run a weekly request review

Keep the meeting short. For each meaningful pattern, decide one action:

  • Fix now: a broken promise or serious risk.
  • Investigate: observe more users doing the job.
  • Test manually: deliver the outcome without committing to software.
  • Design: the evidence supports a reusable change.
  • Price separately: valuable custom work outside the shared product.
  • Decline: wrong user, wrong job, or poor trade.
  • Park with a trigger: reconsider after a named number of accounts, failures, or lost deals.

Every parked item needs a trigger. “Later” is not a decision.

After shipping, return to the people who asked. Did they use it? Did the blocked job improve? Did activation, retention, payment, or expansion change? A released feature is still a hypothesis.

The founder’s job is judgment

AI tools make the requested object cheaper to build. They do not make it cheaper to maintain, explain, secure, migrate, support, or remove.

That changes the temptation, not the decision.

Listen closely. Preserve the customer’s facts. Find the job beneath the proposed feature. Ask for commitment. Compare the request with the product promise and the work it would displace.

Then say yes, no, or not yet in plain language.

A good early roadmap is not the sum of customer requests. It is the founder’s best current argument about which problems must be solved next, written in code and tested against behavior.