What if users are asking for lots of different things?

That usually means one of: your ICP is too broad (wrong-fit users), your product promise is unclear, or you’re missing a core workflow step that makes the product feel incomplete. Look for patterns in outcomes, not in features. Many different requests can point to the same underlying job.

How to decide what to build next for your SaaS (without guessing)

Q: What if competitors have a feature we don’t?

Ask two questions: Is that feature actually driving their growth, or is it table stakes? Would building it improve our constraint right now? Competitor parity is a tax. Pay it only when it reduces churn, removes sales friction, or unlocks distribution.

Q: What if we have no data?

You always have data. It’s just messy: sales calls, support tickets, churn reasons, activation confusion, win/loss notes, user interviews. Write it down, categorize it, and make decisions from patterns—not from the last conversation you had.

Published April 9, 2026 · Updated August 10, 2026 · Hub: Product prioritization hub

If you are building a SaaS, “What should we build next?” never goes away. It just changes clothes:

this feature request or the churn fix?
a competitor checkbox or deeper onboarding?
rebuild the messy path or add an integration?
do we need a roadmap—or do roadmaps make us worse?

The scary part is rarely that you have no ideas. It is that every option sounds reasonable and you lack a reliable way to choose under incomplete data, loud feedback, and quiet churn.

This is a decision system for that reality. For a shorter stuck-week diagnostic, see how do I know what to build next?. Hubs: product prioritization, solo founders.

What this question is really about

Most teams treat “what to build next” like a backlog problem. It is a strategy and learning problem. When you choose, you are choosing:

which customers you say yes to (and not now)
which risk you reduce next
which narrative you can sell
which trade-off you will live with

The useful bar is not “did we ship something.” It is whether the next 2–6 weeks change your trajectory.

Why most prioritization fails (even when it looks structured)

You optimize for loudness, not leverage

Tickets and DMs feel like certainty. They are often edge cases, personal workflows, or symptoms. You can ship what they asked for and still miss the underlying problem.

You treat “users want it” as “it will move the business”

Desire is signal. It is not a decision. People can want something and never churn, never pay, or only want it because they misunderstood the product.

You build to solve non-build problems

Sometimes “build X” really means fix positioning, pricing, onboarding copy, distribution, or expectations. Building harder on the wrong layer wastes months.

You do not write the reasoning down

Without a decision record, debates repeat, assumptions stay invisible, and six weeks later nobody remembers why you shipped it.

A framework that survives incomplete data

Pick the constraint limiting growth now
Name the risk you must reduce (a sentence that could be false)
Define the outcome (metric or proxy + timeframe)
Choose the smallest bet that can change your mind

Step 1: Identify the constraint

Activation, retention, monetization, reliability, or differentiation. Acquisition issues often show up as differentiation or monetization once you look at win/loss. Pick one primary constraint—two at once usually means none.

Step 2: Convert it into a testable risk

Example: activation → “New users do not understand the product in the first three minutes.”

Step 3: Define the outcome

Measurable, time-bounded, linked to the constraint. Proxies are fine if instrumentation is weak. Do not wait for perfect analytics to start deciding better.

Step 4: Build the smallest bet that can change your mind

A guided first-run, one integration, one reliability failure mode, one packaging change—not a twelve-week rewrite. If it cannot change your mind, it is busywork.

Feature requests without becoming a feature factory

Capture who, goal, friction, and consequence—not just “add X.”

For any request, write three interpretations:

A: they need the feature as described
B: they need a workflow outcome (feature is one path)
C: they are confused about existing product (clarity fix)

Often B or C is higher leverage. See should I build what customers ask for?.

A score that does not lie (as much)

After the constraint is written, score alignment, reach, impact, confidence, and effort. Keep it simple. Confidence of 1 means discovery, not build. Huge effort means split the bet. Details: how to prioritize features, RICE.

The decision doc

One page: constraint, risk, outcome, bet, why now, what you are not doing, how you will evaluate. This is how decisions become learnable.

Example

1,200 signups/month, weak paid conversion, “looks cool but not sure how to use it.”

Constraint: activation
Risk: users do not reach value fast enough
Outcome: first-session aha from 18% to 28% in four weeks
Bet: guided first-run + one opinionated template
Not doing: integrations sprint
Evaluate: events + user calls + cohort check

Even if you miss the number, you learn something specific.

Sometimes the right next build is not building

Removing options, rewriting onboarding, narrowing ICP, or fixing trust can beat another feature. Ask whether the change increases clarity, reduces friction, or increases trust for the users you want.

FAQ

What if users ask for lots of different things?

ICP too broad, unclear promise, or a missing core workflow step. Pattern on outcomes, not features.

What if competitors have a feature we don’t?

Is it driving their growth or table stakes? Does it hit your constraint now? Parity is a tax.

What if we have no data?

You have messy data: calls, tickets, churn reasons, win/loss, interviews. Write it down and decide from patterns.

The part teams usually skip

The framework only works if inputs stay organized enough for patterns to emerge. Most teams already “know” they should decide from constraints and evidence. What breaks is the operating system underneath: feedback, quotes, churn reasons, and “we should…” notes live in too many places, so every planning cycle starts cold.

That is the gap Caret closes: one product memory where captures become insights and opportunities, and the next bet keeps the evidence attached—so “what should we build next?” is a review of what you already know, not a new debate.

If you want that memory for your SaaS, start a trial and run the next decision cycle inside Caret.