CHAPTER 02 / 13 · READ → DECIDE → BUILD
Write a brief you can test.
Turn a promising idea into a focused PRD.
Describe the outcome before the feature
A PRD explains the problem, who has it, and how the first release helps. Start with what a user is trying to accomplish today and the workaround they use. For TaskTogether, the problem is coordinating ownership of small tasks without two people unknowingly taking the same one. A feed, search box, or notification is a possible solution. Keep those choices tied to an observed need or label them as assumptions.
Use examples to reveal hidden rules
Write acceptance criteria that someone else can check. Given an available task and a signed-in volunteer, claiming it should create one claim and update the displayed state. Given an already claimed task, another volunteer should receive a clear conflict and the existing claim should stay unchanged. Include a signed-out request and a failed connection. These examples expose permission, concurrency, and recovery requirements before code is written.
Define enough and stop
Your first PRD needs a user, one useful journey, explicit exclusions, acceptance cases, and a success measure. For a learning project, successful completion of the journey by a test user is a sensible start. Do not invent interview evidence or claim product demand based on an AI-generated persona. Ask the assistant to list unresolved decisions separately. A short honest brief is more useful than a confident document full of guesses.
SEE THE DIFFERENCE
A small example. A better decision.
Users should be able to manage tasks easily.
Given an available task, a signed-in volunteer can claim it. The claim remains after refresh. A second volunteer cannot replace it and sees who has already claimed the task.
The revised requirement creates several observable checks and a clear ownership rule.
Your build steps
- Use the PRD prompt with your project charter.
- Reduce the first release to one end-to-end journey.
- Write success, conflict, signed-out, and failed-request cases.
- Review the brief yourself and mark assumptions before saving it as docs/prd.md in your project.
FROM THE PROMPT LIBRARY
A useful brief for this step.
Turn an idea into a testable PRD ↗Stops a vague idea becoming an expensive feature list.Find the real user problem ↗Separates a proposed solution from the pain behind it.Cut an MVP to one useful outcome ↗Reduces a launch scope that cannot fit the available time.All prd & discovery promptsMAKE THE CALL
Think like the reviewer.
BUILD YOUR WORKBOOK
A one-page PRD
Use the lesson and your project evidence. Your workbook saves privately; keep credentials and private records out. The checks below assess completion of the exercise, not the correctness of an external app.
Before moving on
Loading your workbook…