From Product Theory: The Hidden Forces That Shape User Behavior — 40+ short chapters on why users behave the way they do.
Pull up any big company's app. Notice how the checkout flow feels like it was built by a different company than the product page? How the mobile app and the web app share a name but nothing else?
That's not a coincidence. It's a law.
The product page team lives on the third floor. Checkout is on the fifth. Mobile is in a different building entirely. They have different managers, different roadmaps, different definitions of success. And so the product ships with visible seams — because the seams in the product are copies of the seams in the org chart.
That's Conway's Law.
The org chart you can feel
Melvin Conway wrote it down in 1967, in a paper called "How Do Committees Invent?" His claim was simple and a little heretical: the structure of any system mirrors the communication structure of the organization that built it. Design a compiler with four teams, you get a four-pass compiler. Design it with one, you get something integrated.
He submitted it to Harvard Business Review. They rejected it.
The most vivid illustration came decades later, not from a paper but from a cartoon. Someone drew the big tech companies as org charts. Microsoft was a set of armed departments pointing guns at each other. Google was a mess of overlapping circles. Apple was a clean hierarchy all reporting to one person at the top.
Here's the part that should make you uncomfortable: you could predict what using each company's products felt like just by looking at the chart. The fragmentation on paper showed up on screen. The coherence on paper showed up on screen. The org wasn't behind the product. The org was the product.
Why the seams appear
The mechanism is boring, which is why it's so reliable: communication is expensive.
When two people sit next to each other, they resolve ambiguity in seconds. A quick "wait, do you mean this or that?" and it's done. When they're on different teams in different buildings, resolving the same ambiguity takes emails, meetings, escalations, and a shared doc that nobody reads.
So teams do the rational thing. They optimize for what they control. They build a clean interface at their own boundary, throw it over the wall, and hope for the best on the other side. Nobody is being lazy or incompetent. Everyone is behaving sensibly. The mess is emergent.
This is why your iOS app feels different from your Android app. You told two teams to build "the same app." They can't. They use different design patterns, make different trade-offs, ship on different schedules, and don't share enough context to converge. So you get two apps that happen to have the same name.
And it's why cross-team features ship slower and worse. Not because people can't do their jobs — because coordination has overhead. One team owning a feature end-to-end moves fast. A feature that needs three teams to align takes three times as long, maybe five, because now you need meetings to sync and meetings to prepare for the sync meetings. Quality suffers too. When no one owns the whole thing, everyone optimizes their piece, and the seams show.
The one move that actually works
Most companies build an org structure out of legacy, politics, and headcount. Then they stare at their disjointed product and wonder what went wrong.
The better move is called the reverse Conway maneuver: decide what product experience you want, then structure the org to produce it.
Want a unified checkout flow? Put the whole flow under one team. Want tight platform integration? Put platform and features under shared leadership. You're not fighting the law — you're pointing it in the direction you want.
This is the quiet superpower of startups. Small teams mean fewer boundaries. Everyone talks to everyone. The product feels unified because the team is unified — not because anyone worked hard to make it so.
That advantage has an expiration date. Somewhere around 100 people, you start creating teams. Teams create boundaries. Boundaries show up in the product. The unity you got for free now costs money to maintain.
The mistake is wanting a unified product while organizing for a fragmented one. If your internal APIs are a nightmare, don't blame the engineers — blame the org structure that made them talk through walls.
Rule of thumb: Your org chart is your product blueprint. If you don't like the product, redesign the org.
Look at your product's worst seam — the place where it feels stitched together from two different apps. Now trace it back. There's almost certainly a boundary in your org that matches it exactly. The distance between two teams, measured in floors and managers and Slack channels, is the same distance your user feels when they cross that seam.
If you catch yourself tracing your product's worst seam back to a line on the org chart this week, there's more where that came from — the Context Limit newsletter sends one idea at a time, no pitch attached.