The Reorg Is a Product Decision Nobody Calls One

The short version

Org design is product strategy, and Conway's Law is the reason. Your org ships its own communication structure, so a reorg sets the ceiling on your roadmap before anyone writes a ticket. Most leaders treat reorgs as HR events, headcount math and reporting lines, then act surprised when the product mirrors the new boxes with seams a customer can feel. The org chart is the most consequential product spec in the company and almost nobody reviews it as one. In the AI-native present this gets sharper, not softer: when agents absorb the routine work, fewer humans coordinate more, and the new product lever is where the agent layer sits and which judgment stays human. Here is why the reorg is the product decision you are not calling one, and how to design org structure around the product you actually want to ship.

I have sat in a lot of reorg meetings. CPO at four companies, VP Product at Salesforce across Marketing Cloud, Quip, and Slack, leadership roles at Adobe and Microsoft before that. In almost none of those meetings did anyone say the words "this is a product decision." They said retention, span of control, levels, who reports to whom. And then six months later we were all confused about why the product felt like three products stapled together.

It felt that way because it was built by three teams who did not talk to each other. That is the whole story.

Conway's Law is not a metaphor, it is a mechanism

Conway wrote it down in 1968 and it has been quietly true ever since. Organizations design systems that mirror their own communication structure. Split a team into three groups with thin connections between them, and you will ship a product with three seams in exactly those places. The boundaries between your teams become the boundaries in your software, every time, whether you plan for it or not.

This is not a soft observation about culture. It is a hard constraint on what your product can become. If billing and onboarding live in different orgs with different VPs and different roadmaps, the handoff between billing and onboarding in your product will be bad, because the handoff between the two teams is bad. You can write "seamless onboarding to paid" at the top of every roadmap you want. The org will overrule the roadmap, because the org is what actually does the building.

“

Your org ships its communication structure. The seams between your teams become the seams in your product, and a customer can feel every one of them.

”

So when you redraw the boxes, you are not moving people. You are deciding which features will be cheap and which will be structurally impossible. That is a product decision. It is arguably the biggest one you will make all year, and you are making it in a meeting about levels.

Why leaders keep calling it an HR event

The reorg gets triggered by a people problem. A strong VP needs more scope or they will leave. Two leaders are fighting over the same surface. Headcount got cut and the boxes have to shrink. Someone good got promoted and needs a bigger org under them. These are all real pressures, and none of them start from the product.

So the reorg gets optimized for the people math. We solve the retention risk, we give the VP their scope, we make the org chart symmetrical and clean. The product consequences are an afterthought, discovered later, in a roadmap review where everyone is puzzled about why the cross-team feature keeps slipping. It keeps slipping because it crosses three teams, and crossing three teams is the most expensive thing a feature can do.

I have made this mistake. Early in one CPO seat I reorganized to fix a politics problem, drew a clean org that made the humans comfortable, and shipped a product that felt like it had a fault line running through the middle of it, because it did. The fault line was the reporting boundary. I had designed it in without noticing, because I was thinking about people and not about the product the people would inherit.

The org chart is a product spec. It is the most binding spec in the building, because it decides what the other specs are even allowed to become. Almost nobody reviews it as one. We review PRDs to death and approve org charts in a slide.

Start from the product, not the people

The fix is to invert the order. Do not start with the people you have and where they should sit. Start with the product experience you want a customer to have, then design the smallest org that can ship it without seams.

Draw the surfaces a customer actually touches. The thing they sign up through, the thing they pay through, the thing they get value from daily. Now make sure no single surface spans three teams, because the surfaces that span three teams are the ones that will feel broken. Give each surface clear ownership. Where two surfaces have to hand off, put that handoff inside one team if you possibly can, because the handoffs that cross org boundaries are the ones that rot.

This is the same idea I keep coming back to in how I think about the product operating model: structure is not downstream of strategy, it is strategy. You are not choosing reporting lines. You are choosing which version of the product is buildable.

“

Stop drawing the org you have and asking what it can ship. Draw the product you want and ask what org could possibly ship it. Then build that org.

”

The AI-native version raises the stakes

Here is where this stops being a lecture about 1968 and becomes the most live decision on my desk right now.

AI collapses the headcount that org charts existed to coordinate. When agents handle research, first drafts, QA, routine build work, and a growing share of the glue work, you simply need fewer humans, and the humans you keep spend their time on judgment and direction instead of execution. The org problem changes shape. It stops being "how do I arrange forty people" and becomes "where do the agents sit, what work moves to them, and which judgment stays human."

That boundary, between what an agent does and what a person decides, is the new org design. It is also, by Conway's Law, the new product design. An org where agents own the routine build and humans own the customer judgment will ship a different product than one that bolts agents onto the side of an unchanged human org. The first ships fast and coherent because the agent layer is part of the structure. The second ships the same old seams, now with a chatbot in front of them.

I am living this at Falkster.AI, where the org is mostly an agent layer with me directing it, and the outcome-to-prototype loop is fast precisely because there are no team boundaries for it to cross. That is the easiest possible case. The hard case is the 400-person company deciding which roles to dissolve into agents and which to keep human, because that decision will not read like a reorg. It will read like a product strategy, because that is what it is. The director layer is the first place this pressure lands, which is its own uncomfortable conversation I get into in how AI deletes the director.

What to do this week

Pull up your current org chart and your current product, side by side. Find the place in the product where two teams hand off, the spot that always feels a little broken to a customer. That seam is almost certainly a reporting boundary. You did not design the seam on purpose. You designed the boundary, and the seam came free with it.

Pick one product surface that matters and ask a single question: does the team structure around it match the experience I want a customer to have, or does it match an old people problem we solved two reorgs ago. If it is the second one, you have found your next product decision. It just happens to be hiding in an org chart instead of a roadmap. Treat the next reorg like the product spec it is, and write it down that way before the memo goes out.

Sources: Silicon Valley Product Group on product operating models; Harvard Business Review on organizational design and Conway's Law; First Round Review on scaling product organizations.