Speed Is Cheap. Knowing What to Build Isn't.

When engineering velocity goes up, the first instinct is to staff up around it. More product managers to write PRDs. More designers to create wireframes. More discovery capacity to feed the machine. This traditional logic feels sound: if one part of the pipeline moves faster, the bottleneck shifts upstream, and you balance it by adding headcount where the constraint now lives.

The problem with this logic isn't that it's wrong. It's that it's solving for the wrong constraint.

The pipeline is compressing everywhere

Here's what the "hire more PMs and UX" default response misses: AI isn't just accelerating engineering. It's compressing the entire product development pipeline. Product managers are prototyping ideas in an afternoon that used to take two-week design sprints. Designers are shipping production-quality front-end code without an engineering handoff. The bottleneck isn't moving neatly upstream. It's dissolving across all three functions at once.

Claire Vo, who has spent the last two years interviewing over 50 engineering, product, and design leaders on this topic, puts it plainly: the division into Product, Design, and Engineering was always a detour. A workaround for skill scarcity. When any one of these disciplines required years of specialized training to be minimally functional, functional separation made sense. AI is compressing those learning curves faster than most organizations have acknowledged. See her Maven course for more detail.

LinkedIn is already acting on this. Tomer Cohen, LinkedIn's CPO, replaced the company's traditional Associate Product Manager program with an Associate Product Builder program that teaches coding, design, and PM skills together (see this episode of Lenny's Podcast). LinkedIn now has a formal Full Stack Builder title and career ladder, meaning anyone from any function can take a product from idea to launch. Cohen's diagnosis is direct: organizational specialization was slowing features to a six-month cycle. The Builder model is a structural response to that.

What the builders framing gets right

Both Vo and Cohen are pointing at something real. The boundaries between product, design, and engineering have always been more porous than org charts suggest. The best teams I've been part of had engineers who understood users and wanted to know the "why", designers who could read a database schema, and PMs who knew what was technically expensive and what wasn't. The specialization was never as clean as the job descriptions implied.

AI is making this visible in a new way. When a PM can generate a working prototype in thirty minutes, the argument that prototyping requires a designer starts to wane. When a designer can ship front-end code directly, the handoff to engineering looks like unnecessary friction. The "builder" concept isn't utopian. It's a description of what's already happening on the teams moving fastest.

What it sidesteps

What the framing doesn't fully answer is the judgment problem.

Building something is, in most ways, the tractable part. It's a task with a defined start and end. You can measure progress, remove blockers, ship and iterate. Knowing what's worth building is a different kind of work. It requires sustained proximity to users, not just surveying them but actually understanding how they think and where things fall apart. It requires intellectual honesty about what isn't working, even when people have invested in it, and the organizational willingness to kill ideas before they become commitments. It requires a robust strategy aligned with company goals.

None of that gets easier when everyone can code. In some ways it gets harder. When the cost of building a prototype drops to near zero, the discipline required to decide which prototypes deserve pursuit has to come from somewhere other than scarcity.

The root cause the builders model exposes

Here's what AI-accelerated development is actually surfacing in most organizations: rigorous product discovery was already underfunded and undervalued before any of this. The problem predates the acceleration.

PMs were managing backlogs and negotiating priorities. Designers were executing on requirements handed down from above. The genuine "figuring out what to build" work, the kind that requires sitting with ambiguity, talking to users repeatedly with iterative designs in hand, and being willing to report back that the original hypothesis was wrong, was happening informally, inconsistently, or not at all. A slower engineering pace masked the cost of this. Nobody noticed the GPS was off because the vehicle wasn't moving very fast.

When you can ship ten times as fast, the bill will likely be ten times more.

What this means for how you lead

Two gut responses are equally wrong.

The first is hiring more PMs and UX designers to "keep up" with faster engineering, treating them as throughput functions whose job is to generate enough input to keep engineers busy. That model was always a bit broken. It doesn't hold up in a world where engineering can outpace almost any team's ability to produce raw specifications.

The second is collapsing everyone into "builders" without preserving any dedicated investment in the upstream judgment work. The builder model is a genuine improvement over rigid functional silos. That said, it doesn't automatically produce better answers to the hardest question, which is what to build.

The harder question for any leader: who, specifically, owns the "what to build" question in your organization? Not who writes the specs, not who manages the backlog, but who has the time, the user access, and the actual authority to say "we shouldn't build this"? That function is under the most pressure right now, and in most organizations it's the least protected.

A faster machine needs a clearer destination. Getting that right is harder than hiring for it.

Note: Light AI assistance used for editing and idea refinement.