PM is 99 Should-We Questions to Earn 1 Can-We

The belief

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. The rare "can we do it?" is the bonus question that only arrives after 99 correct answers to "should we do it?" - and that 1 is disruption. The rest is food.

This is not a difficulty claim. It is an identity claim: the role is defined by refusal and prioritization at a ratio of 99 to 1.

How to apply

1. Default to "should we?" before "can we?". When a new feature request, direction change, or scope addition arrives, the first filter is not technical feasibility - it is strategic fit. Can the team build it is a question for engineers. Whether the team should build it is the PM's call, every time.

1. Treat every PRD session as a should-we audit. The PRD is where scope fights happen on paper, not in production. Every item without a clear "should we?" answer becomes a sprint negotiation later. Settle it upstream: the hard-fought battle over customization settings belongs in the spec, not the sprint.

1. Count your refusals as output. Saying no to a feature request, an edge-case story, a stakeholder ask - these are deliverables. An invisible deliverable is still a deliverable. A PM who says no correctly is invisible because the product simply works.

1. Audit the ratio. When the ratio tips toward mostly can-we debates - feasibility reviews, effort estimates, engineering prioritization - the PM function has drifted into project management territory. The 99/1 split is a diagnostic: if you are spending less than 80% of your time on should-we questions, something has migrated the role.

1. At CEO altitude, should-we is the entire job. When you reach altitude, the can-we questions are fully delegated. The should-we questions are what remain. PM is not a stepping stone to that posture - it is a smaller-scale version of it from day one.

What this is not

• Not "avoid can-we questions entirely." Feasibility is real. Technical risk is real. The claim is about ratio and primacy: should-we comes first, and the PM owns it. Can-we is often borrowed - from engineers, architects, data teams. Should-we is never borrowed.
• Not a complexity hierarchy. The belief does not say should-we questions are harder than can-we questions. They are different in kind. The rare can-we earns its place precisely because 99 should-we calls cleared the runway for it.
• Not a formula for slow teams. The 99/1 ratio describes work composition, not process overhead. Fast teams move fast because the PM answered the should-we questions before the sprint began - not because they skipped them.

Argues against

• "Ship fast and let the market tell you what to build - the product itself answers the should-we."
• "Saying no too early kills innovation; keep the options open until you have data."
• "The PM should be a facilitator who synthesizes team input, not a discriminator who filters it."

Where to go from here

If you want the parent theme that frames this belief, go to pm-taste. The theme holds the broader case for why taste is the core PM competency.

If you want the purest expression applied to a specific decision class, go to anti-customization. Holding the line on customization is what a correctly-run 99/1 looks like in practice.

If you want the named faculty that does the should-we filtering, go to taste over execution. The 99/1 belief names the ratio; taste-over-execution names what runs the filter.