Once the development environment is ready, the next decision is which problem to work on. An initial idea often mixes goals, features, visual preferences, and technical choices. Before implementation, turn those ideas into a clear user scenario, an initial scope, and acceptance criteria that can guide design and development.
Start with three questions: Who is it for, what problem does it solve, and what should the first version do? Then follow the user's task from beginning to end to check whether the answers are specific enough.
The outcome should be a short product definition that can evolve with feedback. It should explain the core value, the complete user journey, the boundaries of the current version, and how to find out whether it solves the problem. The same process can support independent tools, AI applications, personal websites, and internal business systems. Adjust the level of detail to the project.
1 Choose a path based on how clear the idea is
People begin product work with different amounts of information. Some already know whom they want to serve, what problem they want to solve, and roughly how the product should work. Others have a vague direction and discover what they want through repeated conversations with AI. Both are useful starting points, but they call for different kinds of help.
| Starting point | A useful approach | Main outcome at this stage |
|---|---|---|
| You can describe the user, problem, and rough journey | Path A: organize, challenge, and validate the initial outline | A reviewed product definition, scope, and assumptions to test |
| The idea is vague and the user, problem, or product form is unclear | Path B: explore, compare, and narrow the idea through conversation | A provisional problem statement, possible directions, and questions to investigate |
Path A Start with an initial outline
If you have relevant work experience, a requirements outline, user feedback, or an initial feature list, give those materials to AI. Ask it to organize the reasoning, find gaps, research specific questions, and review the proposed scope.
Check whether you can explain which user task each feature serves and why it is needed. Even a detailed feature list may leave the target user or core value unclear. AI should help examine the outline and distinguish its assumptions from the evidence already available.
Path B Start with a vague idea
If all you can say is "I want to build a learning tool," "I want to improve this part of my work," or "I am interested in this problem," start with specific experiences and the changes you hope to see. You can leave the product form open and work toward a requirements outline through conversation.
Ask AI to explore a few questions at a time: When did you last encounter the difficulty? How do you handle it now? Which outcome would you most like to improve? As your answers become more specific, compare a small number of possible directions, the people each would serve, the part of the task it would address, and the evidence still needed.
For example, "an AI learning tool" might become "I cannot tell whether I understood the material after reading it." You could then compare practice questions, a discussion partner, and explaining concepts in your own words. Treat these as possible approaches and examine them through research and feedback.
Once you can provisionally describe the user, scenario, main difficulty, and desired outcome, summarize an initial outline and continue with requirements analysis. Exploration may also lead you to postpone an idea, learn more about users, or try an existing tool.
Use the two paths separately or together
A project with an initial outline can begin directly with Path A. A project still taking shape can start with Path B and move into scope definition as the problem becomes clearer. You can also move between them. Research may challenge the original user assumption and prompt another round of exploration. If the core task is clear but one scenario is uncertain, explore that part on its own.
Both paths eventually need to examine the user problem and the proposed value. A clear description developed with AI is a hypothesis you can investigate further. Research and actual use will continue to shape it.
2 Define the user and core value
Describe a specific situation
"Build an AI learning tool" gives a direction, but it does not yet define the first version. "Help people learn more efficiently" also needs detail. What are they learning? When do they need help? How do they handle the task now, and which part is difficult?
Use this sentence to draft a problem statement:
For [a specific group of users], when [a situation occurs], the current approach of [how they handle the task] creates [a specific difficulty]. The product aims to help them [complete a core task], and we will examine its value through [an observable outcome].
For a knowledge practice tool, an example hypothesis could be:
Independent learners who have just read a passage want to check their understanding, but writing questions and checking answers by hand takes effort. The product aims to turn that passage into a practice session, helping them identify what they have not yet understood through questions and explanations.
This description already helps with priorities. The relationship between questions and source material, answer feedback, and a learning recap deserve attention. Leaderboards, shareable graphics, and virtual presenters each need a separate explanation of how they help the core task.
Choose the first group of users
A product may eventually serve several groups, but the first round of validation benefits from a clear audience. Students testing themselves, teachers preparing questions, and businesses running training may all use a knowledge practice tool. Their needs for question review, saved results, and access permissions differ.
| What to clarify | Questions to ask |
|---|---|
| Target user | Whom does the first version prioritize? What is their background? |
| Situation | What triggers use? On which device and in what setting? |
| Current approach | Do they use another product, a spreadsheet, or manual work? |
| Main difficulty | Which step takes time, causes mistakes, or cannot be completed? |
| Desired outcome | What result would make this session useful to them? |
Initial answers may come from observation, work experience, conversations with users, or existing usage records. Keep unsupported answers as hypotheses for further research.
3 Combine human judgment with AI research
Record what you already know
If you have an outline, record your current view of the user, problem, rough journey, constraints, and exclusions. If you are still exploring, record specific experiences, uncertainties, and desired changes, then use conversation to clarify the scenario and problem. Even half a page gives subsequent research a direction.
People with knowledge of the setting should contribute its context. An internal tool may depend on data permissions and approval processes. A personal website may need regular content updates. A learning tool may need answers that can be traced to the source material. These conditions affect scope.
Keep this background at the beginning of the requirements document and update it as decisions change. It can restore context when you start a new conversation, change development tools, or hand over the work.
Research specific questions
You can alternate between tools with web research capabilities and conversational tools. Use research to find sources and understand existing approaches; use conversation to organize material, compare options, and draft the document. Check information that affects a decision against its original source.
Useful research questions include:
- How do people already complete the task, and where does that approach fall short?
- Which value do similar products emphasize first? What happens between opening the product and obtaining a result?
- Which features directly support the core task, and which support retention, collaboration, or charging for the product?
- Which external capabilities does the idea depend on? Do data availability, interfaces, cost, or deployment conditions affect the first version?
A competitor comparison should record concrete observations, such as the first use journey, input requirements, output format, and failure handling. A checklist of product names and features still needs an explanation of what the differences mean for the intended user.
| Comparison area | What to record |
|---|---|
| Audience and task | Whom the product explicitly serves and what it helps them do first |
| Core journey | Conditions for starting and the main steps to a result |
| Output value | Whether the user receives a file, answer, report, or completed action |
| Usage limits | Supported inputs, quotas, account requirements, and observation date |
| Relevant choices | Which decisions fit your scenario and which need reconsideration |
A competitor's feature is a possible approach to examine. Decide whether your product needs it by returning to the target user and current validation goal.
Distinguish facts from uncertainty in the analysis
AI can help suggest explanations and approaches. Examine the basis for a convincing answer by separating three kinds of information:
- Known facts: information with a source, observation, or record you can check, such as steps you experienced while using a product.
- Interpretations: explanations drawn from those facts, such as the possibility that a prerequisite increases the effort of first use.
- Hypotheses to test: judgments that still need user conversations, a prototype, or actual use, such as willingness to pay for an outcome.
For important items, record the source, observation date, and next validation step. Dates are especially useful for product capabilities, pricing, and interface limits that may change.
Assess technical feasibility and user value separately. Existing components or open source libraries can make implementation easier. Whether the product is worth building also depends on whether people have the task and why existing approaches fail to meet their needs.
4 Define the MVP around a complete journey
Find the shortest complete journey that delivers value
MVP stands for Minimum Viable Product. It delivers core value within a limited scope and helps test a defined set of assumptions. First identify what this round needs to establish, then decide how much to build.
For a knowledge practice tool, suppose the question is whether turning learning material into exercises helps people discover gaps in their understanding. A first version could support:
Enter a passage → Generate a set of questions → Answer and read explanations → Review the session recap
This journey includes input, processing, use, and a result. A question generation endpoint alone would leave part of the user's task unfinished.
You can still narrow the input. Text, documents, videos, and web pages require different retrieval and parsing work. Start with one input type and use it to complete the validation journey. A recap can initially be a results page; sharing, downloadable reports, and historical trends can be considered separately.
Decide what belongs in this version
Ask whether the core value would still hold without a feature. Also check whether it provides a necessary condition for the current round of validation.
| Decision area | Question |
|---|---|
| Core task | Can the user still complete the main task without it? |
| Validation goal | Can you still test the most important assumption without it? |
| Conditions of use | Would its absence prevent actual use? |
| Simpler alternatives | Could a simpler interface, manual step, or narrower scope work for the first round? |
A personal practice tool may initially work without saved history. If spaced review is its core task, history becomes part of the first version. Business training may require identity and saved results to record employee learning. If the current goal is to test willingness to pay, design a validation method that can observe purchase behavior.
Judge databases, knowledge retrieval, accounts, and payment against the task. Retrieval may be central when an existing knowledge base is the necessary source for answers. Decide its place in the MVP from that requirement.
Record inclusions and deferrals
A scope table should include why something is deferred and when to reconsider it. The following choices illustrate a knowledge practice tool:
| Current scope | Deferred work | When to reconsider |
|---|---|---|
| A single text passage as input | Documents, videos, and web pages | Early users need these sources and the text journey has received feedback |
| One question format with explanations | Multiple formats and generated illustrations | Different formats have a demonstrated role in the learning task |
| A recap of the current session | Sharing, report export, and historical trends | Users need to take results away or return for ongoing review |
| Individual practice | Multiplayer challenges and leaderboards | A specific shared learning scenario has emerged |
Apply the same approach elsewhere. A download tool can first test downloading from specified sources. A personal website can define what visitors need to find. An internal system can focus on one business task that can run from initiation to completion.
5 Write requirements that can be checked
Describe behavior beyond feature names
"Intelligent summaries," "a friendly interface," and "fast responses" express intentions. Add the trigger, input, output, and what happens when something goes wrong.
For each core requirement, ask when the user starts it, what the system processes, what the user receives, and how they can continue after a failure.
For example, expand "provide feedback after an answer" into:
After the user submits an answer, display the correct answer, their answer, and an explanation. The explanation should correspond to the input material. After reviewing feedback, the user can move to the next question. If generation fails, preserve the input and provide an understandable message and a way to retry.
Check the normal journey and the main exceptions: empty or unsupported input, processing, failure, duplicate submission, and whether the user needs to resume after leaving. Define the behavior for situations relevant to the current task.
Define quality for AI output
An AI requirement should explain how people will use the output and which errors would disrupt their task. For a knowledge practice tool, check whether questions are grounded in the input, the wording and choices are clear, and answers agree with explanations. For a summary tool, check for missing essential information, whether conclusions can be traced to a source, and how insufficient material is handled.
Prepare a small set of representative inputs covering normal, boundary, and failure cases. Describe the expected behavior before deciding whether numerical targets are useful. Set quality, waiting time, and cost targets for the actual scenario, and distinguish intended targets from measured results.
Check functional completion and user value separately
Functional acceptance asks whether the system behaves as defined. Can someone complete a practice session? Is input preserved after a failure? Does the recap reflect the current session?
Value validation asks whether the person has solved their problem. Can they identify something they have not understood? Would they return with new material? Why do they continue or stop? A successful demonstration establishes that a journey runs; actual use helps examine its value.
6 Keep decisions in a short PRD
A PRD is a Product Requirements Document. An initial version can be brief, recording decisions, their basis, and open questions. Use this template for a new product or an iteration of an existing one.
Product or iteration name Background and problem Target user: Triggering situation: Current approach and main difficulty: Evidence and sources: Current goal Core task the user should complete: Most important hypothesis to test: Core journey Starting input, main steps, and resulting outcome: Scope and tradeoffs Included in this version: Excluded from this version: Reasons for exclusion and conditions for reconsideration: Core requirements and acceptance Triggers, inputs, and outputs: Normal journey and main exceptions: Acceptance criteria and representative examples: Known constraints Relevant business, data, time, cost, or operating limits: Confirmed conditions and provisional assumptions: Validation plan Behavior or feedback to observe: How to test it: Results that would lead to continuing, changing, or stopping: Open questions Questions that affect scope: Questions for design and development: Decision log What changed, why, and which journeys or criteria it affects:
For an existing product, add its current behavior, the proposed change, and capabilities that must be preserved. This helps reveal whether the new requirement affects an established journey.
Store the requirements in project Markdown or a document tool suited to the collaboration. Maintain one clear current version, with links or attachments for research and longer records, so that different documents do not describe conflicting scopes.
7 Use an AI prompt suited to your starting point
The two prompts below serve different starting points. Replace the [placeholders] with your information. Write "to discuss" where you are unsure and "none yet" where you have no material.
Path A You have an initial outline
Use this when you can describe the user, problem, and rough approach and want to review and improve the requirements.
You are a product adviser with experience in product analysis and software delivery. I have an initial outline. Help me review it, improve it, and define the scope of this version. Project and stage: [Name; new product or iteration] User and situation: [Who will use it and when] Core problem and current approach: [How the task is handled now and what is difficult] Desired outcome: [What the user should complete or receive] Initial journey and candidate features: [Paste my outline] Evidence and materials: [Feedback, observations, research, competitor links, or other materials] Known constraints: [Time, budget, business, data, or operating conditions] For an iteration: [Current behavior, proposed changes, and capabilities to preserve] Please: 1. Restate your understanding of the user, core task, and value. Examine gaps and contradictions. 2. Distinguish facts, interpretations, and hypotheses. Identify the assumptions that most affect the direction. 3. Research specific questions where necessary, explaining which findings affect scope. 4. Define the shortest complete user journey. Divide features into required now, future candidates, and out of scope for now, with reasons. 5. Write a short PRD with main exceptions, acceptance criteria, and a plan to validate user value. 6. List questions for the subsequent design and architecture stage. Working agreements: - Challenge my outline where appropriate. Identify what could be simplified, changed, or dropped. - Do not automatically turn candidate features or competitor features into current requirements. - If missing information would materially change the user, core value, or scope, ask up to five focused questions first and wait for my answers before settling the affected conclusions. - For other uncertainties, state provisional assumptions and continue the parts that can be completed independently. - Give sources and checking dates for external research. Mark unverifiable claims for checking; do not invent feedback or data. - This task is product definition. Leave detailed technical design and coding for a later stage. Organize the output as project understanding and key questions, evidence and assumptions, core journey, scope decisions, a short PRD, and validation and handoff.
Path B You have a vague idea
Use this when you want conversation to help uncover the problem and compare possible directions. A rough idea or one actual experience is enough to begin; other fields may be left blank.
Act as a product exploration partner. Help me gradually clarify what I want to build through a conversation. My idea is still vague. I cannot yet fully define the target user, product form, or features. Current idea or interest: [Describe it in your own words; fragments are fine] Related experience or observation: [A recent difficulty, a work problem, or something you noticed] Desired change: [What you hope would become different for yourself or others] Known conditions or preferences: [Fill in what you know, or leave blank] Please work with me as follows: 1. Briefly restate your understanding, then ask only one to three useful questions per turn. Wait for my answers before continuing. 2. Explore specific experiences, current approaches, difficulties, and desired outcomes. Offer accessible examples when they would help me explain. 3. Once there is enough context, suggest two or three possible directions. Explain whom each serves, which problem it addresses, and what still needs testing, so I can compare them and respond. 4. After discussing a topic, briefly summarize what is clear, where we disagree, and provisional assumptions. Let me revise or reject them. 5. Once we can provisionally describe the user, situation, problem, and desired outcome, prepare a one-page exploration summary. Check that it represents my intention before moving into research and MVP scope. Working agreements: - Do not begin by asking me to complete a full requirements form or by producing a complete PRD or feature list. - Do not present your suggestions as my decisions. Do not invent user needs or market validation. - Allow the direction to narrow, change, or be postponed. Mention existing tools if they may already meet the need. - Research specific external questions when necessary and give sources. Clearly mark information you cannot verify. - Focus on the problem and value at this stage. Leave detailed technology choices and coding for later. Use my starting information to ask the first round of questions.
Annotate the document and keep the reasons for changes
Whichever path you use, once there is an exploration summary or requirements draft, you can comment directly in the document:
[TODO] The audience is too broad. Separate the scenarios and suggest which group to prioritize. [CHECK SOURCE] Where does this limit come from? Verify it before excluding this input type. [SCOPE DECISION] Support text first. Keep other inputs as future candidates. [ACCEPTANCE NEEDED] Which examples and checks define a good explanation?
Ask AI to revise from those comments and check that related scope, journeys, and acceptance criteria change together. Incorporate confirmed decisions into the current text, keep unresolved matters as open items, and record the reasons for decisions that affect scope.
When a new idea appears during development, examine how it affects the current core task. If it changes the goal of this version, update the requirements and acceptance criteria together. Otherwise, keep it as a future candidate. This allows new learning while preserving a clear completion boundary.
8 Check readiness for the next stage
Before moving to Architecture & Contracts, you should be able to explain whom the first version serves, which task it completes, and why you chose the current scope. You should also have a complete journey, explicit exclusions, acceptance criteria you can apply, and a way to examine user value.
If the input, task duration, or use of data may make the core journey infeasible, run a small feasibility experiment and adjust the product definition from its results. Resolve questions that affect direction first; implementation details can be addressed in the next stage.
Hand over confirmed requirements, assumptions still to test, and constraints. Examples include which results need to be saved, whether people must continue across devices, acceptable waiting time, and what happens when an external capability is unavailable. The next stage can use these inputs to discuss technology choices, data models, and interface contracts.
Product definition continues to evolve with usage feedback. Clear context, scope, and decision records help each change answer the same question: How does this help the intended user complete the task that matters most now?