Observe the world
Product design: does it hold up?
System design's constraints are objective, so the reasoning converges. Product design's constraints are people and money — just as fixed, but they don't point at a single answer. So these have no model answer, only whether they hold up.
These prompts only exist in 简体中文 for now.
How to use this
There is no model answer here — but there are definite wrong answers. Only three things make a case hold up, and every prompt's answer key carries a "common wrong answers" section that is more useful than the checklist itself.
The three things that make it hold up
- You can say whose problem this is and what it is — **with evidence** (not "I think users would want it")
- You can say what success looks like — **and what that number is today** (no baseline, no acceptance criteria)
- You can name the cost and what you gave up — **the hardest one to fake**, which is why every prompt hunts for it
How to start
- Pick a question, open it, copy the prompt.
- Paste it into a brand-new conversation — not one where you already discussed it.
- Say nothing. Wait for its first question.
Four commands you can call out at any time
跳过move to the next scene now提示give a direction, not the answer直说吧spell this point out in full, then keep pressing on the trade-offs复盘jump to the wrap-up and print the review card
Three traps
- Don't rush to a solution. More than half the lost points here come from designing before asking — especially describing features before defining what success means.
- Expect to be pushed for numbers. "It'll perform better", "users will like it" get cut off: which metric, what is it today, and when do you look?
- When it starts praising you, point it back to rule five — feeling validated crowds out noticing what you missed.
Start with the north star metric; it underpins everything else. Then pick by what's on your plate: a backlog you can't order → prioritisation; nobody using it or retention sliding → retention and onboarding; need to price something → pricing. Save the experiment review for later, and keep redoing the one about turning a one-line request into a spec — it's the closest to daily work.