A product rarely becomes hard to use in one dramatic moment. It gets there through reasonable decisions made by people under pressure.
- Sales promises a workflow to close a deal. A team adds a “temporary” custom setting for one enterprise customer. Six months later, every plan tier has slightly different behavior and nobody can explain the rules cleanly.
- Engineering forks a shared component to meet a sprint deadline. Design accepts a one-off pattern because there is no time to reconcile it with the rest of the system, then 2 months later has to explain why two identical-looking controls behave differently.
- Growth adds an onboarding modal to improve activation. Support sees more tickets because users now skip the setup page the modal covers. Support writes a workaround article because customers are already confused, but product never prioritizes the fix.
Products are shared finite resources, not just collections of screens and buttons, and many quality problems are the visible symptoms of many people making individually reasonable decisions in isolation, which damage the shared system that everyone depends on.
What is a Commons?
A commons is something many people depend on while also influencing its condition/health. Nobody completely controls it, yet everyone leaves traces, and if the group isn’t careful, it can be used up.
| Quality | Real life | Tech |
|---|---|---|
| Many people depend on it | clean water, roads, public parks, shared air, fisheries | the product experience, design system, codebase, customer trust, shared roadmap, analytics taxonomy |
| Many people can affect its condition | drivers affect roads, residents affect parks, farmers affect groundwater, fishers affect fish stocks | sales promises affect product complexity, engineering shortcuts affect maintainability, design exceptions affect coherence, support workarounds affect user behavior, leadership timelines affect quality |
| Its capacity is finite | a pasture can be overgrazed, a road can become congested, groundwater can be depleted | user attention runs out, engineering capacity gets consumed, design coherence erodes, onboarding patience drops, a codebase can only absorb so many exceptions |
| Local benefit can create shared cost | one person overuses water and everyone faces scarcity; one driver takes a shortcut and the neighborhood absorbs traffic | one team ships a custom flow for an important account, but every future team has to maintain the exception; one dashboard gets every stakeholder metric, but users lose the ability to understand what matters |
If we take the suggestion that product is a commons, that means that everyone can’t just do whatever they want with it (like infrastructure1) because it is a shared resource whose health depends on how it’s used, changed, governed, and maintained.
A sales promise can create future complexity. A design exception can weaken coherence. A technical shortcut can become a permanent constraint. A leadership deadline can move quality costs into the future.
The product accumulates all of those decisions, whether or not the organization wants it to.
Once You See Products This Way…
1. Why do good people disagree so often?
Because of their Conflicting Incentives, they’re often optimizing for different outcomes. That’s why sometimes product disagreements feel strangely personal even when they are structural.
A stakeholder asking for a new dashboard metric may not be “making the design worse.” They may be trying to make their team’s work visible. An engineer pushing back on a polished interaction may not be “resisting quality.” They may be trying to prevent a brittle implementation from becoming a maintenance problem. A designer objecting to a one-off feature may not be “blocking progress.” They may be protecting the product’s ability to remain understandable.
All of these can be independently useful; the conflict begins when each group treats its priority as the whole picture. So we should not pretend those incentives do not exist, and instead make them visible enough that the team can reason about the whole system.
2. Why do so many meetings fail to create alignment?
Because understanding can’t be assumed—it has to be designed and translated
So many meetings produce temporary calm by resolving the surface language without addressing the underlying interpretation. “We need this to be simpler.” can produce a lot of nods, but does it mean usability, reduced scope, faster demos, fewer decisions, fewer tickets, or lower cost?
In a product commons, shared understanding is part of the infrastructure, and without investing in shared understanding, every function keeps making local decisions based on partial context.
3. Why do products become harder to improve over time?
Since local optimizations accumulate into system behavior, design must include diagnosis.
A simple feature request becomes a tour through old assumptions. Why does this role behave differently from that one? Why are these two settings separate? Why does this component have a custom variant? Why does this workflow skip the normal approval step?
This is why mature products often feel slower than teams expect. With mature products, you often already have processes, headcount, and ambition for dealing with your old debt, but by the time it’s grown, sometimes the product has absorbed so many unresolved decisions that every improvement has to move through them first.
This is why paying down design debt involves figuring out:
- what’s symptom and what’s cause?
- is this actually a capacity problem?
- have we been shipping our org chart instead of maximizing value to the customer?
4. Why do communication skills matter so much?
Because conversation is one of the primary ways products get built, so communication is a design material
A vague question produces vague requirements. An unspoken assumption becomes scope. A misunderstood objection becomes conflict. A poorly translated user need becomes a feature nobody quite believes in.
In a commons, listening is a diagnostic tool:
- Restating someone’s concern can reveal the constraint underneath it.
- Naming a tradeoff can prevent a team from treating it as a preference.
- Slowing down a conversation can save weeks of thrash later.
Product work is full of conversations that look adjacent to the “real work”: stakeholder interviews, critique, roadmap debates, reviews, planning meetings, customer calls, handoff discussions, executive updates. But these places where the product is being shaped.
And so if communication is a material, the quality of the conversation often determines the final quality of the thing that gets made.
Articles:
5. What should stewardship of commons actually look like?
If products are commons, we all maintain—or degrade—them together. The tragedy arises when one party makes decisions based on their personal needs or desires without taking into account the others who rely on that public resource.
Stewardship means designing the conditions under which a product can stay coherent while many people continue changing it:
- documenting why exceptions exist
- giving teams shared decision principles
- noticing when speed is borrowing from future maintainability
- treating design systems as governance, not just component libraries
- creating rituals where local decisions can be reviewed for system-wide effects
Stewardship asks, “What does this decision do to the shared thing we all depend on?” Ownership, often asks, “Who gets to decide?” A lot of teams are operating from ownership and pretending/imagining that they’re stewards.
Finally, what’s a designer’s job in a commons?
Again, products aren’t a collection of screens and buttons for designers to arrange. The interface is where many organizational decisions become visible to users. That gives us a particular responsibility to notice when the shared system is being depleted, confused, or quietly made harder to maintain. For those reasons, a lot of designers’ work has included:
- diagnosing systems rather than symptoms
- translating perspectives
- uncovering conflicting incentives
- improving the conversations that shape decisions
- helping teams take better care of something they all depend on
None of that replaces design craft. They explain why design increasingly looks like facilitation, systems thinking, and organizational problem-solving as products grow.
And then, products become better (or at least slightly less stressful) when teams learn to see the commons they are already inside.
More Reading
- The commons is what everyone draws from and affects: user attention, product coherence, customer trust, engineering capacity. Infrastructure is what helps the work happen: design systems, codebases, APIs, data pipelines, deployment tools. ↩︎