Two Product organizations can look equally sensible on a slide and behave completely differently in the work.
Both might have clean reporting lines. Both might have platform teams, customer-facing teams, design and engineering leadership, and somebody accountable for strategy. The chart tells you where people sit. It does not tell you why those boundaries exist or what the organization is trying to make easier.
A better explanation starts with the business: how value is created, where context matters, which capabilities should be shared, which decisions need to happen close to the work, and which dependencies are worth accepting because they create leverage somewhere else. Then the org chart becomes the consequence of an argument instead of the argument itself.
Every boundary buys something and costs something
Imagine a capability every Product area needs: identity, pricing, search, payments, experimentation, inventory services, or some other shared foundation. You could centralize it. That may create specialist depth, consistency, stronger standards, and less duplication. It can also create a queue between the shared team and the Product teams trying to use it.
You could embed specialists inside each stream-aligned team. That brings context and speed closer to the customer problem. It can also duplicate capability, fragment standards, and make scarce expertise harder to develop. You could organize around customer or market segments. Teams may understand their users deeply and own more of the experience. They may also rebuild the same underlying capability several times.
You could create a platform boundary and ask other teams to build on top of it. Done well, that creates leverage. Done poorly, it turns the platform team into another dependency everyone has to negotiate with. None of those choices is automatically modern or outdated. Each one makes some work easier and some work harder.
“Follow the business model” does not mean copy a canvas into the org chart
When I say structure should follow the business model, I am talking about how the company creates value and intends to win.
What does the customer actually buy from us? What needs to feel coherent even though many teams contribute to it? Where does scale create advantage? Where does local knowledge matter more than standardization? Which capability is differentiating enough that the company wants deep internal expertise? Which work is infrastructure that should be made easy for everyone else to consume?
The same capability can deserve a different organizational home in two different businesses because the strategy around it is different. A company competing on a deeply integrated ecosystem may tolerate more central coordination to protect coherence. A company winning through many independent business lines may push more authority into those lines. A retailer may centralize some digital foundations while keeping other Product work close to store operations because local operating context changes the quality of the decision. The chart should express those tradeoffs, not hide them.
Your altitude changes which part of the design you can influence
Most Product people are not sitting in a room redesigning the entire company. That does not make org-design literacy irrelevant. A PM should understand the boundary of the team: what it truly owns, what it consumes from others, and which dependencies are likely to shape the roadmap.
A manager or senior manager should be able to notice when the boundary itself is creating chronic problems. Is the team carrying too many unrelated capabilities? Is a shared service overloaded because every request requires custom interpretation? Are two teams duplicating the same expertise because the central model is too far from the work?
A principal or director may need to reason across several teams: which capabilities deserve to be shared, which should stay close to the value stream, where the seams are creating local optimization, and which decisions sit at the wrong altitude. At VP or Head of Product scope, those observations can turn into broader topology, funding, and leadership decisions. The authority changes. The reasoning does not suddenly appear at the top.
Decision rights are part of the structure even when they are not on the chart
Two teams can report into the same leader and still have terrible coordination. Two teams in different organizations can work extremely well if their boundaries and decision rights are clear. So I would never evaluate an org design only by asking who reports to whom. I also want to know who can make the important decisions, where escalation begins, what interface exists between teams, and how the organization handles a tradeoff that crosses those boundaries. Suppose a shared pricing capability serves several business lines. Centralizing the engineering team does not answer whether a business-line Product leader can change a price, whether Finance has a guardrail, whether local teams can experiment, or who wins when enterprise consistency conflicts with a market-specific need.
The reporting structure is only one layer of the design.
Design around the work you want to make easier
One practical way to reason about a structure is to ask what behavior the business is deliberately trying to make easier. If speed inside a customer segment matters most, push context and decision authority closer to that segment and accept some duplication. If consistency and risk control matter more, centralize more of the capability and accept some coordination cost. If many teams need the same technical foundation, invest in a platform boundary strong enough that consuming it does not require a negotiation every time.
The hard part is being honest about the price. Organizations often describe the benefit of the structure they chose and treat the cost as an implementation problem. But the cost is part of the design.
Centralization creates distance. Embedding creates duplication. Specialization creates handoffs. Broad ownership creates cognitive load. Shared platforms create dependencies. Autonomy creates variation.
The question is not how to eliminate those tradeoffs. It is which ones the business can afford and which ones support the way it intends to compete.
Hide the org chart for a minute
If you want to test whether the design has a real logic, explain it without using reporting lines.
Why are these capabilities together? Why is that team shared instead of embedded? Why does this decision happen centrally? Why is that one pushed closer to the customer or operator? Which dependency did the company deliberately accept in exchange for leverage somewhere else? What would become harder if you changed the boundary?
If the answers are grounded in value, strategy, capability, decision speed, and real dependency patterns, the chart is probably expressing a coherent design—even if it is imperfect. If the explanation is mostly history—that group has always owned it, that leader has those people, that is how the budget is organized—then the organization may be administratively tidy without being intentionally designed. The org chart is useful. It just should not be the first or only explanation of why the organization works the way it does.