Before you reorganize, find out how your teams decide
A reorganization changes who sits where. In most product organizations I'm asked to look at, that isn't what's broken: goals arrive as revenue, teams count story points, and nobody agrees how decisions get made. Here's how to tell which problem you have before you move a single box.
The question usually arrives as a structure question. Should we split the platform team? Move to product trios? Put product under engineering, or engineering under product?
It's a fair question. It's also the one with the most visible answer, which is why it gets asked first. You can draw an org chart on a slide. You can't draw how a team decides what to build.
So before anyone redraws anything, I check what the redraw is supposed to fix. Most of the time it's something a new reporting line won't reach.
A team can have the right shape and still work the old way
Deviniti Apps is the cleanest example I have. Before its pilot, four people on the Luna team answered a product model maturity survey. Every question about the trio came back at the top of the scale from all four: who does what, which ceremonies they plan and learn in together, how value and viability are shared between them. The structure was there, and they agreed about it.
Focus scored lowest. All four said their planning was guided by effort estimates, story points or hours, and half named velocity and story points as the numbers they watched most closely. On five questions, the four answers spanned the whole scale. Asked how the team shares accountability for outcomes, two said each role focuses on its own deliverables and two said the team owns its success metrics together.
A reorganization would not have touched any of that. The boxes were fine. What happened inside them was not. The full story is in the Deviniti case study.
Five things to check before you change the structure
These are the questions I start with. None of them is about the org chart.
1. Where do the goals come from? If every team's goal is some version of "grow revenue", no team can act on it on a Monday morning. At Deviniti the business goal had always been communicated as growing monthly recurring revenue. The missing step was to decide whether the business was short on activation or on retention, and then let each product manager read their own analytics to see which one their product was short on.
2. What do the teams measure? Velocity and story points tell you how much got built. They say nothing about whether it mattered. If every number a team watches is about output, the team will optimize output, in any structure.
3. Who decides what gets built? If the roadmap is agreed somewhere upstream and handed to the team, moving the team changes who receives it. The decision stays where it was. Look at where the last three features came from: a stakeholder request, a sales promise, or a problem the team found and chose to solve.
4. Do people describe the same way of working? Ask every member of a trio the same questions, anonymously. Where the answers spread across the whole scale, you have found a disagreement that no reporting line will settle. At Deviniti that spread told us more than the score itself.
5. Can the team reach customers, data and the business? A product team needs direct access to three things: users and customers, product data, and business stakeholders. Watch the word "access". "We have analytics" often means the tracking is installed, not that anyone on the team can read it and decide from it.
When the structure really is the problem
Sometimes it is. If a team has no designer, if engineers only see work once it has been specified, or if nobody on the team can talk to a customer without three approvals, the competencies to make a product decision aren't in the room. Better goals won't fix that.
Even then, change one team first. Reorganizing everyone at once is one of the moves that makes a stalled transformation worse. A reorg announcement plus a new set of rituals gets you compliance in the first month and a quiet return to the old behavior by the third, because nothing in the incentives moved.
What to do instead, for the next quarter
Pick one team that already has a product manager, a designer and engineers, and can reach its customers. Give it one business number the company already cares about, and let it choose how to move it. Measure where the team stands before you start, so you can tell later what changed. Then let the evidence from that quarter decide what the structure should be.
At Deviniti the pilot team's trial-to-paid conversion went from 26% to 59% in three months. The longer-lasting result came after: every product manager set a product outcome for the next quarter, from their own analytics, in two or three sessions each. That spread came from a method each team could copy, not from moving teams around.
This is the shape of the Product Operating Model Transformation: a two-week assessment that asks these questions across the organization, then one pilot team, one metric and one quarter before anything scales.
If you are about to reorganize
Run the five checks first. If the answers point at goals, metrics and decisions, a reorg will move the problem rather than solve it. If they point at missing skills or missing access, change the structure, one team at a time.
Either way, measure before you move. The free Product Model Maturity Assessment asks a short version of these questions in about three minutes. It's one person's view, which is a start, not the whole organization.
