Sometimes You Can See the Company Inside the Product
Use some products for long enough and you can almost guess how the company behind them is organized.
There are two settings pages because two teams built them. The mobile app calls something a “workspace.” The website calls it an “account.” Billing asks for information you already gave to sales. One part feels new, another feels five years old, and a third looks like it came from a different company.
This is often called shipping the org chart. The way the company is split starts showing up in the product.
So, What Does “Shipping the Org Chart” Mean?
The idea goes back to a 1968 paper by Melvin Conway. His point was simple: the systems a company builds tend to look like the way people in that company communicate.
The important word is communicate. It is not only about the boxes and lines on the formal org chart. It is also about who talks every day, who has the same manager, who shares a goal, and how hard it is to make a decision across teams.
This is not just a nice theory. A Harvard Business School study compared software built by companies with different structures. They ended up building software with different structures too.
Put simply: how you split the work changes what you build.
One Customer Journey, Five Teams
Imagine a growing software company. It has separate teams for growth, the main product, collaboration, billing, and support.
That sounds reasonable. Each area has an owner. But look at the customer's first week. The customer does not experience five teams. They experience one product.
Every handoff is a place where things can break. Growth wants more completed sign-ups. Product wants more projects created. Billing wants more completed checkouts. Support wants faster replies.
Again, all reasonable goals. But who owns the full question: Did the customer understand the product, invite their team, upgrade, and actually get value from it?
What It Looks Like in the Product
This usually does not show up as one big disaster. It shows up as lots of small, annoying inconsistencies.
| What the customer sees | What may be happening inside |
|---|---|
| The navigation follows product modules instead of what customers want to do | Each team owns a section of the product |
| The same setting or workflow appears in two places | Two teams solved similar problems without a shared owner |
| Different words describe the same thing | Each team came up with its own language and data |
| Customers repeat information when moving between steps | The data stops where one team's ownership ends |
| One part of the product looks and behaves differently | Teams ship separately and follow different standards |
| A problem falls between support, sales, and product | Nobody owns the whole problem |
One of these on its own does not mean your org structure is wrong. But if you keep finding them across the same journey, the problem may be bigger than a few bad screens.
Why Good Teams Still End Up Here
It is easy to blame bad communication or weak design. Usually it is not that simple.
As a company grows, it has to split the work. Teams need focus and clear ownership. Growth should be able to improve sign-up without asking the whole company for permission. Billing needs people who understand payments. A platform team needs to keep shared systems reliable.
Splitting the work makes sense for the company. But the customer still experiences one product.
This is where it gets tricky. Two teams can both make the right decision and still create a bad result. One team removes a field to improve sign-up. Another team asks for the same information later because it needs the data. Both decisions make sense. The customer just sees a product asking the same question twice.
A design system can make the buttons and spacing look consistent. It cannot decide who owns the full journey. It cannot fix two teams pulling in different directions. And it cannot make them share context if the company never gave them a reason to.
Three Real Examples
ExactTarget: The Menu Followed the Company
When DesignMap reviewed ExactTarget's platform, it found that the product structure matched the company structure almost perfectly. Features were split by channel and business unit. To understand the product, customers almost had to understand the company behind it.
That is a classic example. The menu answered “Which team built this?” instead of “What is the customer trying to do?”
Microsoft Outlook: Two Organizations in One Box
Steven Sinofsky used Outlook 98 as a very literal example in his essay “Don't Ship the Org Chart.” Outlook had different modes for internet email and corporate workgroups. It even used different installation technology. Internal product boundaries became choices the customer had to understand.
Android: A Simple Task Crossed Too Many Teams
A summary of a Google UX talk tells the story of Larry Page helping a friend set up Android to send a text message. A simple task had become difficult because different teams owned different parts of it. Every part could work as designed while the full experience still failed.
The same thing happened in all three examples. The customer crossed an internal boundary and had to deal with it.
It Is Not Just a UI Problem
The interface is just the easiest place to notice it. The same team boundaries can affect the software, data, APIs, pricing, sales process, and support.
- Two teams store different versions of the same customer data.
- An API uses internal service names that mean nothing to a customer.
- Pricing follows product departments instead of what customers value.
- Support has to transfer a customer because each team can only see its own system.
- A change takes months because it needs space on five different roadmaps.
Customers can feel the org chart even when they are not looking at a screen.
Not Every Boundary Is Bad
Products need boundaries. Companies do too. Clear teams can move faster, build expertise, and really own something.
The problem is not that the product has different parts. The problem starts when an internal boundary creates extra work for the customer.
If customers have to learn your departments, repeat themselves, work out what different words mean, or get passed between teams, you are making them deal with your structure.
Are You Shipping Your Org Chart?
Pick one important customer journey and follow it from start to finish. Do not review every feature on its own. Pay attention to what happens between them.
- How many teams own part of this journey?
- Does anyone understand and own the whole experience?
- Where does the customer have to repeat information or make the same choice twice?
- Do the words, rules, or design change when the customer moves between teams?
- When the journey fails, who feels responsible for the full outcome?
- Do the team's metrics measure customer success or just activity inside that team's area?
There is also a simple test. Show the product's main menu to someone who knows the company. If they can draw the departments from it, you may be shipping more of the org chart than you think.
Your Org Chart Is Also a Product Decision
Every box on an org chart creates focus. It also creates a boundary. That boundary affects who talks, what gets measured, which problems matter, and which problems belong to someone else.
Sooner or later, some of that reaches the customer.
This does not mean every bad screen needs a reorg. It just means some product problems start before anyone opens Figma or writes code. Before redesigning the menu or adding another meeting, it helps to understand the structure underneath the problem.