Direction Over Speed
How to structure product and growth teams now that shipping is cheap.
Being AI-native isn’t about speed. It’s about direction.
Speed was never the bottleneck. Direction was. AI made shipping cheap, and the real bottleneck became obvious: most teams now ship the wrong things, faster.
Two years ago I wrote a guide on structuring product and growth teams. The principles held up. The ratios broke. The PM role compressed around the one thing AI can’t do for you: alignment.
Here’s the refresh.
The cast
Two roles do most of the work in a product-led team:
Product Manager (PM). Owns what the team builds and why. They connect what gets shipped to the business: the business case, the altitude map (a cascade of metrics from company outcomes down to the team’s daily work), qualitative and quantitative research, and the go-to-market plan. The PM is the person who answers: is this worth building, and how will we know?
Engineering Manager (EM). Owns how the team ships. They lead the engineers technically and as people: hiring, coaching, sprint cadence, technical health, removing blockers. Throughout this piece I mean the internal EM, the one who sits inside the team alongside the engineers, not one managing from outside across multiple teams. The EM is the person who answers: are we building this well, and can we sustain the pace?
Those two, plus 2-3 engineers and sometimes a designer, are the team. Everything that follows is about how their scope and ratios changed.
1. Smaller. EMs smaller still.
I used to recommend product teams of fewer than seven people. That’s now too big.
The new shape: 4-5 people total, including the PM. Three to four engineers, one PM, sometimes a designer. That’s the unit. Operators and investors looking at AI-first companies are landing on the same number.
The engineering manager scope dropped harder. I used to say an internal EM could handle 3-4 engineers. The new working number is 1-2, with rare exceptions at 3. Above that, the EM regresses into pure people management and loses the technical context they need to balance tech debt against product urgency.
The whole point of embedding the EM in the team was to keep that balance live. You can’t keep it live across 5 engineers.
Why:
Specialist profiles got more senior. Fewer people, each doing higher-leverage work.
Shipping more means reiterating more. Tight teams iterate faster than wide ones. The loop between ship and learn matters more than the act of shipping itself.
Bigger teams don’t fix this anymore. They amplify it.
2. PM ratios split by measurability.
I used to recommend one PM per team. That’s now too dense for some teams and not dense enough for others.
The split depends on one question: how easy is it to measure whether the team’s output is good?
For commercial product work, UI features, conversion flows, anything where you can run an A/B test and read the result, one PM can cover roughly eight engineers across two teams. Quality is verifiable. Metrics close the loop. The PM is needed for direction, not babysitting.
For core AI behavior, model outputs, prompts, agent reliability, anything where “is this good?” doesn’t compress into a single number, you need one PM or TPM (technical product manager, a PM with deep engineering fluency) per two engineers. Quality is the work. You cannot offload it to a dashboard.
The harder it is to measure quality, the more PM bandwidth per engineer you need.
One exception. A junior PM can sit dedicated to a single team while a principal or staff PM spans both teams as their coach. Treat it as a time-bound training overlay, not the steady state. The thesis here is concentration, not headcount.
3. Prototypes replace specs. PMs compress around alignment.
The product requirements document (PRD) used to be how a PM communicated the build to engineers. PMs wrote PRDs, engineers turned them into code. The handoff was the artifact.
That’s over. Prototypes replaced specs, and they’re built collaboratively now, in two phases:
The PM prototypes the idea first, with the team. A visualization of what came out of customer conversations, or what customers reacted positively to. Rough, fast, throwaway-grade. AI prototyping tools let a PM build the first version without needing an engineer to start.
Engineers deepen it. They add functionality, surface technical implications, push it to where the team can see what’s actually being committed to.
These are primary focuses, not silos. Separating meaning from team members is dangerous. A PM who doesn’t know what’s technically possible will prototype things that can’t ship. Engineers cut off from the why will build the wrong thing, faster. The whole reason teams got smaller is to make this kind of separation harder.
The exercise has way less overhead than the PRD-to-code handoff. Two artifacts collapsed into one collaborative thing.
But prototypes only solve the spec part of the PM job. They don’t solve alignment: the prior question of which thing to build, which trade-offs the team will live with, which metric defines success, which users we’re choosing to disappoint. A prototype shows the what. It doesn’t tell you why this and not something else.
So the PM role compresses around alignment. Less time writing specs. More time talking to customers, sitting with executives to surface the real strategic question, running experiments that resolve the ambiguity. The deliverable changes from documents to decisions.
But the alignment that matters most isn’t even up-down to leadership. It’s sideways. Across marketing, sales, growth, and product. Without a PM actively connecting those functions into one story, they only talk to each other when they need something.
Marketing pulls product in only when they need a feature for a launch. Sales pings product only when a deal is on the line. The story fragments and guess who feels it: the customer.
This is where good commercial PMs earn their seat. They hold the whole arc. From how the thing gets discovered (marketing), to how users adopt it (growth), to how it gets sold (sales), to how it gets built. They walk the org sideways before the org realizes it needs to.
This is the part AI cannot do for you. Not because AI is bad at it. Because alignment is about reconciling competing humans, and AI doesn’t have skin in the game.
4. PM comp matches engineer comp.
Pay your PMs like you pay your engineers. Same bands, same levels.
Why: the role got harder, not easier. With fewer PMs covering more surface, each one needs to be unusually strong. Vision. Qualitative judgment. Quantitative literacy. The instinct to know when to be data-informed (data shapes the decision but doesn’t make it) and when to be data-driven (the data dictates the call). Most PMs do one or the other badly. The new bar is doing both fluently.
Keep PM bands a tier below engineering and you signal that PM is supporting work. It isn’t anymore. The PM determines whether the team builds the right thing.
The bottleneck moved from shipping to direction. Pay the people who own direction like the bottleneck they are.
5. Growth profile is mandatory now, for PMs and engineers.
I only hire PMs and engineers with a growth profile now. That used to be optional. It isn’t anymore.
A growth profile means the person owns four things, in addition to whatever their nominal job is.
This doesn’t mean engineers become marketers or PMs become salespeople. The bar is intuitive understanding, enough to ask the right questions when something matters. Specialists still exist; they just can’t be the only ones thinking about these things:
Marketability. Can the thing we’re building actually be sold? Does it have a hook the marketing team can use, a story the sales team can tell? Building a beautiful product nobody can communicate is a way to lose quietly. Growth-profile engineers don’t just ask “does this work?” They ask “is there a story here?”
Distribution-awareness. Distribution is no longer a problem you hand off. It’s an input to what you build. If a feature has no path to reach the user who needs it, building it is a waste. Growth-profile PMs scope ideas with the distribution channel in view from day one. They kill features that only work if marketing performs heroics.
Optimal friction. Especially with AI in the mix. The question used to be “do you want this tool?” Now it’s “do you want a tool that fits into your existing workflow with this much friction?” Optimal friction means the lowest possible cost of adoption inside the customer’s actual environment. Most products lose here without realizing it.
Attention budget. Inside any product, multiple teams compete for the same finite resource: the customer’s attention. UX research wants to recruit them for an interview. One team wants to send an NPS survey. Another wants to onboard them into a new feature. Marketing wants to push a release. Each is locally rational. Stacked together, they’re death by a thousand cuts. Marketers don’t own the total attention demand. PMs traditionally don’t either. Growth-profile people do. They notice when the org is collectively shouting at the customer and step in to coordinate.
Without a growth profile in the room, the team optimizes for what it can measure (shipped features) and ignores what it can’t (the customer’s experience as a whole).
6. What stayed.
Most of the 2024 framework held up. The principles below are unchanged:
Internal EM, embedded in the team. Engineering managers should still sit inside the team, owning hiring, coaching, technical health, and delivery cadence. The scope dropped (1-2 engineers, not 3-4), but the principle is the same.
Insourced specialists. Data scientists, UX researchers, and other specialists shouldn’t sit in a separate service team. Pull them into the product team for the duration of a project, return them to a central pool. Outsourcing this kind of skill creates the service center mentality: specialists with no business context, PMs explaining from scratch, endless back-and-forth that costs more than just hiring in.
Business casing inside the team. PMs own the case for what they’re building. Not the CEO. Not strategy. If a PM can’t connect their feature to revenue, they shouldn’t be building it.
Altitude maps. Cascading metrics from company outcomes down to team-level work. Still the cleanest way to translate between leadership language and team language.
GTM planning by PMs. Product teams own how the thing gets sold. They don’t outsource that question to whoever happens to be in marketing.
Kill the service center mentality. The spine of the 2024 guide. Still right. Outsourcing a function that should sit in the team always costs more than it saves.
AI-native teams don’t ship more. They ship the right things, with less wasted attention.
That’s harder, not easier. Fewer people, more senior, costs more per head.
If you’re racing to ship faster with AI, you’re optimizing yesterday’s bottleneck. The new one is direction. Build the team for that.
I wrote the original framework two years ago. The principles in it still hold; the ratios in this piece are the update. Read the 2024 guide.
Thank you and credit goes to Mike Pilawski for reflections and feedback on Eval focussed teams.