Skip to content
MyDSHMy DSH Field Notes
中文
Independently maintained; not affiliated with DeepSeek. No association with mydsh.dev or other MyDSH sites.

All categories/Product and design

Requirements and product · Level Advanced · Product Acceptance Product

Acceptance criteria: pass or fail

The feature shipped and it is not what was meant.

Prompt

Ask what happens if we do not build it, then who uses it and how often. If those have no answer, it does not get scheduled.

Task: The feature shipped and it is not what was meant.

[Before you start, do three things]
1. Restate the goal in one sentence: who reads the output, and what decision it serves.
2. If I have not given you the following, ask me. Do not assume:
   - the goal
   - key scenes
   - edge cases
   - who accepts
3. Say how you plan to do it (at most 5 steps) and wait for my go-ahead.

[Go through each of these]
- each criterion as an action with an expected result
- cover normal, error, edge
- no subjective criteria
- the one item most likely to be missed

[Process]
1. Reconstruct what the user actually does
2. Decide whether this is a need or a proposed solution
3. Offer build, do not build, or another way
4. Write checkable acceptance criteria
5. Mark the risk and reversibility

[Output]
Problem, judgement, options, acceptance, risk.

[Do not]
- Never copy the requester's solution
- No scheduling without a usage scene
- No acceptance criteria like 'improve experience'
- Never three features at once

What to state before it starts

Leave these unsaid and the model fills them with an assumption. Most 'wrong answers' start here.

  • the goal
  • key scenes
  • edge cases
  • who accepts

Go through each of these

Where this kind of work most often goes wrong. Already in the prompt, so you do not have to remember it.

  • each criterion as an action with an expected result
  • cover normal, error, edge
  • no subjective criteria
  • the one item most likely to be missed