The PM’s Anti-Pattern: Using “Requirements” to Avoid Thinking

There’s a tempting PM move when things are messy: write more requirements.

Long PRDs, exhaustive acceptance criteria, pixel-level rules—these can feel like “clarity.” Often they’re the opposite: they hide uncertainty behind documentation.

This is the anti-pattern: using requirements to avoid thinking.

Here’s what it looks like:

• specs that describe a solution before the problem is understood
• “must-have” lists that are really stakeholder wishlists
• detailed UI directions written before design exploration
• requirements that try to predict every edge case up front

Why it fails:

• it kills exploration early
• it creates false certainty
• it turns design into execution
• it makes engineering optimize for compliance, not outcomes

A better approach is to separate three things:

1) Requirements as constraints

These are non-negotiables:

• legal/compliance
• performance/security
• hard platform limitations
• business rules that must be true

Keep these crisp and explicit.

2) Requirements as outcomes

These are success conditions:

• “Users can complete task X in under Y minutes.”
• “New users reach value within Z steps.”
• “Error recovery is possible without support.”

Outcomes guide design without dictating it.

3) Requirements as decisions

This is where a “spec” should focus:

• what we chose
• why we chose it
• what we’re not doing
• what risks remain

The spec becomes a decision record, not a pre-design blueprint.

In interviews, a strong line is:

“I use documentation to capture decisions and constraints, not to pre-solve design. If we’re writing requirements to feel safe, we’re usually skipping the real work: exploring, testing, and deciding.”

That signals maturity—and it’s exactly what great designers want in a PM.