Organizational Design for Product and Engineering
Structure your teams to maximize autonomy, speed, and strategic alignment.
Help the user with organizational design for product and engineering using insights from 27 guests and posts across Lenny's Podcast and Newsletter.
How to Help
- Analyze Lifecycle and Goals - Determine if the company needs speed and agility via a GM model or product cohesion via a Functional model.
- Define Team Boundaries - Structure autonomous pods around durable customer segments or outcomes rather than temporary features.
- Assign Leadership Pairs - Pair Product and Engineering leads at every level to ensure business strategy and technical execution are balanced.
- Implement Scaling Guardrails - Add specialized roles like product ops and clear career ladders as the organization grows to maintain velocity.
Core Principles
Shift from Projects to Programs
Bill Carr: "Let's create teams that can stand alone, where there's a single leader and the cross- functional resources that they need are all either directly report to them or are dedicated to them. So they don't necessarily have to be a straight line direct report. In Amazon's case, for the most part it was. There were some dotted line, but it could be all straight line, it could be all dotted line, it could be a mix of the two."
Move away from shifting resources between tasks toward a program orientation where teams own a specific customer area indefinitely. This empowers single-threaded leaders to take full ownership of long-term outcomes.
Unify Under a Single CPTO
Claire Vo: "I'm using CPTO for short code of running product and engineering design functionally together. There should be no debates over what's best for product or what's best for engineering, what's best for design speed. What is best for the organization?"
Consolidating product, engineering, and design under one leader eliminates functional silos. This alignment stops internal debates and optimizes for overall organizational speed over individual department goals.
Standardize via Functional Centralization
Dhanji R. Prasanna: "So all engineers report into one single team now, all designers report into one single team and there's single head of engineering, single head of design, et cetera. And so that was the big transformation that we made, and that meant we could really drive forward AI, we could drive forward platform and just technical depth generally."
Transitioning to a functional structure helps a company align on singular technical strategies. It allows for standardized engineering levels and policies that drive excellence across the entire department.
Design in Public
Heidi Helfand: "I really like it when there's transparency in reorgs. There's a story in my book from Christian Lima at Spotify about how they reorged a large infrastructure team. They visualized it on whiteboards and brought people over to the whiteboards to see the future team structure that the leaders wanted and they got input into the design."
Maintain transparency during reorganizations by visualizing proposed structures on public whiteboards. Involving employees early helps identify structural errors and increases engagement with the new mission.
Distribute PM Responsibilities
Karri Saarinen: "We actually don't have much PMs in the company. We only have one and we can talk about more about it. One of the things I think that happens is when you build a team and you start creating these very specific roles for everything I think that often the PM can be the ones figuring things out and making decisions and guiding the team, but they're not the ones building the feature."
Eliminating dedicated PMs for every team can increase ownership among those actually building the product. Distributing management tasks to engineers and designers fosters higher attention to detail.
Hire Only When Thirsty
Varun Mohan: "I want the company to almost be like this dehydrated entity. Every hire is like a little bit of water, and we only go back and hire someone when we're back to being dehydrated."
Treat every new hire as a scarce resource and wait until the team is truly underwater before adding headcount. This prevents organizational bloat and ensures every role is vital for project survival.
Organize by Customer Segment
Sachin Monga: "The teams aren't oriented around product surfaces. We don't have a team that's like the app team or a team that's like the dashboard team or the podcasting team. We have teams that are oriented around customers and solving bit of a timeless customer problem."
Define teams by the specific customer group they serve rather than ephemeral feature surfaces. This creates a more durable structure where each team has its own dedicated cross-functional resources.
Templates & Frameworks
- GM vs. Functional vs. Hybrid Org Model Decision Framework (General management, functional, and hybrid models: Which org design works best for top companies?) - A two-factor framework for deciding which organizational model suits a company, based on (A) proximity of North Star metric to revenue and (B) importance of hol
- Metric-Based vs. Feature-Based Team Classification (How Duolingo builds product) - A framework for deciding whether to structure product teams around quantitative metrics or around product missions/problems
- AMPED Team Structure (How Miro builds product) - Cross-functional team structure that integrates Analytics, (Product) Marketing, Product, Engineering, and Design into unified product teams organized by streams
- Notion's Four-Layer Product Team Structure (How Notion builds product) - A metaphorical layered team structure for highly interconnected products where no feature can be fully isolated
- Linear's No-PM Project Team Model (How Linear builds product) - A framework for running product teams without traditional PMs, where the project team serves as its own PM.
- Areas of Responsibility (AORs) Spreadsheet Template (How to get your marketing team to drive more impact) - A spreadsheet template for creating a shared list of ownership areas across marketing and cross-functional teams, learned from Asana's internal system.
- Org Design Principles for Product Velocity (How Ramp builds product) - Three principles for structuring the product organization to maximize speed and collaboration
- Three Approaches to Managing Ambiguous Ownership (This Week #9: Breaking into growth, leading with influence, and (not) stepping on toes 🦶) - A graduated set of strategies for handling unclear product area ownership as a PM team scales, from simplest to most complex
- Company Stage → Org Model Progression (General management, functional, and hybrid models: Which org design works best for top companies?) - A lifecycle-based framework showing how org structure typically evolves as companies grow from early-stage to mature multi-product companies
- PM Career Ladder Design Decisions Checklist (Product management career ladders) - Key structural decisions to make when building a PM career ladder, derived from patterns across 20+ companies
See references/artifacts.md for the full list with details.
Questions to Help Users
- "Is your primary goal right now business speed and agility, or product cohesion and consistency?"
- "What are the top three cross-team dependencies that currently slow down your shipping velocity?"
- "Do your teams currently own features (outputs) or business outcomes (metrics)?"
- "How many people are currently in your product, engineering, and design functions?"
- "Do you have clear career ladders defined to reduce role ambiguity as you scale?"
- "Are your teams structured around technical layers or customer segments?"
Common Mistakes to Flag
- Over-staffing projects - Adding too many people creates communication overhead and organizational rot that slows down execution.
- Copy-pasting industry standards - Implementing models from other companies without adapting them to your unique culture and product medium often leads to friction.
- Siloing Product and Engineering - Failing to pair PM and Engineering leads results in misaligned strategies and execution bottlenecks.
- Treating org design as static - Organizations are products that must be iterated on to provide teams with maximum autonomy as the business evolves.
- Designing reorgs in secret - Hidden design processes lead to employee anxiety and miss the valuable feedback that comes from those closest to the work.
Deep Dive
For all 50 sourced insights from 27 guests, see references/guest-insights.md
Related Skills
- Hiring Product Talent
- Interviewing Evaluating Candidates
- Building Growth Team
- Founding Exec Team
