By early 2024, the product organization of the company I was working at, had outgrown its startup character and turned into a “Kraken” that needed some serious taming. Ask a manager what the teams were working on this quarter, and you got a helpless, sometimes desperate shrug. Ask a team what the company’s main goal was and how their work contributed to it, and you got raised eyebrows and big question marks. Ask sales what the product actually was, and the answer depended on who you asked.

We had reached roughly 30 development teams working on more than 250 epics at the same time. Each team had its own idea of what mattered most and its own toolbox: Kanban, Scrum, Scrumban, anything went, nothing was necessary. No standards, no guidance. Any cross-team dependency turned into a small nightmare, costing weeks just to agree on how to work and document together. Documentation lived wherever an individual, not even a team, happened to keep it, in the analog and the digital world alike.

Building leverage, not a department

As a product director, I sat right in the middle of the sandwich, translating between “the teams aren’t delivering fast enough” and “management isn’t setting a clear direction.” I wasn’t only expected to find a solution. I needed one for my own sake: every hour spent translating between the two layers was an hour not spent on the strategic work the role was supposed to be about.

When an organization can no longer say what matters more than what else, it isn’t ambitious. It’s ungoverned.

And no amount of individual effort fixes an ungoverned system. Nobody was failing to execute. We needed a systemic answer if we wanted real change with measurable impact.

There was simply no operating layer left to align, prioritize, or learn at the pace the organization had grown into. Product Operations has its own canon by now, its own conference circuit, its own three-pillar frameworks, and at the time it was having another hype moment in my bubble. I asked around in my network, convinced we couldn’t be the only ones with this problem.

One argument I kept reading and hearing: if you don’t invest dedicated, undistracted time (meaning people, meaning money) into Product Ops, don’t even get started. It will lose momentum, turn into a side project, and die as it becomes irrelevant. I don’t love “don’t even try, unless…” claims; they make me want to prove them wrong. But there was also a practical problem: hiring new people was not an option at the time. Least of all for a “process” topic.

Before writing the pitch, I asked what leadership could actually say yes to: no money for new hires, and no appetite for betting on something unproven. I also preferred to shape the decision rather than wait for one. If Product Ops was coming either way, I wanted it to come from the middle of the organization, not down from the top. So I designed the proposal as an MVP of organizational change: small enough to approve, honest enough to test.

Concretely, that meant a dedicated, cross-functional Product Ops team with a clear mandate from management, but staffed from existing employees who invest 20% of their time and stay in their regular teams for the rest. If it worked, it would earn the right to grow. If it didn’t, it would have cost a fraction of a few people’s time, not a department. Two sponsors, me being one of them, carried it to leadership and made the trade-offs visible when priorities collided. No new headcount, no new box on the org chart.

The bet was that the leverage inside an organization is usually larger than the leverage you get by adding people to fix it. New hires need onboarding. People who feel the lack of a strong system every day are already motivated to fix it. You just have to build the mechanism that lets them.

We got the go in May. The team, six people across product management, agile coaching, engineering, and data, was kicked off in August. They decided to put their 20% into one dedicated day, Wednesdays, to protect focus.

We didn’t start from zero, and I want to be transparent about that. For the first six months, an external partner accompanied us through the initial setup: team building, a rough structure, and an orientation in what Product Ops can cover at all. The common reference is Melissa Perri’s three pillars: business data and insights, customer and market insights, and process and governance. The partner helped us get moving. The decisions about what to build, and for whom, stayed with the team.

Diagnosing before prescribing

Instead of jumping into fixing mode, we took a step back. Knowing where the problems are and having ideas for solving them is one thing. Rolling them out to an organization with a considerable allergy to anything “standard” is another. We needed buy-in. That started with who sat on the team, and it was a deliberate choice. Not new faces from outside with a model to impose, but colleagues the teams already trusted, who sit in the same planning meetings and feel the same friction. Standards land differently when they come from the inside. The other part of buy-in, I learned, is data.

So the team started by asking, across all flight levels: What are the biggest problems you’re facing right now? What has helped in the past, and what gets in your way?

That meant 340 quotes from internal interviews with management, sales, and product before a single artifact got created. We then structured what we heard by how often a problem came up, how many different functions raised it, and what it would take to fix. The answer: our main issues sat in the third pillar, process and governance, not in business data or customer insights. Nobody could see what was happening, nobody could agree on what the product even was, and nothing connected strategic intent to what a team was building that quarter.

The operating layer

What we built was deliberately narrow.

A portfolio layer, Portfolio Epics, that made significant, company-wide investments visible above team level for the first time, each with a business case and a hypothesis attached, so leadership could see and actively manage what was in flight instead of discovering it after the fact.

A single knowledge base for product documentation, with automated prompts built into the workflow so it couldn’t silently go stale again.

A small set of delivery metrics (system lead time, customer lead time, throughput), not as a dashboard for its own sake but as an early-warning system. When 19% of epics showed a system lead time of a single day, that wasn’t a good number. It was a data-quality problem, and it told us exactly where to clean up.

And an estimation matrix, to bring comparability and a common language to cross-team topics: how much time to block for them on a roadmap. It also gives sales a direction for their next client call.

What changed

The numbers since then are unglamorous, which is roughly the point. Quarterly planning kickoffs that used to take a full day now take two hours, because alignment happens continuously instead of in one expensive ritual. System lead time is down 15%. Work that used to be invisible above team level, the actual strategic bets rather than the backlog noise, now has one current, shared source of truth instead of three conflicting ones in Miro, Confluence, and Jira. That also increases accountability.

None of this required more people. It required an organization willing to treat its own operating model as something to design, not inherit. There is no blueprint to copy and paste. It takes working on and with the problems: experimenting, discarding, iterating.

Why this is a decision problem, not a process problem

It would be easy to file this under “process improvement” and move on. I don’t think that’s what it is. Every one of those numbers is downstream of a decision that got made faster, with less ambiguity, by more of the right people than it would have a year earlier. The documentation didn’t matter because documentation is virtuous. It mattered because sales and product leadership couldn’t make good calls without a shared, accurate answer to “what is the product.” The portfolio layer didn’t matter because visibility is nice. It mattered because leadership couldn’t weigh one investment against another without seeing both.

That’s the pattern I keep finding, in Product Ops and outside it: the constraint on complex organizations is rarely effort. It’s the quality and speed of the decisions the system allows people to make. Better decisions create better systems, and building the operating layer that lets an organization make them is a smaller, cheaper, more durable fix than most people assume.