Product Org Design: Build the Decision System, Not the Chart

A product organisation can have tidy reporting lines and still make every important decision through private escalation.

One team owns activation, another owns billing, and a platform group owns identity. A trial change touches all three. The chart shows owners. The work shows a queue of negotiations.

Product org design is the design of a decision system: how work is divided, who may commit it, what information travels, and how dependencies are resolved.

The organisation chart records part of that system. It does not create it.

Start with recent decisions and customer obligations. Put tightly coupled work close enough to reason together. For dependencies that remain, design an interface instead of hoping goodwill will absorb the cost.

Begin with a decision trace

Do not start by naming squads, domains, or reporting lines.

Choose three recent decisions that were consequential, slow, repeatedly reopened, or escalated. Reconstruct what happened from the first signal to the final commitment.

For each episode, record:

• the customer or business obligation at stake;

• the evidence needed and who held it;

• the recommendation and decision owners;

• the people who could block or reverse the choice;

• the teams required to implement or operate it;

• every wait, handoff, escalation, and reopening;

• the person who carried the consequence after release.

The trace separates a structural problem from a difficult decision.

If one unusual regulatory choice took time, the system may be working as intended. If routine pricing changes always wait for six leaders, the operating model has created recurring coordination work.

Decision Frameworks for Product Leaders covers the protocol for one contested choice.

Org design addresses the repeated pattern around many choices: where authority, evidence, execution, and consequences sit.

Write the organising problem before the solution

Puranam, Alexy, and Reitzig argue that organisations must address four general problems: divide tasks, allocate them, distribute rewards, and provide information.[1]

Their article is a conceptual comparison of forms of organising, not an empirical study showing that one product structure performs better.

Its value here is diagnostic. A fashionable team label does not answer those four problems.

Write an org-design brief that names:

• the strategy and promises the organisation must execute;

• the recurring decisions that matter to those promises;

• scarce capabilities and hard constraints;

• dependencies with high frequency or high consequence;

• current failures the redesign should reduce;

• trade-offs the new design will knowingly accept;

• conditions that would trigger another review.

“Increase accountability” is not a usable problem statement.

“Renewal decisions cross four teams, no role can commit the customer experience, and incidents expose conflicting owners” describes a system that can be examined.

Separate the layers of ownership

The word “owner” is often asked to carry incompatible meanings.

A person can own an outcome without controlling every system that affects it. A platform team can own an asset without deciding the commercial policy built on top of it.

Separate at least five layers:

Layer	Question
Outcome	Who is accountable for learning whether the intended change occurs?
Decision	Who may commit this class of choice within a declared boundary?
Work	Who plans and executes the change?
Asset or service	Who maintains the product, data, or technical capability over time?
Operational risk	Who responds when the change harms customers, compliance, or reliability?

One team may hold several layers. They should not be fused by assumption.

For every material area, name the decision classes, authority boundary, required consultation, escalation condition, and review trigger.

A team does not own an outcome in a useful sense if every meaningful lever belongs elsewhere and no mechanism governs those dependencies.

Outcome language without usable authority turns accountability into blame.

Put tightly coupled decisions close together

Boundaries should reduce the most expensive coordination, not eliminate all dependencies.

Galbraith’s information-processing view argues that uncertainty increases the amount of information an organisation must process, influencing how it coordinates work.[2]

It is a conceptual framework from 1974, not a tested recipe for contemporary product organisations.

Use it as a design constraint: when uncertain work requires frequent exchange, a distant handoff may cost more than placing the relevant decisions and capabilities together.

Map coupling between work areas:

• how often they need the same evidence;

• how often one decision changes the other’s options;

• how costly delay or misunderstanding becomes;

• whether the interaction is predictable enough to standardise;

• whether shared context decays between handoffs.

High-frequency, high-consequence, and highly uncertain interactions are candidates for a closer boundary.

Stable, legible interactions may be served through a clear interface.

Cataldo and colleagues analysed coordination requirements in a large software-development project and found that coordination needs were volatile and extended beyond formal team boundaries.[3]

Higher congruence between coordination needs and actual coordination was associated with shorter development time in that setting.

The evidence comes from one project and repository and communication data. The relationship is associative, not proof that copying its method will accelerate another organisation.

The practical question is still strong: does the structure put communication where the technical and product dependencies actually require it?

Design interfaces for the dependencies that remain

Every structure leaves cross-team work. “Collaborate closely” is not an interface.

For a recurring dependency, write a coordination contract:

Purpose of the interface
Decision classes on each side
Inputs and evidence required
Output or service promised
Named owners and substitutes
Response or lead-time expectation
Escalation condition and authority
Operational and customer obligations
Review trigger

Okhuysen and Bechky’s review of coordination research identifies accountability, predictability, and common understanding as integrating conditions across coordination mechanisms.[4]

It is a conceptual synthesis, not evidence that this contract causes better product outcomes.

Use those conditions to test the interface.

Can each side see who carries the obligation? Can they anticipate what will happen next? Do they understand the work and consequence well enough to make a compatible choice?

The contract should be proportionate. A low-risk analytics request may need an intake boundary and expected response. A shared identity change may need joint evidence, incident ownership, and a formal escalation path.

Do not route every exception through the executive team. If the same escalation repeats, the interface or boundary is unfinished.

Leadership Presence shows how necessary senior intervention becomes an approval gate when it has no explicit entry and exit boundary.

Treat shared capabilities as real services

Research, data, design systems, security, legal advice, and platform engineering are often shown as support around autonomous teams.

That picture can hide a queue.

If a shared capability is scarce, state what it provides, who prioritises demand, what input is required, what it does not provide, and how urgent work displaces existing commitments.

Also decide which knowledge should transfer into teams and which work genuinely requires a specialist.

An invisible pool creates two misleading stories: product teams appear fully staffed, while the shared function appears unreliable when simultaneous promises exceed its capacity.

The remedy is not always to duplicate the function. It is to make the service boundary, demand choice, and consequence visible.

Draw the chart last

Reporting lines matter. They shape performance management, professional development, compensation, information access, and the route for difficult people decisions.

They are only one coordination mechanism.

After the decision system is drafted, draw the chart that supports it. Then test whether the reporting relationship conflicts with the declared product authority.

Look for predictable contradictions:

• a product lead owns an outcome but cannot allocate any relevant capacity;

• a functional manager can silently overturn a domain decision;

• one executive is the only connection between two interdependent teams;

• a shared specialist receives competing priorities from every stream;

• operational ownership starts only after a feature is released;

• a temporary exception has become the permanent route for ordinary work.

Team Alignment explains the local frame teams need to make coherent decisions. An org design should make that frame usable across boundaries, not replace it with central approval.

Test the design before moving people

Run recent decision episodes through the proposed model.

Who would have held the evidence? Who could have committed the choice? Which dependency contract would have applied? Where would the customer or operational consequence land?

Then simulate one plausible disruption. Stable planning often hides unclear authority that appears during incidents, commercial exceptions, or regulatory change.

Use the test to revise boundaries before changing titles or reporting lines.

For a material reorganisation, document the transition:

• old and new authority during the change;

• active decisions and commitments that cannot be dropped;

• product, data, and technical assets changing hands;

• customer and operational obligations;

• temporary interfaces and their expiry;

• the date and evidence for the first design review.

Gradual change is not automatically safer. Two overlapping systems without an explicit transition can make every decision contestable.

Early Startup Team Building covers the first local operating model. Product org design becomes necessary when several teams, services, and authority boundaries must work as one system.

A fictional redesign without a promised result

Consider a fictional software company with separate acquisition, workspace, and billing teams. The example is invented and claims no outcome.

The acquisition team is accountable for trial conversion. It changes plan presentation, but billing owns pricing rules and workspace owns invitation limits.

Decision traces show that every trial experiment needs three roadmap negotiations. Billing also carries incident risk after commercial policies are committed elsewhere.

The design group does not begin by creating a “growth tribe.” It separates ownership layers and maps the coupling.

Pricing policy receives one commercial decision owner. Billing retains authority over ledger integrity and operational risk. Acquisition owns experiment design inside declared policy and representation boundaries.

The three teams create an interface for trial changes. It names required evidence, systems affected, response boundaries, incident ownership, and the conditions that require the commercial owner.

One engineer is not moved merely to make the chart symmetrical. A repeated identity dependency is tested against its frequency, consequence, and information needs before any boundary changes.

The proposed model is replayed against a recent failed-payment decision and a hypothetical billing disruption. Unclear transition authority is recorded as a design defect.

No faster delivery, conversion gain, or better morale is asserted. The example shows how to move from episodes to boundaries, interfaces, and then reporting lines.

Review the system through episodes

Do not declare success because people can recite the new teams.

Inspect comparable decisions after the change:

• where did choices wait and why;

• which decisions were reopened and by whom;

• where did evidence fail to cross a boundary;

• which shared capacity received incompatible demand;

• which operational obligation lacked an owner;

• when did escalation add authority or expertise;

• when did it merely route around the model?

Decision time alone is unsafe. A fast choice can ignore expertise or transfer harm. Escalation count alone is ambiguous. Lower numbers can mean clearer authority or concealed conflict.

Read the episodes with customer, operational, and decision-quality evidence.

Product Portfolio Optimization addresses how to allocate scarce investment across options. Org design determines whether those choices can travel into accountable work.

A useful product organisation does not make ownership absolute. It makes authority legible, dependencies governable, and consequences hard to abandon.

Design the recurring decisions. Place tightly coupled work deliberately. Give the remaining dependencies an interface. Draw the chart that supports the system you can explain.

Sources

1. Puranam, Alexy, and Reitzig: What’s New About New Forms of Organizing? (conceptual comparison of organisational forms; not an empirical product-org performance study)

2. Galbraith: Organization Design — An Information Processing View (1974 conceptual framework; not a contemporary product-organisation intervention)

3. Cataldo et al.: Identification of Coordination Requirements (analysis of one large software project; observed associations do not establish causality or general transfer)

4. Okhuysen and Bechky: Coordination in Organizations (integrative literature review; not a causal test of the coordination contract used here)

Read next

• Decision Frameworks for Product Leaders

• Team Alignment: Make Local Decisions Coherent

• Product Portfolio Optimization: Fund the Next Decision