Text guides

Product planning

Turn an idea into a small, testable piece of work. State what users need, what the first version includes and how to check it.

12 practical tasks. Each guide includes a sample request and a way to check the answer.

Write a product problem statement from evidenceA problem statement says who is trying to do what, what stops them, and how you know. Use it to focus a feature discussion. If a sentence prescribes a button, screen or tool, check whether it names a solution before explaining the problem.
Sort feature requests by the problem they describeGroup requests by the task the person is trying to finish, not by the feature they named. Different wording often describes one problem, and one wording can hide two. Record what you know and what you still need to ask.
Choose a workable first release for a product ideaA first release gets smaller by dropping features, not by dropping steps the user needs. Pick one task a person can finish from start to end, list every step it requires, and cut only what sits off that path.
Turn a feature brief into acceptance criteriaAcceptance criteria describe what someone can observe after a user acts, not how the system works inside. For each behavior in the brief, write the starting condition, the action, the visible result and what happens when something goes wrong.
Map dependencies before setting a product dateA date is only as firm as the inputs behind it. List each task, what must be finished or decided first, who owns that prerequisite, and what proof shows it is ready. Then look for loops and for prerequisites nobody has confirmed.
Explain a feature tradeoff in one pageA tradeoff note lets someone who missed the discussion see what was considered and why one option won. Name the options, state the constraints, cite the evidence, record the decision, and say what would make you reopen it.
Make a release checklist around actual user tasksList the tasks a person needs to finish with the feature, then check each one in a working build before anyone announces it. For every task, record what you tested, what you saw, what remains open and who decides whether the release goes ahead.
Write a product demo that shows one real workflowPick one task that works today and show it from start to finish. Write the script so a viewer can see the starting state, each real step and the visible result. End with a plain statement of what the demo does not cover.
Draft a feature announcement from confirmed changesBegin with the changes that are confirmed and live, then state who can use them and how to start. Add the known limits in the same message. Leave out plans, hopes and anything that depends on unfinished work.
Ask beta users for feedback on a specific workflowAsk what the person tried to do, what happened and what they did next. Tie the questions to one workflow and a particular attempt so you can trace the answer to a problem. A general opinion question may need follow-up before it explains what went wrong.
Define a useful success check for a product experimentWrite down what you expect to happen, what you will observe, where the data comes from and how long you will watch. Then state which result would lead you to continue and which would lead you to stop, before you look at any numbers.
Draft a factual notice for a retiring featureState the date the feature ends, what will stop working and what users can do before then. Give the steps for keeping their data, name any approved alternatives and say where to ask questions. Use only what the approved plan confirms.

Related topics