In 1967, Mel Conway published a paper that nobody in management has read — but that explains more about why products fail than any product management framework I know.
Conway’s Law: “Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure.”
Your product looks like your org. Not accidentally. Structurally.
What This Actually Means
If your data team sits separately from your product team, your product will treat data as a bolt-on. If your content team and your engineering team don’t talk, your product will treat content as a feature request. If your mobile team has no single named owner, your mobile experience will be fragmented — not because anyone chose fragmentation, but because the org produced what its communication structure permitted.
You don’t need to audit your product to find the dysfunction. You can read it from the org chart.
Putt’s Law is the darker companion to Conway’s: “Technology is dominated by two types of people — those who understand what they do not manage, and those who manage what they do not understand.” When these two types are separated by an org boundary, Conway predicts exactly what you’ll get: a system that reflects the gap between them.
The Implication Most Leaders Miss
When leaders encounter a broken product experience, the instinctive response is to fix the product. Conway says: fix the team first.
This is why product redesigns without org redesigns tend to reproduce the same problems in new packaging. The new design gets handed to the same structure. The same communication gaps produce the same architectural decisions. Six months later, the interfaces are different but the fractures are in the same places.
The teams I’ve seen break this pattern — who ship genuinely integrated experiences — are almost always the ones who did something structural first. They co-located people who needed to share context. They gave a single person accountability across a surface that had previously been owned by three teams. They removed the boundary that was encoding itself into the product.
Using Conway’s Law as a Design Tool
The most powerful use of Conway’s Law is not as a post-mortem analysis. It is as a design tool.
Three things you can do with it:
-
Before you design the product, design the team. Ask: what communication structure would produce the architecture we want? Then build that structure first — or you will inevitably build the architecture your current structure produces.
-
Name a single accountable owner for every major product surface. If more than one team owns a surface with no clear arbiter, Conway predicts what the product will look like: the boundary between those teams will appear as a seam in the experience.
-
Use it as a diagnostic. When a product feels fragmented or incoherent, map it against the org chart. The architectural problems will correspond almost exactly to the org boundaries. The fix is structural, not cosmetic.
This is sometimes called the Inverse Conway Manoeuvre: deliberately design your org structure to produce the architecture you want. It sounds obvious. Almost nobody does it.
The org chart is not an admin document. It is a product decision. Treat it like one.
Look at the last product decision that frustrated you. Now look at your org chart. Are they the same shape?
The Laws They Don’t Teach series:
Leave a Reply