How do I know what to build next? A practical answer for SaaS founders
Published July 29, 2026 · Updated August 10, 2026 · Hub: Product prioritization hub
Monday standup. Three ideas on the whiteboard. A customer email from Friday. A competitor launch on Twitter. Your engineer asks what the priority is—and you realize you do not have a defensible answer. You have opinions.
That stuck feeling is the point of this page. Not another brainstorming prompt. A way to get unstuck this week without pretending you have perfect data.
For the full operating framework—capture systems, scoring, decision briefs end-to-end—see how to decide what to build next for your SaaS. Related hubs: product prioritization, solo founders.
Why you feel stuck
Three forces collide:
- Too many inputs — feedback, metrics, competitor launches, investor suggestions, your own ideas
- Too few decision rules — no shared definition of “important”
- Too much sunk cost — half-started projects and emotional attachment to old bets
Roadmap theatre follows: a slide that looks confident and a team that still argues every week. More ideas make it worse. Shipping stays busy while metrics stay flat, and nobody can explain last quarter’s choices.
What does not unstick you
- Another brainstorming session
- Ranking by who asked loudest
- Copying a competitor’s changelog
- Waiting for “enough analytics”
- A prettier roadmap tool with the same unclear constraint underneath
Those activities feel like progress. They rarely produce a bet you can defend on Friday.
A diagnostic you can run in 30 minutes
You do not need a research team. You need a loop you can finish before the next standup.
1) Name the constraint (not the feature)
Write one sentence: what is limiting growth right now?
| Constraint | Typical signals |
|---|---|
| Activation | Users sign up but never reach “aha” |
| Retention | Early users churn after week 2–4 |
| Monetization | Trials stall, pricing objections, low expansion |
| Reliability | Incidents, slow support, trust erosion |
| Differentiation | Win/loss notes cite “we all look the same” |
If you try to optimize all five, you optimize none.
2) Use messy data you already have
Support tickets, sales notes, churn free-text, onboarding drop-offs, a handful of conversations. Tag by job and segment. A few high-severity reports from core customers outweigh many low-severity requests from edge cases.
3) Frame candidates as decisions
Every “what if we built X” needs: segment, problem/job, smallest proposed change, evidence, constraint link, and a 30-day success line. No evidence line means discovery—not build.
4) Pick one primary bet and one backup
Prefer the change that ships in weeks, has a clear metric, and teaches you something even if the solution is wrong. Ask what would make you more certain in 14 days.
Do this today
- Write your constraint in one sentence
- List at most ten competing ideas
- Cross out anything that does not hit the primary constraint
- Add one line of proof to each survivor
- Pick one bet + one backup
- Write success criteria before anyone opens a PR
Share those six lines. That is the decision for the week.
When everything still feels important
Map every candidate to one constraint. Keep only the primary. Defer the rest with a revisit date. If items still tie, prefer ICP evidence over loud wrong-fit users, blockers over nice-to-haves, and smaller bets over platform rewrites.
With little quantitative data
Severity, segment fit, recurrence, and constraint tie-in beat empty dashboards. Five interviews repeating the same activation confusion beat 200 signups with no behavioral insight.
Common mistakes
Building because competitors shipped. Parity is a tax—pay it when win/loss says you are losing deals.
Building because one big customer asked. Still ask whether it helps the next ten ICP customers.
Confusing activity with progress. Measure constraint movement, not ticket count.
Never killing bets. If success criteria miss after a fair window, write a kill note and move on.
FAQ
How do I know what to build next with little data?
Use messy data you already have: support tickets, sales objections, activation drop-offs, churn reasons, and interview notes. Patterns beat perfect analytics.
What if everything feels important?
Name each idea to one constraint. If it does not reduce activation, retention, monetization, reliability, or differentiation right now, it is later—not urgent.
How often should I revisit what to build next?
Revisit weekly as evidence arrives. Re-communicate the roadmap when priorities actually change, not because the calendar says “planning day.”
When the diagnostic is not enough
This works on paper for a while. It breaks when feedback, prior decisions, and success criteria live in different places—so every week restarts from opinions again.
When product memory is intact, “what to build next” becomes a review of what you already know instead of a scavenger hunt before standup. That is the loop Caret is built for: capture → insight → product decision briefs, with an AI product brain that keeps evidence attached to every bet.
If you want next week’s diagnostic to start from memory instead of a blank page, start a trial and drop this week’s feedback into a project.