Taste over Execution

The belief

AI commoditizes execution. Writing, coding, designing, drafting PRDs - these are no longer scarce. The scarce thing is the upstream judgment: what to build, what to refuse, what constitutes done, and what to leave out of the PRD entirely. Taste is the discriminating function. It has not been automated, and the proliferation of generation tools makes it more valuable, not less.

How to apply

1. When starting any product decision, resolve the "should we" before the "how we." The PM job is 99 "should we build this?" questions for every 1 "can we build this?" question. The execution question is easy to answer; the taste question is the actual work. If a sprint is debating scope, the spec failed to exercise taste upstream.

1. Audit the acceptance bar before reaching for a generation tool. A model produces a plausible output by default. Plausible is not the same as right. Before prompting, name concretely what "right" looks like: the exact voice, the exact scope, the specific value. Without that standard, no taste is applied to the output - only vibes.

1. Treat scope refusal as a deliverable, not a failure. The taste-call is: does this belong at all? Saying no is the work. The PRD that ships without the wrong feature exercised taste; the one that included it did not.

1. When a generative output disappoints, interrogate your taste standard before the tool. Wrong voice, wrong scope, wrong prioritization in the output - these are almost always a reflection of an underspecified taste standard, not a tool failure. The tool averaged across a population; the taste call was missing.

1. Recognize that "delight" is a taste judgment, not a feature category. Building and measuring products is no longer the constraint. Knowing what delight looks like for this user, at this fidelity, is. No checklist produces that discrimination.

What this is not

• Not "execution doesn't matter." Execution still ships the product. The belief is about which constraint is binding: when execution is cheap, taste is the bottleneck. In environments where execution is genuinely scarce - no engineers, no runway - taste-first advice is the wrong medicine.
• Not "PM taste is unteachable." The belief says taste is irreducible, not innate. The 99/1 framing and the anti-customization discipline are learnable. They require judgment under ambiguity, but that is different from being unteachable.
• Not a claim that taste is faster than execution. When AI makes execution nearly free, the investment should shift to the thing that remains scarce. Taste becomes the rate-limiter; that is the only claim.

Argues against

• "Move fast and let the market tell you what to build - taste is something you discover in iteration."
• "Good enough shipped is better than perfect held - execution speed is the real PM discipline."
• "AI makes taste more democratic: anyone can generate a high-quality output now, so the bar has risen for everyone equally."

Where to go from here

If you want the parent theme that holds this belief alongside its siblings, go to spec-first-taste. The theme frames why the load-bearing work has migrated from doing to deciding.

If you want the process-layer version of the same claim - taste applied to what you write before building - go to spec over sprint. For the tooling-layer version - taste applied to what you give the model - go to context over prompt.

If you want the decision pattern taste most directly produces - refusing scope at the PRD layer rather than the sprint - go to anti-customization.