How Product Organizations Scale Without Splitting Strategy from Execution

Quick recap from my previous article: In high-performing product organizations, strategy and execution aren't split between different roles. Every product team needs someone who owns both the "why" and accountability for what is built: someone with strong commercial instinct, ownership of outcomes, and direct connection to execution.

"But does this scale?"

Now let me address the inevitable objection: "Sure, but that integrated model might work at startup scale. Once you have hundreds of teams and complex enterprise environments, you need to split these responsibilities for scalability."

And while the scale at which you operate can influence your organizational design, a good principle is good at any size, and a bad principle is bad at any size.

There are several empirical examples of companies that scaled to massive size without splitting strategy from execution. Google doesn't have Product Owners. Neither does Cloudflare, nor Netflix. They scale not by fragmenting the role, but by managing scope: ensuring each Product Manager has a clear, bounded mandate where they can make meaningful impact without drowning in dependencies.

A sustainable model to scale Product teams

If you shouldn't split strategy from execution, how do you scale product management?

The answer is vertical, not horizontal. You scale by expanding scope, not by fragmenting responsibilities:

Product Manager → Owns a single product or module with clear boundaries. Responsible for both strategy and execution. Measured on business outcomes and impact. Works with a squad sized and staffed appropriately to the scope. Following Team Topologies principles, the squad must be optimized for fast flow and own the end-to-end value generation of a slice of the problem space. In startups, that slice will be very big. In huge corporates, that slice will be very small.

Group Product Manager / Head of Product → Owns a portfolio of products or a complex product with multiple independent modules. Sets portfolio-level goals. Acts as people manager for Product Managers. Provides coordination across products and platforms.

Director of Product / VP / CPO → Owns product organization vision, culture, tooling, and structure. Ensures product management practices scale effectively. Builds systems that empower PMs to make impact. In smaller companies who don’t need 2+ management layers, this role is usually merged with the previous one. In startups, this is usually the CTO (heading both the Engineering and Product functions).

In this structure, the Group PM isn't "doing strategy" while PMs "execute." Instead, the Group PM works at a higher level of abstraction—setting portfolio goals and ensuring alignment—while individual Product Managers maintain full ownership of both strategy and execution within their scope.

The Group PM asks: "Are we working on the right set of products to achieve our business objectives?"

The PM asks: "Is my product's roadmap delivering maximum impact on those objectives?"

Both are strategic. Both are connected to execution. The difference is scope, not separation of concerns.

Assigning the right scope

The key to scaling is assigning the right scope to each Product Manager. Not so broad that they're drowning in dependencies and can't make meaningful decisions. Not so narrow that they lack autonomy or can't see how their work connects to business outcomes.

When you get the scope right and each PM has a clear mandate and a squad-sized team to execute it, you can scale this model from dozens to hundreds of product teams without introducing artificial role splits.

What does "right scope" look like?

• Clear boundaries: The PM can make most decisions without constant cross-team coordination. There are no debates about ownership and no handoffs between teams in the value chain.

• Measurable impact: Success can be tied to specific business outcomes, not just feature completion.

• The right team: The PM works with a squad that can execute the roadmap without being stretched too thin or sitting idle. The squad’s combined skills allow the team to ship meaningful work without having to delegate work to another team.

• Strategic autonomy: The PM has enough freedom to experiment and adjust course based on learnings. The squad’s ability to ship new features is not constrained by heavy dependencies on other teams.

The takeaway: scaling is about scope, not splitting

Scaling is possible even with a single person managing both product strategy and execution. The most important thing is setting the scope right and using the management chain to coordinate overarching topics.

If you’ve been following the broader “Product Owner vs Product Manager” debate from the previous article, it can be tempting to treat scaling as a question of titles and role boundaries.

But the pattern underneath is the same: organizations split “strategy” from “execution” when they’re trying to compensate for a lack of true outcome ownership.

So the leadership takeaway is this: companies get the product management they incentivize. If you measure people on throughput, compliance to process, and “staying on plan,” you’ll get backlog managers and ceremony owners, regardless of whether you call them PMs or POs. If you give clear scope and accountability for impact, you’ll get product leaders who can hold the whole loop: problem → delivery → learning → outcomes.

When you get that right—scope and incentives aligned—your product organization can scale to hundreds of teams without ever needing to split product strategy from execution.