5 Principles for Structuring your Single-Product PM Team

Structuring a PM team is easy when you have a fragmented portfolio of products. Each product has a manager, hence the job title! But in contemporary B2B SaaS, you frequently have one complex product with a large engineering team. I would advise against tackling that with a single PM. I once tried it on myself, and it was not very fun! This creates infinite ways to structure your team, and many of them are spectacularly wrong.

The tempting move is to slice PMs by whatever feels natural: features, user types, technical components, or that slide from last quarter’s strategy deck. The result? A beautiful org chart that produces ugly outcomes. Teams ship fractured experiences and spend more time in alignment meetings than actually moving the business forward.

But here’s the thing: single-product teams have a structural advantage too: the power to drive a customer value explosion based on many brains and brilliant insights. You just need to set them free to do so.

The five principles below aren’t theoretical frameworks from a consulting deck. They’re operating principles from my own experience that keep PM teams focused on what actually moves the needle: shipping value to users and results to the business. No buzzwords, just the structure that lets good PMs do their best work.

1. Business lanes

• Anchor PM ownership to measurable business outcomes (e.g., activation, retention, monetization of an add-on, entering a new adjacent market), not to engineering modules or surface areas. This keeps incentives aligned with impact rather than internal architecture trivia.
• Define each lane with a clear mission, target KPIs (even a North Star per lane!), and explicit ownership to reduce overlap and arbitration costs.
• In corner cases, step in as a leader to resolve!

2. Stable structure

• Keep the team topology stable for multiple planning cycles so PMs can compound domain context, relationships, and playbooks. Constant reshuffles are a tax on product velocity and cohesive strategy.
• Stability enables longer-horizon bets and cleaner causal inference on what’s working.
• Change structure only when there is a dramatic strategic shift, or when you are starting or closing a monetization bet.

3. Autonomy with accountability

• The team is only as autonomous as its ability to influence business outcomes with minimal outside help.
• Give PMs freedom to decide, but within a set of owned KPIs and an OKR structure, reviewed on a cadence.
• As a leader, make sure every project considers the end-to-end Job-to-be-Done, not a fragment based on imperfect ownership.
• Broadcast commitments and results across lanes to tighten trust loops. When teams win, credit flows to the players and the scoreboard, not the slide deck animations.

4. Verticalize first

• Start with vertical slices mapped to the strategic business bets and Jobs-to-be-Done. Verticals reduce dependency spaghetti and ship value end-to-end.
• Only introduce horizontal layers (e.g., shared platform, design systems, infra) once duplication clearly outpaces the overhead of coordination. Inevitability, not ideology, should force horizontals. Use some of the best practices from Marty Cagan’s Empowered to define proper platform OKRs.

5. A monolith team for the monolith

• If the product core is an inseparable monolith, treat it as a single PM organism: one accountable lead, shared backlog rituals, and explicit service-level expectations to the business lanes. Splitting artificial “modules” creates phantom ownership and reduced accountability.
• The monolith team’s job is usually retention and the core JTBD, possibly with additional KPIs when realigning the ICP. Their success metric could also be the downstream acceleration of the lanes they serve.
• Don’t postpone the right structure until the tech team “splits the monolith into microservices”. That might never finish, and PMs need to influence outcomes tomorrow to do their jobs.

How to put it together this quarter

• Define 2–5 business lanes, each with a named PM, 1–3 north-star KPIs (their reasons to exist), and a 90-day outcome bet. Publish scopes and escalation paths in a one-pager everyone actually reads.
• Build core and/or platform groups where necessary, prioritized against global KPIs and commitments.