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 a mechanism, not a metaphor
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. 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. So when you redraw the boxes, you are deciding which features will be cheap and which will be structurally impossible. That is a product decision, arguably the biggest one you will make all year, and you are making it in a meeting about levels.
Why leaders keep calling it HR
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. Someone good got promoted. These are real pressures, and none of them start from the product. So the reorg gets optimized for the people math, and 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 with a fault line running through the middle of it, because the fault line was the reporting boundary. We review PRDs to death and approve org charts in a slide.
Start from the product, and raise the stakes with AI
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, make sure no single surface spans three teams, give each surface clear ownership, and where two surfaces hand off, put that handoff inside one team if you possibly can. Structure is not downstream of strategy, it is strategy.
The AI-native version raises the stakes. AI collapses the headcount org charts existed to coordinate. When agents handle research, first drafts, QA, and routine build, you need fewer humans, and the ones you keep spend their time on judgment and direction. The org problem 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 is the new org design, and by Conway's Law the new product design. An org where agents own routine build and humans own customer judgment ships a different product than one that bolts agents onto the side of an unchanged human org.
Pull up your org chart and your product side by side, find the seam that always feels a little broken to a customer, and you will almost certainly find a reporting boundary. Treat the next reorg like the product spec it is, and write it down that way before the memo goes out.