How AI is changing who sits on a product team

The Product Leaders work group on pod size, blurring roles, hiring and keeping someone on the team who pushes for the user.

Updated October 13, 2026

It depends on the company and the stage of the bet. Small pods with wide roles suit new bets, while large products keep their specialists and run into new limits on judgment and code review.

Small pods for new bets. Nikhyl Singhal has seen a pod of one PM and one engineer, given a specific customer problem and four weeks, usually outperform bigger teams, and calls over-hiring the most common mistake right now. Noam Lovinsky says AI lets a team of three or four take on a problem that used to need a full pod.
Large companies look different. Tamar Yehoshua says small and large companies are moving in different directions. Ami Vora says a surface with many users and dependencies keeps its specialists, and the hard part is judgment and review. As agents write more code, Tamar's most experienced engineers carry the review load, and she plans for that when staffing teams.
Hiring profiles are shifting. Noam asks for product-minded designers who like to build, and calls writing the most underrated skill. Before a backfill, Ami Vora now asks whether automating repetitive work would let someone on the team grow into the role. Nikhyl points to people with years in sales or operations as strong user voices in a small pod.
Keep someone pushing for the user. Yuhki Yamashita warns that a one-person pod tends to negotiate with itself and settle on whatever is feasible. He checks that someone on each team pushes for the user, the business and feasibility. Nikhyl would screen PMs for user advocacy at hiring and judge a pod on whether the customer's problem went away.
Prototypes come first, and reorgs name their trade-offs. At Figma, a designer or PM can go straight to a working prototype with Figma Make before engineering commits. Yuhki expects a generalist product builder role surrounded by a smaller group of specialists. For any reorg, Ami says out loud which constraint it optimizes for and what it gives up.

Group chat with Tamar, Yuhki, Ami, Nikhyl, Noam — the Product Leaders work group

Question:

How is AI changing the way product teams are staffed and organized?

Nikhyl SinghalFounder of Skip. Former VP of Product at Meta and Chief Product Officer at Credit Karma

Teams are getting smaller, roles are getting wider, and the people being hired into product look different than they did two years ago.

On team size: the pattern I keep seeing in coaching sessions and on the podcast is a pod of one PM and one engineer, given a specific customer problem with clear market value and four weeks to discover and ship. That pod usually outperforms a bigger team. Over-hiring is the most common mistake I see right now, because it adds the coordination overhead that small AI-native teams no longer need.

On roles: three jobs are collapsing into one. When I talked with Jagjit about how his org at Meta adopted AI, his strongest PMs weren't the ex-engineers. They were economics and physics PhDs who reason from first principles, so technical pedigree is being discounted. Meta also cleared a full week of meetings so people could learn to build, and named "AI captains" by function to spread what worked. Zero-to-one pods (an engineer, a PM, a data scientist) still sit at the whiteboard together and add AI afterward.

That changes what the PM is there for. One PM told me his engineering partner said, "I can trigger fifty agents to fix all of those. What I need from you is the five-degree directional shift we have to make as a business over the next three years."

LinkedIn If the main goal is shipping features, hire an engineer. A PM earns the seat through taste, judgment, and cross-functional influence.

The org redesign has to be built from inside the company. JZ at Laurel ran AI adoption like a product launch, watching actual usage and fixing the tooling when adoption lagged. She also put a cash bonus on the first go-to-market feature shipped to production. Henrik at Mutiny calls token leaderboards "a blip in time."

Substack

Tamar YehoshuaChief Product and AI Officer at Atlassian. Former CPO of Slack and President of Product and Technology at Glean

The answer depends on company size. Small teams and large ones are moving in different directions, and I think a lot of the current debate mixes the two.

In a tiny startup, the single "AI builder" who covers PM, design, and engineering is a real advantage. Inside a 10,000+ person company like Atlassian, with complex codebases, lots of dependencies, and hundreds of thousands of customers who each have their own security and compliance requirements, the roles are expanding rather than converging.

Here is what we're seeing on the ground:

Throughput moved, so the bottleneck moved. Sherif Mansour, who leads Product Craft at Atlassian, put it well: if AI takes you from 1,000 engineers to the throughput of 2,000, you don't need more code. You need clearer direction on what to build and why. That makes PM and design judgment worth more.
The boundaries between roles are blurring. Our engineers use AI to write better specs, and our PMs and designers use coding agents to jump in and fix bugs. Each role still owns its craft, and the execution has become much more collaborative.
The PM job is the same and the day-to-day is different. PMs still set direction, exercise judgment, hold the quality bar, and drive business outcomes. What has changed is how much one PM can get done and how fast the roadmap moves.

On staffing, I've always said there is no single PM-to-engineer ratio. At Slack, growth teams had far more PMs per engineer than infrastructure teams did, and the right ratio depended on the phase of the company.

produxlabs AI shifts those ratios again. When code ships faster than a PM can steer it, as one founder, Maxime, told me directly, the answer is to hire people with taste who can own features end-to-end. Those people also need tooling that lets them unblock themselves and some deliberate guardrails for quality.

There is also a new constraint. As agents write more code, review becomes the bottleneck, and our most experienced engineers are carrying that load, so we have to plan for it when we staff teams.

Noam LovinskyChief Product Officer at Superhuman. Former CPO of Grammarly and Thumbtack

Most of the change is acceleration of things good teams were already doing. The best teams I've worked with have always had blurry lines between roles, and we've hired T-shaped generalists for a long time. AI makes that gap much more visible. A team of strong generalists now covers far more ground, and a team built around narrow handoffs (PM writes the spec, design makes the mocks, eng builds) looks slow by comparison.

So the hiring profile is moving. When I post for designers now, I ask for product-minded designers who like to build

LinkedIn. A designer who can take an idea all the way to a working prototype changes how many people you need in the room before you learn whether something is worth doing. Engineers get pulled further into product judgment as well, because generating code is cheaper and deciding what to build is where the time goes.

The skill I think most teams still underrate is writing. Great writers are even harder to find than great designers and engineers

X. With AI products, writing is the product: prompts, evals, the words in the UI, and the spec that keeps a small team aligned all depend on it.

On org structure, I keep returning to what we learned with the New Product Experimentation team at Facebook. Small, dedicated teams working outside the main product org's constraints validated and built much faster

getrecall. AI makes that model the default. You can give a team of three or four people a problem that used to need a full pod. The hard part has moved to the leadership layer: deciding which problems deserve a team and holding a high bar on quality when output is cheap.

Question:

Nikhyl sees roles collapsing into one, with a single PM and engineer pod shipping in four weeks. Tamar says that holds in tiny startups, but at a 10,000-person company roles are expanding, and code review by senior engineers is the new bottleneck. Anthropic grows fast and builds with its own models. Which pattern matches what you see there, and how has it changed who you hire into product and how teams are set up?

Ami VoraCPO of Anthropic. Former CPO of Faire and VP of Product and Design at WhatsApp

Honestly, both, and which one you get depends on the problem you hand the team. A brand-new bet looks like Nikhyl's pod: a few people who each cover a lot of ground and get to a working thing fast. A surface with lots of users and dependencies looks like Tamar's picture, where specialists stay specialists and the hard part is judgment and review. I'd rather not describe Anthropic's internal setup in detail here, so here's the decision process I use, which I'd apply anywhere.

Every reorg can only optimize for a handful of constraints (customer, technology, product, or leader), so I say out loud which one we're picking and what we're giving up. When tech moves this fast, teams get reset more often, and careless reorgs create confusion and fear.

Substack

On hiring, the backfill is the biggest change for me. When someone leaves, my reflex used to be to fill the role. Now I pause and ask whether we could automate the repetitive work so someone already on the team can grow into more of that role.

Substack

When I do hire, I watch out for the too-senior mismatch: someone who expects to manage, set strategy, and delegate when the team needs fast iteration close to users. So I put in-the-weeds work in the interview to see whether a candidate likes doing the work as well as whether they can do it, and I often bet on internal people who are high-capacity and hungry to learn.

Substack

What I value most right now is generalist problem solving. Everything resets so fast that nobody knows it all (I'm behind from this morning!), so I look for people who stay near the front and keep learning.

YouTube

Question:

Noam now hires product-minded designers who build working prototypes, because that cuts how many people you need before you learn whether an idea is worth doing. Tamar says that at large companies roles are expanding, and senior engineers reviewing AI-written code are becoming the bottleneck. At Figma, how has AI changed how many designers, PMs, and engineers you put on a team, and which of those two pictures matches what you see?

Yuhki YamashitaChief Product Officer at Figma. Former Head of Design for New Mobility at Uber

At Figma I see Noam's picture inside a team and Tamar's picture across the company. What has changed most is the order of the work, more than the headcount mix on any one team.

Inside a team, a designer or PM can now start at the end. With Figma Make, you can skip wireframes that slowly gain fidelity and go straight to a working prototype, then put a realistic concept in front of users before engineering commits. Prototyping used to be something you got to if you had time. Now it can be the first step. That reduces how many engineers have to be involved before we know whether an idea is worth pursuing, which is Noam's point.

Spotify

Across the company, Tamar's picture holds, because Figma is a professional tool with a high quality bar. We have shipped things that fell short of that bar, and users called us out publicly. So I don't want fewer people with deep craft. I want those people placed where depth matters most, and I expect a generalist product builder role surrounded by a smaller group of specialists who go deeper on craft.

I'm careful about one thing with tiny pods. At Figma we once had a design intern who wanted to try PM, so we gave them a project to both PM and design. Once they put on the PM hat, they got very pragmatic and stopped letting themselves dream. Good designers keep pushing on business and technical constraints until those constraints change, and that tension moves the product forward.

Spotify When I staff a team, I check that someone is pushing hard for the user, someone for the business, and someone for technical feasibility, whatever their titles are. A one-person pod tends to negotiate with itself and settle on whatever is feasible.

Faster building also means more people moving fast in different directions, so more of our org design effort goes into shared critique and work the whole team can see.

Question:

Yuhki warns that when one person covers PM, design, and engineering, they negotiate with themselves and settle on the feasible option, so he staffs to keep three advocates on every team: user, business, and technical feasibility. Your one PM plus one engineer pod has no dedicated user or design advocate. In the pods you've seen outperform, who pushes for the user, and have you seen pods ship something feasible but mediocre because nobody did?

Nikhyl SinghalFounder of Skip. Former VP of Product at Meta and Chief Product Officer at Credit Karma

In the pods I've seen work, the PM is the user advocate, and the mandate does a lot of that job. The pod gets one specific customer problem with clear market value and a four-week window, so success gets judged against whether that customer's problem went away. Shipping something on time doesn't count by itself. That framing makes it harder to settle for the feasible option, because a feasible-but-useless result fails the brief.

Yuhki's risk is real, and the place I see it most clearly is in PM hiring. When I talked with hiring leaders at Netflix, Rippling, and EvenUp, Sarah Koo at Rippling said candidates jump into solutions without understanding the use cases, then crumble when pressure-tested. Sam Stone at EvenUp said it's shocking how few candidates do user research, even though AI tools make it trivial.

LinkedIn Put that PM in a two-person pod and you get exactly the mediocre-but-shippable outcome Yuhki describes. So the user advocacy has to be screened for at hiring, because a small pod has no one else to catch it.

The pod also has limits. For complex features, I'd still bring design and engineering in deeply, because craft and long-term maintainability need people who go deep. The pair works best for discovery and early bets. Once something is worth scaling, it should pick up the specialist depth Yuhki and Tamar are describing.

On staffing, Ami's backfill question points at where the next user advocates may come from. Product roles are absorbing work that used to be three jobs, and AI covers much of the technical depth that used to gate entry. Someone with ten years in sales or operations often knows the customer's real workflow better than a pure-track PM does, so that person can be the strongest user voice in a small pod.

Ask a follow-up

Product Leaders

220

Product Leaders

3M+ insights

Product leaders from Google, Airbnb, Stripe & 7 more

by Lenny Rachitsky

Frequently Asked Questions

What goes into a good product strategy?
A customer problem the team can describe, one clear choice about the value to deliver first, the work set aside, and the evidence that would show the bet is working. It should let the team explain a specific 'no' to an important customer.
How do you tell a product strategy from a roadmap?
A strategy changes decisions: who the team builds for, where people are staffed and which requests get declined. Noam Lovinsky's test is which staffed project the team would stop to make room for its top bet.
How do you run customer interviews that change what you build?
Tie them to a decision someone owns, ask why the customer has the problem, watch them use a working prototype with realistic data, and check which segment each finding came from before it reaches the roadmap.
How do you scope an MVP?
Set the bar for viable, then cut breadth to one segment, one job and one surface. Keep the core interaction at full quality, leave operations rough, and write down the result that would make you stop before launch.
How should a product team handle feature requests?
Route them by source, write down the problem behind each one, rank only near-term work, and protect capacity for bigger bets and reliability so the request queue can't fill the whole roadmap.
How do you tell whether a new feature worked?
Write down what a win looks like and when you'll read the metric before launch. Read adoption, then sentiment, then behavior change, and check that the whole product gained rather than usage moving from one feature to another.
How do product managers keep stakeholders aligned on scope?
Put the scope decisions and the cut list in one shared record, ask what moves whenever someone adds work, name who owns each call, and check that agreement is real, for example by asking stakeholders to explain the decision back.
How do you forecast delivery for a project full of unknowns?
Give a range and the decisions that set it rather than one date, resolve the unknowns on the path to customer value first, and re-forecast at milestones that get feedback from outside the team.
What makes a product brief useful?
It lets the people building decide well without the PM in the room: the customer problem and evidence, the outcome, the trade-offs made, what is still open, and which constraints the team can challenge.

All product management questions →

Frequently Asked Questions

How AI is changing who sits on a product team

Product Leaders

Frequently Asked Questions

What goes into a good product strategy?

How do you tell a product strategy from a roadmap?

How do you run customer interviews that change what you build?

How do you scope an MVP?

How should a product team handle feature requests?

How do you tell whether a new feature worked?

How do product managers keep stakeholders aligned on scope?

How do you forecast delivery for a project full of unknowns?

What makes a product brief useful?

Your ideas, super powered.

How AI is changing who sits on a product team

Product Leaders

Frequently Asked Questions

What goes into a good product strategy?

How do you tell a product strategy from a roadmap?

How do you run customer interviews that change what you build?

How do you scope an MVP?

How should a product team handle feature requests?

How do you tell whether a new feature worked?

How do product managers keep stakeholders aligned on scope?

How do you forecast delivery for a project full of unknowns?

What makes a product brief useful?

Your ideas, super powered.