Chapter 48: The Myth of Common Sense

Last updated on 
Share
Chapter 48: The Myth of Common Sense

The Scapegoat of Incomplete Specifications

Few phrases in product management are as destructive as "Just use common sense."

It typically surfaces during post-mortems or requirement breakdowns, deployed by managers looking to shift blame. When a feature fails to meet unstated expectations, the leadership team hides behind the assumption that the correct path was "self-evident" and that anyone who missed it lacks fundamental competence.

This reasoning relies on a fatal flaw: the belief that "common sense" is a universal, pre-installed software package shared by all human beings.

In reality, mental models are built from disjointed inputs—different cultural backgrounds, education, past engineering traumas, and domain contexts. What is self-evident to a senior solution architect who has spent fifteen years in payments is an opaque riddle to a junior developer or an outsourced contractor.

The Four-Fruit Taxonomy Paradox

In clinical psychology, classification tests are used to evaluate cognitive abstraction. A patient is given four items and asked to remove the "odd one out."

  • The Trivial Case: Sparrow, Pigeon, Titmouse, Automobile.

The "common sense" answer is obvious: the automobile is an inanimate object, while the rest are living birds.

When managers delegate tasks, they assume their requirements look like the trivial case. In modern product development, however, real-world requirements almost always resemble the Four-Fruit Paradox:

Selection Set = {Orange, Quince}, Watermelon, Pear}

If you ask four intelligent engineers to pick the "odd one out" using their own "common sense," every single choice is 100% logically defensible:

  1. Orange: The only tropical fruit in the set.
  2. Quince: The only fruit with an astringent, tart taste profile requiring preparation before consumption.
  3. Watermelon: Botanically, the only berry (pepo), whereas the others are traditional tree fruits.
  4. Pear: The only fruit with a distinct pyriform (bottom-heavy, non-spherical) geometry.

If a manager fails to specify the classification criteria, four different engineers will build four completely different solutions—and each one will be strictly logical under their chosen framework. Calling one engineer "wrong" because they focused on botany instead of geometry is not management; it is arbitrary punishment.

Pragmatic Task Handoff Rules

To eliminate the "common sense" trap without creating suffocating bureaucratic overhead, apply three operational principles:

  1. Calibrate Context to the Specific Receiver: Eliminate ambiguity based on the individual's experience level. Do not waste time lecturing a veteran on basic primitives, but never assume a newcomer understands internal domain shorthand.
  2. Reward Clarification over Blind Assumptions: When an engineer encounters a gap in a specification, the default behavior must be to stop and ask—not to guess what the manager's "common sense" might be. If a team stays silent and guesses wrong, it indicates a culture where asking questions is penalized.
  3. Never Punish Ambiguity Failures: If a task fails because a requirement was ambiguous, the fault lies with the handoff protocol, not the executor. Punishing an engineer for choosing "Pear" when you wanted "Watermelon" guarantees they will become risk-averse and passive in future iterations.

Communication is the only protocol that bridge gaps in mental models. Explicit constraints build reliable systems; reliance on "common sense" builds shelfware.