The Real Constraint in Product Development: Known and Unknown Unknowns
What we're actually trading off against isn't effort, points, or quality; it's uncertainty. Learn how known vs unknown unknowns drive friction between business, product, and engineering.
In the last article, I argued that great products aren't built by optimizing a backlog; they're built by making explicit tradeoffs.
This raises a natural question:
What are we actually trading off against?
The answer isn't effort, or points, or even quality.
It's uncertainty.
More specifically: known unknowns and unknown unknowns.
Most friction between business, product, and engineering isn't disagreement. It's people reacting to different kinds of uncertainty, without naming which ones they're dealing with.
Two Types of Unknowns That Matter
Known Unknowns
These are the risks you can name upfront.
You know there's uncertainty; you just don't have the answer yet.
Examples:
- Will customers adopt this?
- Will this performance profile hold at scale?
- Can this dependency deliver on time?
- Is this scope sufficient?
Known unknowns are uncomfortable, but manageable. They can be tested, priced, and planned around.
This is where most teams think they're operating.
Unknown Unknowns
These are the risks you don't know exist yet.
They only reveal themselves through:
- real usage
- real scale
- real failures
- real change
Examples:
- an assumption embedded deep in the system
- a workflow no one anticipated
- a scaling cliff that wasn't obvious
- an organizational bottleneck that only appears under pressure
Unknown unknowns are why plans break. They're also why rewrites happen.
Why Backlogs Are a Trap
Backlogs are good at organizing work. They are terrible at surfacing unknown unknowns.
A backlog assumes:
- problem is understood
- solution is known
- work is enumerable
Unknown unknowns violate all three.
When teams treat the backlog as truth, they optimize execution around assumptions that haven't been stress-tested yet.
That's how you end up "on schedule" and still wrong.
Tradeoffs as a Tool for Managing Uncertainty
This is where the Fast / Good / Well framework from the first article matters.
These aren't quality levels. They're uncertainty strategies.
Fast: Expose Unknowns Quickly
Fast is about surfacing unknown unknowns cheaply.
- prototypes
- spikes
- narrow releases
- temporary solutions
Fast isn't reckless; it's investigative.
Good: Stabilize What You Now Understand
Good is for known unknowns.
- core value is proven
- edges are still fuzzy
- system needs to work reliably, not perfectly
Good keeps options open while the product matures.
Well: Reinforce Where Brittleness Appears
Well is a reaction, not a default.
You build Well after:
- something breaks
- scale exposes stress
- change becomes expensive
- the business depends on it
Well exists to remove specific risk, not to feel responsible.
Why Rewrites Actually Happen
Rewrites don't happen because teams built Good.
They happen because:
- unknown unknowns were ignored
- Fast was never revisited
- brittleness wasn't reinforced in time
- debt was left invisible
Rewrites are the cost of pretending uncertainty doesn't exist.
The Real Work of Product Engineering
Product engineering isn't about eliminating risk.
It's about:
- distinguishing known unknowns from unknown unknowns
- choosing the right tradeoff for each
- revisiting decisions as evidence arrives
When teams fight over scope, quality, or speed, they're usually arguing about which uncertainties matter most right now.
Name the uncertainty, and the tradeoff becomes obvious.
That's how you move from backlog-driven delivery to outcome-driven building.