Vertical vs. Horizontal PM Cuts: A Practical Discussion on Responsibility and Efficiency Design | Louis Yang

Why is this worth reading?
This article takes a practical approach to discuss why product managers should be responsible for vertical cuts (complete feature ownership) rather than just horizontal cuts (functional division) in over 90% of development scenarios. You'll see specific practical challenges, organizational structure comparisons, and actionable strategies and recommendations.

Why is "Vertical Cut" a More Practical Product Thinking?

Vertical cut means: PMs are responsible for a complete user story or feature, covering everything from user interviews, feature design, technical selection, development coordination, go-to-market, to cost management and pricing.

It's not "I only handle UX" or "I don't handle releases," but taking responsibility for the outcome.
It's not just about delivering, but also about selling the product.
Only by mastering the entire process can you truly understand if the product solves problems and can be marketed effectively.

Example: In a multinational SaaS project, I was responsible for a module where I planned everything from API design, frontend operation logic, user education materials, to pricing strategy. Although the pressure was high, each decision was built within a logical system, preventing inconsistencies or risk miscalculations.

Vertical vs. Horizontal Cuts: The Tug-of-War Between Efficiency and Responsibility

Aspect	Vertical PM	Horizontal PM
Focus	Complete user journey	Single function (e.g., API)
Responsibility	High (outcome-driven)	Fragmented, passive support
Communication Efficiency	High (unified cross-platform logic)	High synchronization costs
Organizational Fit	Small teams, innovative products, new markets	Large companies, stable development, process-oriented
Drawbacks	High skill requirements, cross-domain needs	Lack of ownership

Why is Vertical Cut More Efficient?

Horizontal PMs (e.g., those only responsible for backend or writing specs) must synchronize with various other stakeholders for overall requirements. Every change requires additional time for meetings, clarification, and modifications. When requirements are vague or development scenarios change rapidly, this communication overhead grows exponentially, making it easier to "drop the ball."

In contrast, vertical PMs can lead the entire process, reducing back-and-forth confirmations. They can more easily integrate experience, learn quickly, and optimize the next development cycle. Iteration cycles become shorter and more compact, naturally improving product evolution speed.

What About "PM Skills Not Being Broad Enough"?

This is the most common objection to vertical cut design: "One person can't master so many functions!"

I believe this is true, but can be solved through the following mechanisms:

Virtual Support Team

Create knowledge-oriented roles responsible for writing specs, marketing strategies, pricing frameworks, and other best practices (e.g., feature documentation templates, different business tone email templates, requirement convergence and breakdown processes)
PMs share templates, cases, and guidelines with each other, or senior PMs coach junior ones
Leverage AI tools (like ChatGPT, ToneFlow) to assist in initial drafts, lowering skill barriers

AI has lowered the entry barrier. Today's PMs don't need to know everything, but they need to know "who to ask, how to research, and what to achieve."

Supporting Measures for Vertical PMs

To make the vertical work model truly effective, the following systems and process designs are needed:

Clear PM Responsibility Matrix: Let other teams clearly know which PM corresponds to each module, who to contact for what content, avoiding information confusion or responsibility ambiguity.
Regular PM Alignment Meetings: Periodically hold alignment meetings between PMs to align module progress and strategies, and identify conflicts or risks early.
Integrated and Documented Best Practices: Through Notion or knowledge base format, compile knowledge and experience in writing specifications, requirement breakdown, time estimation, technical collaboration processes, etc., forming stable output standards for the PM team.
Transparent Delivery Process Data Platform: Let other teams like development, design, and marketing instantly check each feature's owner, timeline, and design direction.

These supporting systems allow PMs to work independently while collaborating within a systematic framework, helping with knowledge transfer and responsibility clarification during team expansion.

Practical Module Division Recommendations

Some question: "Features are hard to completely separate." I believe this is actually a MECE Principle (Mutually Exclusive, Collectively Exhaustive) problem. This management concept from the McKinsey framework means that divided items should be "mutually exclusive but collectively exhaustive." Each PM's responsibility area should not overlap but should completely cover all product requirements.

Good Vertical Module Examples:

Recommendation System: From data collection → algorithm → frontend presentation, all handled by one PM
Account Module: From login logic, permission management, to third-party integration, all managed by one person

Modules Not Suitable for Independent Division:

Such as iOS / Android / Web FE / BE: These are function-oriented and not suitable for single PM management

Therefore, I recommend that vertical cuts should be feature-centric, not technology or platform-centric.

Who's Responsible for the Overall Product?

Some worry: "If everyone is only responsible for their own features, who manages the overall product strategy?"

I agree there should be a product lead (Lead PM or Head of Product):

Sets product direction and principles, responsible for overall organization operation
Resolves cross-module conflicts
Acts as coach and final gatekeeper when module PMs are less experienced

This design allows each PM to be independent while preventing overall strategy fragmentation.

Conclusion: From Division Logic Back to Product Essence

The PM's role is never just bridging requirements and development, but having substantial influence on product success.
When we let everyone specialize in just one area, we easily cultivate a "that's not my responsibility" culture.
But product success is the result of a complete chain of events.

Vertical thinking isn't about making PMs do more, but making them think more comprehensively.
Let each feature, each user experience, each business decision have a true owner.
Only in such a framework can PMs truly evolve from executors to outcome drivers.

Extended Thinking: If You Want to Adopt Vertical Structure, What's Next?

What PM Division Model Suits Your Team?
Evaluate current PM numbers, background differences, and collaboration models. Do you have the foundation for vertical operation? Which areas need adjustment or reinforcement?
Does Module Division Follow MECE Principles?
Review current module division. Does it follow mutually exclusive but collectively exhaustive logic? Which feature modules should actually be managed by one PM?
How to Help PMs Quickly Develop Cross-domain Capabilities?
Do you have virtual support mechanisms, such as internal best practices, AI tools, internal consulting systems, to help teams reduce cross-functional burden?

These questions don't have single answers, but they're worth deep discussion and design with your team before implementing vertical division.