--- name: product-decisions-checks description: 15 rules from the Noesa course "Product decisions, understood". For founders, product managers, designers, and developers using AI to build features who need to decide what should exist and how to know it works. --- # Product decisions, understood — the rules Use with: Claude Code or Claude (save as a skill), Cursor (save under .cursor/rules as .mdc), ChatGPT or any other assistant (paste the text below into custom instructions or a project's instructions). 15 rules, taken from the course at https://noesa.leafsoft.online/c/product-decisions Each heading is one thing the course teaches. Most are checks to run on your own output before presenting it as done; a few are background you are expected to have. 10 also name a mistake models make by default, under "Watch for". Apply these to the thing you are producing — the type, the schema, the query, the copy — not only to how you explain it. Where a rule names a field, a format or an identifier, that name belongs in the output. ## Name the problem before the solution Rewrite a feature request as a problem statement with a user, situation, struggle, and consequence. **Watch for:** If you ask AI to turn a feature request into a plan, why might it skip problem discovery? The request supplies a solution-shaped pattern, so generation tends to complete that pattern with requirements and screens. The missing customer context is not visible. Check that the plan begins with an observed problem and evidence, not a polished restatement of the request. ## Identify the user and job Name a specific user and the progress they are trying to make in a particular situation. ## Separate symptoms from root causes Distinguish a visible symptom from a supported cause and select evidence that could separate competing explanations. **Watch for:** Why might AI present one tidy root cause when the record contains only a symptom? Common product narratives pair familiar symptoms with familiar fixes, while your local behavior is absent. Generation can fill that gap with a plausible cause and false confidence. Require competing hypotheses and evidence that could distinguish them. ## Write outcomes, not features Define a behavioral outcome with a population, direction, measure, and time window. ## Find the riskiest assumption List an idea's assumptions and identify the one whose failure most threatens the intended outcome. **Watch for:** What happens when AI turns a short idea into a complete requirements document? The document's completeness can make unstated assumptions look like confirmed requirements. Generation defaults to filling familiar gaps, but it lacks your evidence. Extract every claim that must be true and rank it before treating generated detail as a decision. ## Decide what evidence would change you Define a decision threshold and name evidence that would support, weaken, or overturn an assumption. **Watch for:** If AI summarizes interviews as “strong demand,” what must you inspect before accepting that judgment? “Strong” can hide the sample, question wording, contradictory behavior, and the threshold your product chose. A generated summary defaults toward a coherent pattern and may compress dissent. Check the source notes, counts, and disconfirming cases against the prewritten rule. ## Compare opportunities before prioritizing Compare product opportunities using consequence, frequency, confidence, and strategic fit without collapsing them into a false precise score. ## Define the smallest useful test Design a test that isolates one risky assumption with a real behavior, threshold, and limited exposure. **Watch for:** Why might an AI-generated “MVP plan” still be a poor test? Common plans minimize feature scope, not uncertainty. Without your riskiest assumption and decision threshold, generation may propose a smaller product that produces no decisive evidence. Verify that every retained element supports learning, safety, or the measured behavior. ## Read behavior, not compliments Rank product evidence by its distance from the target behavior and identify what each source cannot prove. **Watch for:** An AI turns mixed user research into an upbeat summary. What goes missing? The distance between words and behavior, the constraints at each step, and contradictory cases can be compressed away. The common summary pattern favors one coherent conclusion. Keep evidence types separate and inspect the behavioral drop-offs yourself. ## Design constraints and edge cases State product constraints and trace edge cases through trigger, state, user consequence, and recovery. **Watch for:** An AI lists the edge cases for your feature. Why does the list look complete and still miss the ones that hurt you? Generation defaults to common product patterns, while consent rules, queued states, owner policies, and local consequences may be absent from context. Trace your real state transitions and people affected; list length is not coverage. ## Make trade-offs visible Compare options by naming who gains, who pays, what is reversible, and which value the choice protects. ## Define quality before building Write a quality contract with outcome, behavior, boundaries, evidence, and release gates. **Watch for:** Why can AI produce technically correct work that still fails your quality contract? Generated implementation follows supplied specifications and common patterns, but your outcome, consent boundary, stale-state rules, and recovery expectations are local context. If those are absent or vague, working code can optimize the wrong definition of done. Review every output against explicit gates. ## Decide what not to build Reject, defer, or remove a feature with a reason, revisit trigger, and protected outcome. ## Learn from a failed release Compare expected and observed behavior, locate which assumption failed, and choose a proportionate response. **Watch for:** An AI writes your release retrospective from tickets and delivery numbers. What will it never conclude? Those inputs describe implementation and operations, not your prewritten outcome or the time owners need to refill a slot. Generation may default to execution fixes because that evidence is visible. Compare the result with the decision journal and user consequence before accepting the diagnosis. ## Direct AI from problem to proof Brief AI with a decision record, inspect its proposal against evidence and gates, and accept, revise, or reject the work. **Watch for:** Why should the same AI that generated a proposal not be the only judge of whether it meets your decision brief? Its review can repeat the same common-pattern assumptions and missing context that shaped the proposal, then express agreement with false precision. Use the independent decision record, observed evidence, product checks, and accountable human review as the acceptance standard.