The Product Operating Model, Measured: 5,300 Meeting Hours a Month

Plenty of companies are announcing a move to a product operating model right now. Far fewer can tell you what it changed.

A European business software vendor with roughly 600 employees restructured its IT organisation around product groups in 2025. The decision came out of collaboration data, not a slide deck. A year later, the same measurement was repeated: the four new Business Units spent about 5,300 fewer hours per month in meetings than the equivalent areas did under the old structure. That is the working time of roughly 33 full-time employees, in a scope of about 207 people.

Here is how the project ran, what the data showed, and what we would tell anyone attempting the same.

The starting point: a functional IT organisation

The company's IT was organised the way most IT organisations are: by function. Development in one place, QA in another, product management somewhere else, with people assigned across initiatives as needed.

Nothing about that was unusual, and nobody inside the company described it as broken. What it had instead was a vague, widely shared feeling that too much of the week went into coordination — a complaint easy to voice and almost impossible to act on, because it has no size.

The HR team, led by the HR Director, had been working with Network Perspective data for a while and decided to put a number on it. The first analysis was straightforward: how much time do teams spend in meetings, and how much uninterrupted time is left for focused work?

Diagnosis: it was never really about the meetings

The first finding was the obvious one. Meeting load in the functional structure was high — in some areas above 30 hours per person per week — and deep work time was correspondingly thin.

The second finding was the one that mattered. When the analysis moved from how much time to who with, the picture changed. The problem was not that people scheduled too many meetings. It was that the structure required too many people to be in the room. Delivering almost anything meant aligning across several functional teams, and every one of those dependencies showed up in someone's calendar.

The effect was most visible among product managers, who sat at the intersection of the largest number of those paths. Their collaboration networks were the widest and their calendars the fullest — not because of how they worked, but because of where the structure placed them.

That reframing is what made the project possible. "We have too many meetings" invites a meeting-hygiene campaign: shorter slots, fewer attendees, no-meeting Fridays. Those campaigns rarely survive a quarter, because they treat a structural cost as a behavioural one. "We have too many dependencies between teams" points somewhere else entirely.

The decision: organise around products, not functions

IT leadership concluded that the organisation should be rebuilt around product groups. Four Business Units, one per major product line, each containing the roles needed to ship its own product and subdivided into Product Areas.

The logic was to move the dependencies inside the teams. Work that previously required coordination between three functional groups should now mostly happen within one unit, where alignment is a conversation rather than a calendar negotiation.

Two things are worth being honest about here.

First, the data did not design the structure. Engineering and product leadership did, drawing on their own knowledge of the products, the roadmap and the people. What the data did was establish that coordination load was the problem worth solving, and show where it concentrated.

Second, the change was not popular. The analysis was received with considerable scepticism inside the organisation, and more people were against the reorganisation than for it. That is normal — restructurings move people, reporting lines and status — but it is the part most case studies leave out. The data did not eliminate the resistance. It gave leadership something concrete to argue from, and — crucially — a baseline against which the decision could later be judged.

The result, one year on

In June 2026 the measurement was repeated with the same metrics, comparing each new Business Unit against the equivalent scope in the old structure a year earlier.

Three of the four units came out lighter. The largest went from 37 to 22 hours of meetings per person per week across 65 people, which alone accounts for about 3,770 hours a month. A second unit of the same size went from 30 to 21 hours, worth another 2,210 hours a month. A third, with 54 people, barely moved: 30 hours down to 29. The fourth and smallest, 23 people, went the other way, from 12 hours up to 21.

Net across roughly 207 people: about 5,322 hours a month.

Roughly 5,300 hours a month, or about 64,000 hours a year, moved out of meetings. At a conservative €25 fully-loaded hourly cost that is well over a million euros of working time annually — and even if the true figure is half of it, the order of magnitude holds.

The point is not the euro amount. It is that a structural decision, taken a year earlier on the strength of collaboration data, could be evaluated on the same terms it was argued on.

What the headline number hides

The aggregate is the least interesting part of the result. Three details underneath it are worth more.

The effect was wildly uneven. One unit dropped 15 hours per person per week. Another dropped one. Same reorganisation, same company, same year — and a difference of that size is not noise, it is a finding. It says the structural change released coordination load in some areas and barely touched it in others, which is a far more useful input for the next decision than a single company-wide average.

One unit went the other way. The smallest unit added about 10 hours of meetings per person per week. The honest answer is that we do not know from this data whether that is good or bad: it is a smaller unit that was building out a roadmap, and intensive alignment during that phase may be exactly right. What the measurement does is put the question on the table rather than leaving it to be noticed eighteen months later.

Low meeting load is not automatically a win. One unit ended the year with 29 hours of meetings and roughly 2 hours of deep work per person per week. That combination is a risk signal regardless of what the reorganisation did or did not change there, and it is the kind of thing that only surfaces when the two metrics are read together.

Four things we would tell anyone attempting this

Measure before you decide, not just after. The baseline is the whole asset. This company could evaluate the reorganisation in 2026 only because the same metrics existed from 2025. Organisations that start measuring after the change have no way to separate the effect of the change from everything else that happened that year — and no defence when someone claims the improvement would have come anyway.

Meeting load tells you there is a problem. The collaboration network tells you what it is. This is the difference between a meeting-hygiene initiative and a structural decision. Hours are a symptom; dependencies are the mechanism. If you only ever look at the first, you will keep treating the symptom.

Data does not win the argument for you. It was a sceptical audience, and the numbers did not convert anybody on their own. What they did was change the terms: instead of competing opinions about whether the structure was working, there was a measurable claim that could be checked a year later. That is a lower bar than persuasion, and a more durable one.

Measure the organisation, not the individuals. Everything described here was analysed at team and unit level. That is partly an ethical commitment and partly a practical one: the moment people suspect their calendar is being scored, the behaviour changes and the data stops describing reality. Structural questions need structural resolution anyway — no individual's calendar explains why four teams had to align to ship one feature.

Method and limitations

The comparison covers June 2025 (functional structure) against June 2026 (product structure), on metadata from the company's collaboration tools — no message content, no individual-level reporting. Scope was approximately 207 people across the four Business Units.

Three limitations are worth stating plainly. One team from the old structure had no data available, so the before-state is slightly incomplete. A single month in each year is a narrow window, and seasonality is not controlled for. And this is a before-and-after comparison, not a controlled experiment: other things changed in the organisation during that year, and some portion of the effect belongs to them.

We would treat the result as an order of magnitude — tens of thousands of hours a year — rather than a precise figure. That is still enough to answer the question the organisation was actually asking.