🏗️Delivery, Feature, and Product Teams
Three team archetypes — and your career depends on knowing which one you're actually on.
Marty Cagan's framing — Delivery Teams, Feature Teams, Empowered Product Teams — is the single most clarifying lens on why some PM jobs feel meaningful and others feel like glorified ticket-shuffling. Diagnose your team correctly, and you can either reshape it or leave.
Delivery teams ship code given to them by someone else. Feature teams take ideas from stakeholders and turn them into features. Empowered product teams are given problems to solve and have the autonomy to discover the right solution. Most companies claim to be the third; most are actually the second.
The three archetypes (Cagan)
Delivery teams
The team is handed designs and tickets. They ship code. They have no input on what to build or how. This is essentially an outsourced/contract engineering motion, sometimes called "engineering as a service." It's fine for utility work but it doesn't compound — the team never builds product judgment.
Feature teams
The team takes feature requests from sales, executives, or other stakeholders and turns them into shipped features. They have some agency over how to build the feature, but the what is dictated. This is the dominant model in most companies — and it's a feature factory.
The trap: you ship a lot of features, none of which move the metrics, because no one ever asked whether the features were the right ones. PMs in feature teams burn out because they're managing requests, not making product decisions.
Empowered product teams
The team is given a problem to solve — usually framed as a customer outcome or business metric — and trusted to discover the right solution. The PM, designer, and tech lead are a real trio with shared ownership. The team's success is measured by outcomes, not output.
This is the model at Stripe, the best of Airbnb, the best of Spotify, the best of Atlassian, and at most early-stage startups. It's also rare at scale — only about 10-15% of large product orgs actually operate this way despite the rhetoric.
How to diagnose your team
Ask yourself:
- Where does the roadmap come from? Empowered teams generate it from discovery. Feature teams receive it from stakeholders. Delivery teams just execute on what's handed down.
- How are you measured? Empowered teams are measured on outcomes (retention, conversion, NPS). Feature teams are measured on output (features shipped, on-time delivery).
- What happens if you say "I don't think we should build this"? Empowered teams: respected, the team debates. Feature teams: stakeholder escalates, you build it anyway.
- Who talks to customers? Empowered teams: PM, designer, and often engineers do regular customer research. Feature teams: maybe research does it, occasionally.
Why most companies are feature teams (despite claims)
Three reasons:
- Leadership doesn't trust the teams. Empowered teams require giving up control over the roadmap. Most execs aren't willing.
- Sales pressure. When a $5M deal hinges on Feature X, "we'll discover whether you need it" doesn't fly. The feature gets built.
- PM hiring. Most PMs were hired as feature teams PMs and don't have the discovery muscle to be empowered. The org has to develop it.
The transformation from feature team to empowered team is the central plotline of Marty Cagan's Empowered and Transformed — read both if you're a senior PM or leader.
What to do if you're on a feature team
- Build trust by shipping the requested stuff well first. You don't get to push back on stakeholder asks until you've earned credibility.
- Run discovery in parallel. Even if your roadmap is dictated, talk to customers, look at data, and start having opinions about what you'd build if you had the choice.
- Write the "if I had it my way" doc. Bring it to your manager. Some will engage; others won't. The ones who don't are signals about whether to stay.
- Pick your battles. Reframe one feature ask per quarter. Show that your reframing led to better outcomes. Earn the right to do more.
What to do if you're starting an empowered team
- Start with the outcome, not the roadmap. "This team owns activation. The goal is to move D1 activation from 38% to 55% by EOY."
- Hire a real trio. A PM, a senior IC engineer who'll be the tech lead, and a senior designer. None of them are deputies of the others.
- Default to discovery for the first 30 days. No roadmap until the team has talked to 20 users and looked at the data.
- Set a habit cadence. Weekly user research, monthly metric review, quarterly strategy revisit.
Key frameworks
Measure teams by customer/business outcomes (retention, NPS, revenue), not by features shipped. Output-first measurement is the root cause of feature factories.
PM + designer + engineering lead, sharing accountability for outcomes. None of them is in charge of the others; together they own the problem.
Real-world examples
Atlassian's product teams operate under a 'mission' model — each team is given a measurable mission (e.g., 'reduce time-to-first-value for new Jira admins') and has autonomy to figure out how. The PM, EM, and design lead form a trio with joint accountability. This is one of the rare large-company examples of empowered teams done well.
A typical mid-stage B2B SaaS has 8 squads, each with a roadmap dictated by the VP Sales' top 3 deal-blocker features per quarter. The PMs spend 70% of their time on Jira, the engineers are demotivated, and the win rate on those deals doesn't actually go up — because the features aren't what the customers needed. This is the feature factory pattern.
Common pitfalls
- ⚠Claiming you're an empowered team while measuring the team on output — the metrics betray you.
- ⚠Trying to skip from delivery team straight to empowered team without first earning trust through delivery.
- ⚠Allowing 'discovery' to become an excuse for not shipping anything.
Go deeper — recommended reading
Interview questions (3)
Q1What's the difference between a feature team and a product team?behavioralmid▼
A feature team takes requirements from stakeholders and turns them into features. A product team — an empowered product team in Marty Cagan's framing — is given a customer or business problem to solve and has the autonomy to discover the right solution.
The litmus test: where does the roadmap come from? If it's handed down by execs, it's a feature team. If it's generated by the team from discovery and data, it's a product team.
Both can ship lots of features. The difference is that the product team's features tend to move metrics, because they were chosen to.
Q2Your team is operating as a feature factory. How would you change that?leadershipsenior▼
Three-phase plan:
- Build credibility (Q1). Ship the requested features well. Be the most reliable team in the org. You don't get to push back on the roadmap until you've earned the trust.
- Insert outcomes alongside output (Q2). Start every feature with "we're shipping X because we believe it'll move Y metric." Even if execs picked the feature, you can reframe it around an outcome. Track whether the outcome happened. Over time, you'll have data showing which exec-picked features moved the needle and which didn't.
- Earn discovery time (Q3). Once you have the trust + the data, propose: "Let's reserve 30% of our team's bandwidth for discovery-driven work — bets we generate from customer research. We'll be on the hook for the outcome." Most leaders will say yes if you've done steps 1 and 2 well.
This is slower than "I'll tell the CEO he's wrong about the roadmap," but it actually works. The PMs who succeed at this are patient.
Q3How do you tell in an interview whether the team you'd be joining is a real product team or a feature factory?behavioralmid▼
Ask these four questions of your prospective manager and the engineers:
- "Where does the roadmap come from? Walk me through how a feature got onto the current roadmap." Real product teams have stories about discovery and data. Feature factories have stories about exec requests.
- "How is this team measured?" Outcomes (NPS, retention, revenue) → product team. Output (features shipped, story points, on-time delivery) → feature team.
- "What's a feature this team killed or didn't build, and why?" Real product teams kill things often. Feature factories never kill anything because the input was an exec request.
- "How often does the team talk to users directly?" Weekly → real product team. Quarterly or never → feature team.
If the answers are mostly the second option, take the role only if you want the practice on a hard problem (turning a feature factory into a product team), and only if you have leadership buy-in to do that.