PM taste as risk mitigation. The irreducible skill AI cannot replace.

Building and measuring products is no longer the binding constraint. Writing, coding, designing, drafting PRDs: these are no longer scarce. The scarce thing is the upstream discrimination. Scope judgment under ambiguity, the refusal that prevents a six-month detour, the acceptance standard that saves two rounds of remediation. When AI can execute anything, the binding constraint is taste: knowing what to build, what to refuse, and what counts as done. That discrimination has not been automated. The proliferation of generation tools makes it more valuable, not less.

Taste is not aesthetic preference. In the PM context it has three specific forms: knowing which features belong in the product and which are scope debt in disguise, knowing which trade-offs to take versus defer, and knowing which integrations to accept versus refuse before they become the customer's implementation burden. All three are judgment calls. None of them show up in a velocity metric.

The 99/1 structure of PM work

Product management is a discrimination function. The work is 99% selection: deciding what not to build, which direction not to take, which request to decline before it reaches the sprint. The rare "can we do it?" question is the bonus that only arrives after 99 correct "should we do it?" calls cleared the runway.

This is not a difficulty claim. It is an identity claim: the PM role is defined by refusal and prioritization at a ratio of 99 to 1. When AI handles the execution layer cheaply, that ratio becomes more visible, not less. The PM who delegates taste to velocity signals to the organization that the role is a project coordinator. The PM who owns the 99 refusals upstream is the one whose team ships correctly at speed, with fewer late-stage surprises, lower rework cost, and cleaner SLA performance.

At enterprise scale, taste is explicitly a risk-mitigation function. A product scope that includes aggressive customization options commits the customer to a six-month implementation engagement, an implementation partner, and hundreds of training documents before day-zero go-live. A PM who exercised taste upstream and refused that scope during PRD review prevented a customer success failure and protected the margin. A PM who deferred that call to the sprint team shipped a liability.

The acceptance standard before the generation tool

Execution is cheap when AI is in the loop. The trap is reaching for the generation tool before the taste standard is specified.

A model produces a plausible output by default. Plausible is not the same as right. Before prompting, the PM names concretely what right looks like: the exact voice register, the exact scope boundary, the specific value proposition, the features that are deliberately excluded and why. Without that standard, no taste is applied to the output. The model averaged across a population; the taste call was not made. The result is an output that requires multiple remediation rounds to close because the acceptance bar was never specified upstream.

This pattern repeats at three altitudes:

• At the PRD layer: should we build this at all?
• At the generative tool layer: what does right look like before I generate?
• At the demo layer: does this qualify as production-grade or is it still a POC with good lighting?

All three require taste. None of them are answered by a faster iteration cycle.

Scope refusal as a deliverable

Saying no is the work. The PRD that ships without the wrong feature exercised taste; the one that included it did not. Scope refusal is an invisible deliverable: when the PM gets it right, the sprint never debates the question because it was already resolved. The engineering team ships faster. The customer does not hit a hidden implementation tax. The sales team closes without a last-minute scope negotiation.

The visibility problem is real. And worth naming. A PM who says no correctly is invisible because the product simply works. The sprint team does not have a war story about the scope debate that never happened. Hiring committees at top-tier enterprise companies evaluate this explicitly: they look for evidence that the candidate understood what not to build, not just what shipped. A portfolio built entirely around features shipped signals a feature-factory PM. A portfolio that includes explicit scope refusals, with the reasoning, signals a PM who understands that taste is risk mitigation.

The forward question

Product management was, is, and will continue to be about taste: what to build and what to leave out. The AI-era version of that claim is sharpened, not softened. When execution is free, the only thing that differentiates a PM is judgment quality upstream. The PM who offloads the execution and keeps the taste is applying this correctly.

What I find genuinely uncertain is how taste gets transmitted at scale. Individual taste is developed through pattern recognition across dozens of scope calls, dozens of refusals, dozens of post-mortems. But most teams don't have a shared vocabulary for scope refusal decisions. The interesting frontier is not automating taste. That is not coming. But building the institutional substrate that makes a team's aggregate taste explicit and auditable. A PRD that records not just what was approved but what was rejected and why is one version of that substrate. It is underused.