What Should I Build Next? A Practical Decision Framework for Product Builders
A practical way for solo founders and product engineers to choose the next build using customer evidence, product usage, and small validation tests.
Share
If you are building a product with a small team, “what should I build next?” can feel like a backlog question. It is really a decision about which user problem deserves your next slice of time. AI coding tools make it easier to ship a change; they do not tell you whether that change matters.
Short answer: build the smallest thing that removes a well-evidenced obstacle for a specific user doing an important job. If the evidence is weak, your next step is a learning test—not more code.
This guide is for solo founders, product builders, and product engineers who need a practical way to choose the next move without letting the loudest request or the newest AI-generated idea become the roadmap.
Start with the user and the job
Before comparing ideas, name who is struggling and what they are trying to finish. “Improve onboarding” is too broad. “Help a solo founder turn a customer call into a brief an engineer can implement” is specific enough to investigate.
Write one sentence:
[Person] is trying to [job] when [context], but [obstacle]. Today they [workaround], which costs them [time, effort, risk, or missed outcome].
Keep the user, situation, and workaround together. A feature request such as “add an export” might represent a need to share a report, preserve an audit trail, or move data into another workflow. Those problems lead to different solutions. Specky’s problem statement template helps turn a request into a testable problem.
Gather signals, not a pile of ideas
Collect a small set of recent signals from the people you want to serve. Useful sources include:
A person trying and failing to complete the core workflow
Repeated workarounds in support messages or customer conversations
A user returning to the same task and getting stuck at the same point
A feature request with a clear recent example behind it
A product metric that points to friction, followed by conversations that help explain it
A strategic or technical risk that could make the current product promise unreliable
A signal becomes more useful when it has context: who experienced it, what they were doing, when it happened, and what they did next. Keep a link to the original call, ticket, or event where possible. Do not turn a summary into a substitute for the evidence.
S
Specky Team
Writing about AI-native product development at Specky.
One founder discussion in r/SaaS about deciding what to build next describes using patterns in actual users’ behavior to choose changes. Another builder’s account of trusting AI’s positive idea feedback is a useful cautionary example. These are individual experiences, not representative research; use them as prompts to check your own users’ behavior.
For interview notes, see the customer interview synthesis template. It separates what someone did or said from the interpretation you might be tempted to make.
Check the evidence before ranking options
For each candidate problem, ask:
Who has it? Can you identify the role or customer segment from evidence rather than a broad persona?
When did it last happen? Can someone describe a real, recent situation?
How often or how costly is it? Does it interrupt an important job, create repeated manual work, delay a decision, or introduce risk?
What do they do today? A workaround people repeat, who maintains it, or money already spent on it can show more urgency than a compliment.
What would prove this interpretation wrong? Look for people who do not experience it, a different cause, or a simpler existing solution.
Count distinct situations and users, not just mentions. Ten notes copied from one customer are not ten customers. A single high-impact case may still deserve attention, but label it as a concentrated risk rather than broad demand.
Decide whether the next move is a build or a test
A useful product decision does not always end with a ticket. Match the next action to the largest uncertainty:
What you still do not know
Small next move
Is this a real, painful problem for the target user?
Interview people who recently faced it; ask about the last occurrence and current workaround.
Do users understand the proposed workflow?
Show a rough prototype and observe a real task without coaching.
Will anyone take a meaningful step toward this offer?
Run an honest demand test with a clear promise and a measurable action.
Can the team deliver the workflow safely and reliably?
Build a narrow technical spike with explicit constraints and failure cases.
Is the problem already well understood and the solution low-risk?
Ship the smallest complete change, then observe use and guardrails.
If you already have a prototype, the 7-day product validation plan for builders covers a focused way to test real use. It is different from declaring product-market fit: a few conversations or clicks can guide the next test, but they do not prove a market.
Prioritize without pretending a score is a verdict
When several candidates remain, compare them in plain language:
User importance: how central is this job to the target customer?
Evidence strength: do you have observed behavior and original sources, or mostly assumptions?
Reach: how many of the right users encounter this situation?
Timing and risk: what becomes worse if you wait?
Effort and reversibility: what is the smallest useful test, and how costly is it to change course?
Use these dimensions to structure a discussion, not to manufacture a precise ranking. A score of 84 is not more objective than 79 if the inputs are guesses. If you do use a scoring model, keep the source and confidence beside every score, and let a decision owner explain the trade-off.
For a backlog dominated by requests, use the deeper guide to prioritizing feature requests on a small product team. It focuses on grouping requests around the customer problem rather than counting votes or copying solutions into a roadmap.
Define the smallest useful build
Once you choose to build, write down the user outcome before the implementation details:
Target user and moment: who will do what?
Problem evidence: which observation supports the change?
Expected behavior: what should become easier or possible?
Out of scope: what tempting adjacent work will not be included?
Acceptance checks: what can a person verify in the finished experience?
Guardrail: what should not get worse?
Review date: when will you check whether the change helped?
This keeps an AI coding agent or a teammate focused on the actual problem. A clear brief can include technical constraints, but do not let the implementation plan quietly redefine the user need. When the decision is ready, the AI coding-agent PRD template and free AI PRD generator can help make the work reviewable.
A 15-minute “what should I build next?” review
Try this with your team once a week:
Put the latest evidence in one place. Keep original links and dates.
Group signals that describe the same user problem; do not merge different user types just because they used similar words.
Write the strongest problem statement and one plausible alternative explanation.
Mark what is observed, what is inferred, and what is still unknown.
Choose the next move that resolves the most important unknown: investigate, test, build, defer, or stop.
Record who owns the decision and when you will review the result.
The result might be a small release, a customer call, or a decision not to build. All three can be progress if they reduce uncertainty around an important product problem.
A prompt for using AI without outsourcing judgment
Use AI to organize your evidence, not to invent demand. Give it source material you are allowed to use, then ask:
Group these product signals by user problem. For each group, list the source IDs and the exact observations that support it. Separate observed facts, interpretations, and assumptions. Include counter-evidence and missing context. Do not invent customer quotes, sample sizes, usage data, market size, or urgency. Suggest two low-cost next tests, explain what each would and would not prove, and leave the build decision to the product owner.
Check every generated claim against the source. If the answer cannot point to evidence, treat it as a hypothesis to test.
Frequently asked questions
How do I know what to build next?
Choose the next move that best addresses an important user problem you can support with evidence. If the problem or solution is still uncertain, run the smallest useful test before expanding scope.
What should a solo founder build next?
Start with the moment where a target user reaches the product’s core value. Watch a real person attempt that task, identify the biggest obstacle, and test one focused improvement. Avoid building a broad feature set to make the product look more complete.
Should I build what customers request?
Treat requests as signals. Ask what the person was trying to do, what happened, and what workaround they use. Several requests may point to one shared problem, while the same requested feature may solve different problems for different users.
Can AI choose my product roadmap?
AI can help summarize supplied feedback, find repeated language, draft hypotheses, and compare options against criteria you provide. It cannot turn missing evidence into customer demand or own the consequences of a product trade-off. Keep source links attached and make the decision with the people responsible for the product.
Keep the decision connected to what ships
A short decision trail should connect the user problem, evidence, chosen next move, shipped change, and observed result. That gives a small team a better answer next time it asks “what should I build next?”—and helps product engineers build with customer context instead of receiving an isolated ticket. For an end-to-end sequence, see the AI product development workflow.