How do I choose one idea and define the first version?
Compare opportunities consistently, identify blockers, and scope a complete first version that tests one result.
On this page
Direct answer
Choosing a project means choosing the next worthwhile small experiment, not predicting a final winner. Compare candidates, focus, and extend from one clear result along the same users’ task chain. Examine evidence and blockers before delivery, reach and cost. An apparently precise total score cannot replace judgment. An MVP can be small, but users still need to complete the path to value.
When to use
- You have many candidates and keep postponing a start.
- The first version keeps growing and has drifted from the initial problem.
Step by step
Put every candidate in the same opportunity table
Record the opportunity, evidence location, audience, current approach, worst experience, minimum product, technical building blocks, acquisition, charging model and major risks. Add supporting evidence, the strongest counterevidence, unknowns and the next test. Leads may come from complaints, search, news, technology, existing SaaS or service orders. Missing fields are acceptable if explicit. An imagined candidate without an initial lead needs evidence before being compared with observed behavior.
Check conditions that block this round
Check whether necessary capabilities or data are available and permitted, users are reachable, output can be accepted, a required network can be started, and investment is affordable. Such blockers need not end an idea forever; save it with unlock conditions. Lack of familiarity is not automatic rejection, and “AI can write it” is not evidence of availability. Test the largest delivery risk with a minimal technical sample.
Compare evidence, user action and your advantages
Look for recent events, clear consequences, incurred costs and access to trial users. Consider your understanding of the work, reusable components and reliable delivery. Rate each dimension strong, medium or weak with evidence, without summing. When candidates conflict, prefer an inexpensive experiment that reduces the largest unknown. Focus does not require a fixed number of rejected ideas and does not guarantee the chosen one will earn money.
Define one result and its complete path
Write “help [people] in [situation] obtain [result].” Draw input -> processing -> acceptable output -> necessary feedback, adding an explicit offer and delivery confirmation when testing purchase. Integrating formatting help into an existing word-processing workflow can reduce preparation and switching; it does not imply that every idea needs a plugin. Signup, history and payment depend on the behavior under test, not a mature product’s entire feature list.
Ask which evidence would break if a feature disappeared
Classify features as required now, manually assisted or later. Retain what enables completion, verification or a valid experiment. Exclude features that merely look impressive or platform-like. A complex backend can initially use disclosed manual handling. Keep failure states and unsupported cases because they affect trust. The objective is a justified scope, not the smallest feature count at any cost.
Hand off the scope with behavioral acceptance criteria
Write a one-page specification covering users, task, input limits, output, key flow, errors, exclusions, samples and observation. Say “given this material, obtain this checkable result,” not “accurate AI and a friendly interface.” Check known samples before real tasks. A passing technical sample proves only part of the capability, not demand. Decide who will try the version and how feedback is recorded before development.
Expand along the task chain only after the core result is accepted
Describe each addition as the next obstacle faced by the same user and attach actual records. After a checking result is adopted, investigate evidence lookup only if users repeatedly need it. A feature needing a different audience or acquisition channel is a new assumption. Another product’s revenue, conversion or sharing story is not evidence for your own expansion.
Worked example
Hypothetical comparison: checking references, formatting, or all-in-one writing
Suppose A is reference checking, with a recent task and willing classmates but unknown data coverage; B is institutional formatting, with domain knowledge but no current submitter; C is an all-in-one writing platform supported only by your preference for completeness. Test a manual sample for A, interview someone about a recent B event, and return C to the lead pool. Do not declare A the winner because it scores eight. If A cannot make reliable judgments, narrow or stop that promise. All evidence in this comparison is hypothetical.
Action checklist
Reusable templates
Opportunity pool: evidence to next experiment
[Opportunity evidence and decision record]
Opportunity:
Evidence type / link / date:
Target user and trigger:
Current solution and worst experience:
Cost already incurred:
Supporting evidence and strongest counterevidence:
Smallest deliverable result:
Technical route / reusable parts / untested capability:
Acquisition channel and people actually reachable:
Possible charging model and unknowns:
Major risk and resource cap:
Blocker and unlock condition for saved ideas:
Evidence, reach, delivery and continuity: judgment plus reason; no forced total
Decision: gather evidence / smallest experiment / save
Next test and stop condition:
MVP scope and implementation handoff
[Suggested worksheet]
One-sentence result:
Assumption tested this round:
Target users and first trial participants:
Input: allowed material, amount/format and preparation
Core path: input -> processing -> result -> acceptance/feedback
Successful output: observable criteria and sample
How to explain and recover from failure or unsupported input:
Required features and reasons:
Manual handling and disclosure:
Explicit exclusions:
Offer and delivery agreement if testing purchase:
Acceptance: given [input], obtain [checkable result]
Observation, deadline, cost cap and stop conditions:
Task evidence required before expansion:
Pitfalls
- Giving unsupported assumptions high scores and letting a total create false certainty.
- Adding features to avoid inaccessible users, poor delivery or unwillingness to switch.
- Calling half a workflow a small product; users still need a complete usable result.
- Treating other people’s timelines, revenue or conversion as your own delivery deadline or operating target.