the product
Use this page once per product. Copy the repository, fill the stages in order, then download the pack into that product’s docs folder. The download is the paperwork. The code comes after it.
Your answers stay in this browser until you clear them. Nothing is sent anywhere.
the need
Answer these before you open a builder. The last one is as important as the first four.
what already exists
Study what already exists before you decide your features. Look past your own city: app stores, news, and websites.
- Find several real products. Three is the minimum.
- Write each product’s features in plain words.
- Merge the lists and count how often each feature appears.
- If a feature name is vague, write one sentence so everyone means the same thing.
Existing solutions
Features you saw more than once
the gap
This SWOT is about the products you just listed. Strengths and weaknesses are theirs. Opportunities are the gaps you can prove from that research. Threats wait until you have a product of your own.
risks
A risk is something that could stop the outcome: a missing skill, a person who will not use it, a cost, a rule, a dependency. Write how likely it is, how bad it is, and what you will do about it. This is separate from the SWOT. The SWOT describes other products. A risk is about your own attempt.
how you will work
Pick the way of working from the evidence. A changing need wants short cycles. A settled need can be planned up front. If you still do not know whether anyone wants it, learn that before you build the rest.
| When this is true | Use |
|---|---|
| The requirements are clear, stable, and the technology is known. | Waterfall or incremental. |
| People need to use a slice before they can describe what they want. | A prototype, then stop and write the real scope. |
| You need a thin first release, with the customer close. | Rapid application development. Do not let the screen hide a weak core. |
| The work is large and each round has real risk. | Spiral. Revisit the risk before you build more. |
| A small team can ship often, and the needs will change. | Agile Scrum. You order the backlog and you accept the stories. |
| You still need to learn whether anyone wants this. | Lean. Build the smallest slice, measure, learn, then decide. |
who gains
List the people who use it, or who gain when someone else uses it. Rank who tries it first. Walk through that person’s day before you name a feature. Then match their side of the canvas to yours: every pain should have a reliever, or it is not your job yet.
Their side
Your side
the team
The product owner orders the work and accepts a story when the acceptance lines are true. The person who runs the meetings does not overrule that. Anyone can propose a change to this agreement.
A story is done when
- The acceptance lines are met.
- It has been tried on the real device or the real page.
- Someone else has looked at it.
- The tests that protect it pass.
- Memory, tasks, and decisions are updated.
- You accept it.
stories
Write these only after the research, the gap, and the canvas. One story is one thing a person can finish. Fill who, what they want, and why. Then write the lines that prove it, and the test.
this sprint
One goal. A week or two. Show the result. Then ask what to change. Leave the rest of the backlog outside this sprint on purpose.
look, rules, and proof
These files keep the build from drifting: how it should look, what the build must keep, the rules, who can see what, and what “working” means.
what is true today
Decisions stay decided. Memory is only what is true today. After each accepted story, update both.
Download gives you a docs folder: the need, the research, the gap, the risks, the canvas, the stories, and the rules for the build.