How to organize small product teams

1 The bottom line

Run small pods of two to six people, give each decision one named owner, and show prototypes instead of writing long documents. Coordination cost slows a team to its slowest node, and fewer people and fewer pages cut it.

2 Key takeaways

• Staff each pod with two to six people who can cross roles. Fewer people to coordinate means faster, less committee-driven decisions.
  • Josh Woodward, Google Labs35:05: Labs project teams went from about five to seven people to about two to three, maybe four.
  • Adam Mosseri, Instagram3:25: core teams are now usually six or seven people instead of roughly thirteen.
• Name one accountable owner for every outcome and decision. Clear owners let you cut collaboration without losing the result.
  • Peter Sellis, Snap and Discord7:40: pair a shared strategy with a clear structure of who is trusted with which decision.
  • Tara Seshan, OpenAI43:50: someone is the DRI for adoption, desire and quality, and anyone can do the work.
• Keep the disciplines even as the lanes blur. Breadth and depth still limit what any one person can do well.
  • Andrew Ambrosino, OpenAI25:11: removing the product role throws away accumulated best practices, and he calls it a terrible idea.
• Show a prototype before you write a document. Building the first version is nearly free, so people can react to something real.
  • Max Schoening, Notion28:47: the first 10% of every project is now free, so skip the PRD and build the janky version.
  • Amol Avasare, Anthropic53:55: about 60 to 80% of what ships at Anthropic has no PRD.
• Add people for a specific need, not for a ratio or for growth. Headcount says nothing about product-market fit.
  • Tom Verrilli, Whatnot9:55: Whatnot has roughly 21 to 22 PMs while moving billions in GMV.
  • Josh Woodward, Google Labs53:40: a team that reached 30 engineers with zero product-market fit ended badly.

coordination costs essentially assure that you're moving as slow as the slowest node in the system

Peter Sellis, Snap and Discord

2.1 Size the pod

Product teams are shrinking to half their old size

Google Labs6 before3 now

Instagram core team13 before7 now

ElevenLabs team7 now

Start with a few people who can cross roles, and keep the team small while you search for the product.

• Staff new projects with a handful of multi-skilled people. Josh Woodward, Google Labs35:05
  • Team up people who can cross PM, code and design, and swap them between projects like musicians playing different songs.
  • Meta pods are four to six generalist engineers plus a product staff lead. Add a specialist only when the work needs one, such as a senior data scientist for pricing or a senior designer for a novel experience. Adam Mosseri, Instagram3:25
  • ElevenLabs runs teams of six to eight people on a specific product or opportunity. Jack McDermott, ElevenLabs43:36
  • The Meta team it replaced had about 13 people: two to three each of Android, iOS and server engineers, plus a PM, designer, data scientist and researcher. Adam Mosseri, Instagram3:25
• Isolate the first build. Roman Ugarte, Grok Bot5:15
  • Seat a handful of people apart from the rest of the company, with private Slack channels, for about a month.
  • That group made many daily micro decisions that a large group planning a 6 to 12 month vision would not have reached. First line of code to a working internal product took about a month.
  • For consumer networks, stay as small as possible to limit coordination cost while you find the spark. SuperMe is at eight full-time people plus contractors. Casey Winters, SuperMe34:50
• Under-resource a project a little at the start. Boris Cherny, Claude Code10:24
  • One engineer on a project has to automate with Claude, and their drive to ship sets the pace.
  • Boris built the first version of Claude Code in a terminal because it was just him and that was the easiest way.
  • Anthropic roughly quadrupled its engineering team while pull requests per engineer rose 200%. A year of work by hundreds of engineers at Meta gave a few percentage points.
• Launch each new app with its own pod. Yoav Sharon, Simply6:10
  • Start new apps as separate apps so no product carries weight for another. Give each a multidisciplinary pod that finds the pain, builds the offer and nails the value proposition.
  • Reuse early growth and customer discovery playbooks from earlier apps, and check audience overlap so apps do not compete.
  • Simply Draw grew revenue sixfold last year after launching recently.

2.2 Fill the roles on purpose

Add each role for a real need, and keep the specialties while you let people work across them.

• Hire a PM for a specific problem, not by default ratio. Tom Verrilli, Whatnot9:55
  • Map PMs to problems and critical projects rather than to teams. Some teams go a year without a PM.
  • Engineers and designers can be DRIs of product work if they go through the same product review.
  • Resist fast hiring. Live in some messiness and see what emerges before you consolidate. Josh Woodward, Google Labs53:40
• Keep the disciplines, drop the lane-policing. Andrew Ambrosino, OpenAI25:11
  • Keep a strong PM to rally teams, sharpen the problem and handle resourcing, and an engineer to make sure the system is sound, while people move fluidly between them. Ian Silber, OpenAI19:50
  • Treat PM as a major and builder skills as a minor, so early-career PMs code and prototype in service of becoming exceptional PMs. Josh Woodward, Google Labs38:10
  • Strong designers often become strong product staff. A senior Instagram designer just transferred into product staff. Adam Mosseri, Instagram8:18
• Let the engineer own any project of two engineering weeks or less. Amol Avasare, Anthropic45:35
  • The engineer also talks to security and legal, and the PM advises. Larger or controversial projects stay with the PM as accountable owner.
  • A default team of five engineers, one designer and one PM now behaves like 15 to 20 engineers with 1.5 to 2 PMs and designers.
  • Spread PMs out like a zone defense. Two PMs working too closely is a poor signal. The Codex desktop team has double-digit engineers, about half that in design, and few product people. Andrew Ambrosino, OpenAI29:06
• Put a PM or convenor on any project nearing launch. Ami Vora and Mike Krieger, Anthropic5:17
  • The convenor enables customer success, loops in safeguards, keeps end user needs in view and keeps people on track, so builders keep building.
  • Mike thought Claude could cover a nearly shipped project. Once a PM joined, things that would have been dropped got caught, and he told her she was 100% right.

2.3 Name one owner for each decision

Decide who owns what in advance, so the team needs fewer meetings to reach the same result.

• Give every outcome one accountable owner, whatever their role. Tara Seshan, OpenAI43:50
  • The owner answers for whether users adopt the product, want it and find it high quality. Anyone can do the work, based on affinity and capability.
  • Draw a clear structure showing who is trusted with which decision, and distill the founders' vision into short repeatable phrases. Peter Sellis, Snap and Discord7:40
  • Push PMs to make the decisions the founders would have made a year or two earlier, instead of collaborating on everything. If executives never say stop collaborating, treat it as a warning sign. Peter Sellis, Snap and Discord6:40
• Put one person across both sides of a conflicting trade-off. Tom Verrilli, Whatnot25:00
  • That person makes the trade-off against a single goal.
  • At Twitch, discovery and ads fought over feed impressions. Putting ads in discovery under one PM accountable for GMV from the feed removed months of back and forth.
• Give one or two tastemakers the 1.0 calls. Tony Fadell, Apple, Nest, Build Collective8:42
  • A new category has few analogs, so back the owners with prototypes and expert input, explain why each call was made, and be ready to correct later.
  • Micromanage the few key decisions, not daily operations, and own the data behind them. Tony Fadell, Apple, Nest, Build Collective13:51
  • The leader should own one-way door, controversial decisions. Two-way door, low-stakes decisions can go to junior people to learn. Francesco Polizzi, Discord47:47
• Use the mission and a written strategy to settle competing priorities. Cat Wu, Anthropic30:12
  • When two priorities compete, ask which matters more for the mission, and everyone backs the call.
  • Give empowered teams a product strategy, meaning a prioritized list of problems to solve. Marty Cagan16:43
  • Cat says she would be extremely happy if Claude Code failed but Anthropic succeeded.

2.4 Replace long documents with prototypes

Build something people can try, and write docs mainly to sharpen your own thinking.

• Build the first version instead of writing the PRD. Max Schoening, Notion28:47
  • Show what you think should be built, even if it is janky. Send off 10 agents to explore 10 paths and see which was right.
  • Something to react to builds iteration in early, the opposite of waterfall.
  • Lazar built a prototype in four hours that engineers replicated in production six to seven months later. He estimates writing it up would have taken a week or two. Lazar Jovanovic, Lovable52:15
  • A PM can articulate an idea faster by prototyping it, then spend the saved time improving the why and the what. Amol Avasare, Anthropic51:40
• Build three versions and test them instead of debating the design. Ami Vora, Anthropic8:32
  • Reasoning about where a finger lands on a phone is now less valuable than prototyping and seeing which works.
  • Ami spent years on interaction pattern reviews that she does not expect anyone to ask about again.
  • Say yes to every idea, build them all, and let the best one win instead of the one pitched best. Anish Acharya, a16z17:10
• Choose the format on purpose, and label each prototype's stage. Andrew Ambrosino, OpenAI7:58
  • Use a document for clarity around a vague area. Use a prototype to stress test an interaction pattern.
  • Say whether something is an exploration or a candidate to ship, because polish no longer signals that assumptions were derisked. Andrew Ambrosino, OpenAI9:52
  • At OpenAI there are roughly 90 uncoordinated prototype attempts for any desperately needed feature, so curation is the bottleneck.
• Write docs for your own thinking, and share rough drafts, mocks and test results. Tara Seshan, OpenAI56:34
  • A long doc no longer shows you thought it through. Better to show results from an A/B test and why they point one way.
  • Take a rough draft to the people whose buy-in you need, have them poke holes, and repeat with the next person. Tara Seshan, OpenAI57:37
  • Prepare as long as readers will spend. Tara preps the collective time attendees will spend in a meeting before the meeting. Tara Seshan, OpenAI59:00
  • Roadmaps and PRDs are fine once you have tested that the solution reaches the outcome. Dated roadmaps of ideas that might work waste most engineering capacity. Marty Cagan13:47

2.5 Keep the team in sync cheaply

Replace meetings and stale plans with shared metrics, open channels and a lean process.

• Run a weekly metrics readout and keep written team principles. Cat Wu, Anthropic9:11
  • The readout shows everyone the goals, how they trend and what drives them.
  • The principles cover key users, why they matter and what you will trade off. People then decide alone without waiting on a PM.
  • Still write a one-page PRD for ambiguous or heavy infrastructure projects. For larger projects, Amol runs a 30-minute cross-functional kickoff with legal, safeguards and others. Amol Avasare, Anthropic53:55
• Plan just in time, not six months out. Fiona Fung, Anthropic1:23:00
  • Plan monthly on a small spreadsheet of priorities, check weekly that they still hold, and gather everyone every six months to set themes.
  • Her six-month roadmap doc went stale about three months in.
  • Give explicit permission to kill a process that is dreaded, noisy, expensive or manual and no longer serves. Fiona Fung, Anthropic1:23:15
• Make communication public by default. Edward Tian, GPTZero46:20
  • GPTZero has a channel called "private DMs" that is actually public, for messages others need to see. It also has a mistakes channel and a shoutouts channel.
  • Mike pulled people into many meetings because he lacked a clear plan, and the meetings became an excuse for not having one. Mike Maser, Zero50:00
• Set up a standing launch room so any engineer can ship. Cat Wu, Anthropic8:37
  • After an engineer dogfoods a feature, they post it in the room. Docs, product marketing and DevRel jump in.
  • The marketing announcement turns around the next day. The PM builds this process and defines when to pull in partners.

2.6 Where they disagree

The right setup depends on your stage and product, and these sources pull in different directions.

• Do you need PMs early?
  • Snap had about 200 employees before its first PM hire, because designers were told to do the PM work and own strategy. PMs became important once legal, trust and safety, and data science needs grew. Evan Spiegel, Snap32:30
  • Ambrosino calls eliminating the product role a terrible idea. Andrew Ambrosino, OpenAI25:11
  • Boris sees about 50% overlap between engineering, product and design on his team, and expects the software engineer title to start going away in some places. Boris Cherny, Claude Code41:10
• Prototype first, or specify everything first?
  • Caleb designed every screen and the onboarding in Figma over three days before the developer started, so nobody had to improvise. Caleb Dean, Runafy32:10
  • Notion's approach is the opposite: build the janky version first and let people react. Max Schoening, Notion28:47
• Speed or a design gate?
  • At Snap, design must approve before anything ships. It slows shipping and annoys people, but it keeps the experience cohesive. Evan Spiegel, Snap36:50
  • ElevenLabs teams ship ideas the same day. The cost is less coherence between teams, and coordination is the main downside. Jack McDermott, ElevenLabs43:36
• How closely should leaders manage decisions?
  • Pincus says founders should micromanage pixel-level details for as long as they are the best player. Mark Pincus, Zynga1:18:18
  • Fadell limits it to the few details that matter and delegates the rest. Tony Fadell, Apple, Nest, Build Collective13:51
  • Pincus also suggests giving key people a hill with a plan and budget, so you do not have to manage them. Mark Pincus, Zynga1:15:39