Daniel Cohen

How I work

Nine steps through product work

These steps help me make product decisions I can explain, test and revisit. Start where you are and return to earlier questions when evidence changes.

Open cycle/ on GitHub

Find your current question

Each step has a PM question, what AI changes for you, a prompt to copy, a check and an output. The tags under each title show the one or two things AI improves in that step: more sources, more challenge, more data or faster. Keep the output in your team's existing documents. The repository templates below are optional.

Steps 2, 4, 5 and 8 use a recipient panel: one AI reader per role, standing in for the people who will receive the work and reading it cold. Step 7 uses a red team, a single adversarial reviewer. Simulated readers rehearse questions. Evidence of demand comes from real users.

The prompts in steps 2, 4, 5 and 8 start subagents. A chat in the Claude app does not, so use the no-subagents brief once per reader in a new chat.

  1. 1Frame the problem
  2. 2Learn from users
  3. 3Define success
  4. 4Make a decision
  5. 5Scope the work
  6. 6Support delivery
  7. 7Check the work
  8. 8Prepare the release
  9. 9Measure and learn

Frame the problem

  • Improves
  • More sources
PM question
Whose problem are we trying to solve, and what do they do today?
What AI changes here
You can scan more sources in one sitting. Ask for a source link per claim and open the ones your decision rests on. A second pass then argues against your problem statement before you commit to it.
Try it
Prompt for step 1
Research this problem: [one sentence on who has it and what they do today]. List the alternatives people use now, with a source link for every claim. Mark each claim as sourced, inferred or unknown. Then argue against my problem statement and say what evidence would change it.

Problem statement: [paste yours]
What I check
I check the sources behind claims that affect the decision. Desk research identifies questions to investigate; interviews and observed behavior test them.
Useful output
A short problem statement, current alternatives and open questions.
Keep the research in a second brainGuide and project example

Learn from users

  • Improves
  • More challenge
PM question
What do real people do, and where does the task fail?
What AI changes here
You can rehearse your flow or interview guide with personas of your exact target market before you book real people. Each persona has a job to do, a context and a reason to quit, so you see where they hesitate. Keep the personas in a file and reuse them in the next build. Your interviews then go to the questions only people can answer.
Try it
Prompt for step 2
Build three personas plus one skeptic (four in total, one batch) from this exact segment: [who they are, the job they are trying to do, where and when they do it]. Give each a job to do, a context and a reason to quit. Spawn a subagent per persona. Each walks the flow below as that person and reports where they hesitate, what they expected next and where they would quit. Merge by how many personas hit the same point, then list the questions only real people can answer. Save the personas to a file for the next build.

Flow: [paste the flow, the screens or your interview guide]
What I check
Demand claims need evidence from real people. A persona's answer rehearses a question. Only answers from real people count as demand evidence. I keep interview notes separate from AI suggestions and label feedback from friends.
Useful output
Dated user evidence, a list of gaps and the next questions to test.
Where a second read changed the workGuide and project example

Define success

  • Improves
  • More data
PM question
What change would show that the work helped?
What AI changes here
AI drafts the event definitions and checks your measurement plan against the question you want answered. You find the missing events before launch, when adding one is cheap.
Try it
Prompt for step 3
The question this work must answer: [question]. Draft the success metric with its population, date range and data source. List the events I need to record. Then check my measurement plan below against the question and tell me what it cannot answer.

Measurement plan: [paste it, or write none]
What I check
I check the metric, population, date range and data source. I verify that the events are recorded before using the numbers.
Useful output
A success measure, its definition and checks on the data.
See the dashboard refresh patternGuide and project example

Make a decision

  • Improves
  • More challenge
PM question
What should we do with the evidence we have?
What AI changes here
Two checks run before the doc leaves your desk. product-sparring gives the strongest counter to the decision. A recipient panel of simulated stakeholders then reads the doc and predicts where each would stop and what each would need to say yes. Your real stakeholders still decide.
Try it
Prompt for step 4
Run a recipient panel on this decision doc. The readers are: the sponsor who decides, the engineering lead, design and finance. For each, spawn a subagent that reads the doc cold as that role and reports where they stop, their objections with the line each rests on, one fix each, and what would make them say yes. Merge the reports, fix the objections raised by two or more readers first, then tighten.

Decision doc: [paste it]
What I check
I choose the direction, name what would change my mind and set a review date. Missing evidence stays visible.
Useful output
A decision, its rationale and a test that could change it.
Challenge a plan with product-sparringRun a recipient panelGuide and project exampleUse a decision record

Scope the work

  • Improves
  • More challenge
  • Faster
PM question
What needs to change, and how will we know it is done?
What AI changes here
AI turns the decision into a first brief. Simulated readers from engineering, design and the team that will build it then go through it cold and list what is ambiguous, what they would ask in refinement and which completion criteria they could not test. You hear the likely questions before the sprint starts, then confirm them with the real team.
Try it
Prompt for step 5
Draft a brief from this decision, with the user problem, the behavior we want and the open questions: [decision]. Then run a recipient panel with three readers: an engineering lead, a designer and the team that will build it. Each reads the brief cold and reports what is ambiguous, what they would ask in refinement and which completion criteria they could not test, with one fix each. Merge the reports and revise the brief.
What I check
I check that the scope serves the goal and that the completion criteria describe something a person can observe.
Useful output
A scoped brief or issue with acceptance criteria and explicit open questions.
Turn feedback into an issueRun a recipient panelGuide and project example

Support delivery

  • Improves
  • Faster
PM question
Does the work still solve the problem as details change?
What AI changes here
AI compares each proposed change with the brief and flags where the work drifts from the goal. You answer product questions while the engineer is still in the code.
Try it
Prompt for step 6
Here is the brief: [paste it]. Here are the changes proposed this week: [paste the list or the pull request descriptions]. For each change, say whether it serves the goal, what it adds to the scope and which product question needs my answer. Draft an answer for each question that I can confirm or change.
What I check
I review changes to product behavior and resolve product questions. In Sparktale, a partner developer leads engineering; in solo projects, I also use coding agents.
Useful output
Updated requirements, resolved questions and work ready to review.
Keep requirements and decisions togetherGuide and project example

Check the work

  • Improves
  • More challenge
PM question
Does the result meet the intended behavior and quality bar?
What AI changes here
A reviewer that did not build the work attacks it. This is the red team, one adversarial reviewer with a fresh context. It looks for completion criteria nobody tested, gaps in the test plan and the likeliest ways a user fails, and you verify each finding.
Try it
Prompt for step 7
In a new chat, act as a red team. You did not build this. Read the brief and the result below. Find where the result misses the intended behavior, which completion criteria nobody tested, and the three most likely ways a user fails. Quote the line each finding rests on and rate its severity.

Brief: [paste it]
Result: [paste it, or describe how to run it]
What I check
I verify findings and walk the actual experience. AI review can find issues; usability evidence still needs people using the product.
Useful output
Review findings, acceptance checks and remaining gaps.
See the red-team agent setupGuide and project example

Prepare the release

  • Improves
  • More challenge
  • Faster
PM question
Is this ready to reach users, and what still needs a decision?
What AI changes here
AI collects the check results into one release summary. A recipient panel of simulated users from your segment then reads the release note. They predict which sentences real readers might skip, misread or worry about, so you know which to check with real readers.
Try it
Prompt for step 8
Collect these check results into a release summary and list what is still unresolved: [paste the results]. Then run a recipient panel on the release note below. The readers are: [user type 1], [user type 2], [user type 3]. For each, spawn a subagent that reads the note cold and reports what it means for them, what confuses or worries them, and one rewrite. Merge the reports and tighten the note.

Release note: [paste the draft]
What I check
I read the results and resolve remaining product decisions. Changes involving money, user data or outgoing messages need an explicit approval. The PR template has a "fit with the product doc" section.
Useful output
A release decision, a record of checks and a release note.
Run a recipient panelGuide and project example

Measure and learn

  • Improves
  • More data
PM question
Did the change help, and what should we do next?
What AI changes here
AI pulls the measures you defined in step 3, checks that populations and date ranges match, and drafts a readout against your decision. You start from the comparison and spend your time on what it means.
Try it
Prompt for step 9
Decision and test rule: [paste them]. Data: [paste it or the query result]. Draft a readout. Give each number with its unit, date range, population and filter. Say whether the result meets the rule, what it does not show, and the next decision or research question. Flag any two numbers computed on different bases.
What I check
I check comparable populations and time windows, then decide what the result supports. An unrun test stays an open question.
Useful output
A dated readout and the next decision or research question.
Adapt the metrics refresh patternGuide and project example

Optional: keep the work in files

The guides work with your existing documents. If you want my file structure, copying the repository templates takes about 20 minutes. Pick your assistant below.

Setup steps

  1. Copy templates/knowledge-base-repo into a new repo for prose: research, decisions, specs, sprints, analytics and legal.
  2. Copy templates/code-repo into your code repo for code and the docs that go stale when the code changes.
  3. Fill in the CLAUDE.md in each repo. It is the map file Claude reads at the start of every session.
  4. Save the decision record in your decisions/ folder. Name the decision owner, then write the evidence and test rule.
  5. Read the guide for each step in the cycle folder as you reach it.

Where it works

AssistantSupport
Claude CodeClaude reads each repo's CLAUDE.md at the start of a session.
Claude appThe guides and templates are plain files you attach or paste. The automatic CLAUDE.md read is a Claude Code feature.
Other assistantsEverything is markdown. Paste a guide and your notes.

Why I keep the work in files

The knowledge-base repo holds research, decisions, specs, analytics and legal. The code repo holds the code and the docs that go stale when the code changes. The rule for where a doc goes: it belongs in the code repo if it goes stale when the code changes. Each repo has a map file, CLAUDE.md, that Claude reads at the start of every session.

What side projects helped me learn

I use the cycle on Sparktale and Wellness Coach. Sparktale gave me the dated decision records, the compliance review and a kill test written before spending. Parapet supplied the habit of naming the cheapest kill test in every roadmap brief.

See also I write down what would make me stop.

Credit

These steps apply ideas from people whose work I follow: Marty Cagan, Lenny Rachitsky, Aakash Gupta, Paweł Huryn, Claire Vo and others (who they are and what I took). None of them has reviewed or endorsed this page. Any mistakes are mine.