The full-stack builder is real. So is the ceiling it hits.
In December 2025, LinkedIn’s chief product officer Tomer Cohen went on Lenny’s Podcast and announced something that should have been a bigger story than it was. LinkedIn was scrapping its associate product manager programme entirely. In its place, a new associate product builder track, teaching new hires to code, design and manage product as one integrated skill rather than three separate ones (Lenny’s Newsletter, AOL/Business Insider). Cohen’s language was pointed. He called the traditional model organisational bloat, and argued that a single person who can take an idea from concept to launch, regardless of which discipline they started in, will always beat a relay race of handoffs between PM, designer and engineer.
He isn’t wrong, and I want to be honest about that before I make the opposite case. The economics are genuinely compelling below a certain size. Lovable went from nothing to ten million dollars in annual recurring revenue in sixty days with a team of fifteen people (Lenny’s Newsletter). Cursor and Windsurf tell a similar story. When one person can define the problem, prototype the interface and ship working code without waiting on two other departments, iteration speed doesn’t improve incrementally, it multiplies. If you’re building a first product with a small team and a short runway, hiring three specialists instead of one capable generalist is close to indefensible. Over the past few years I’ve seen this create a newfound excitement in product and engineering teams, scrap that, just in teams! What happens is that time accelerates, you’re suddenly shipping real stuff at a fraction of the time or process than before.
For many it is has been inspiring, addictive and provided those who have been plodding along with a drive and vigour that reminded me of when I first spun up Netscape’s browser in Utrecht in 1996!
The trouble starts when people extend that logic past the point where it holds. Like all good things boundaries are there for reasons.
I’ve watched this exact pattern play out more than once and always with the same shape. A small team proves that generalists plus good tools beat specialists plus process, and the organisation concludes that the lesson scales linearly with headcount. It doesn’t. Ravi Mehta wrote a sharp piece on this recently, built around a story from a team that shipped a product review meeting straight past its own process because a full-stack builder had moved fast enough to skip it (Ravi Mehta). The interface looked credible. Nobody in the room had the design background to notice the parts that weren’t, until a customer did. His point lands cleanly: specialised judgement doesn’t disappear just because one person can now do the mechanical parts of three jobs. It just goes missing quietly, and you don’t find out it’s missing until something ships that shouldn’t have.
There’s a second cost that gets even less attention, and it’s the one I think boards should actually be asking about. Zoe Scaman wrote about this under the banner of “the pipeline problem,” describing how the senior-talent-plus-AI narrative in agencies (S4 Capital’s Monks model being her example) quietly finishes off a trend that had already started before AI gave it a respectable cover story: the slow disappearance of junior roles as a place where people are actually developed, not just deployed (Zoe Scaman). Product has the same exposure. A generalist “builder” track sounds like a brilliant way to train broad, adaptable talent. It can also be a brilliant way to stop training anyone deeply in anything, because there’s no longer a designer three desks away whose whole job is catching the mistakes a generalist doesn’t know to look for. Mentorship was never really a scheduled activity. It happened by proximity, by a specialist correcting a generalist’s blind spot in the normal course of work. Collapse the roles and you don’t just lose the specialism, you lose the mechanism that used to grow the next generation of specialists.
I’ve seen this play out badly – the builder think that their empowerment makes them a domain expert, even when building in guardrails in AI or data. Their lack of empirical thinking in the domain (for example design) cannot possibly be considered by AI and the deliverables are often generic, not idiosyncratic enough. Craft organically where it matters, use tools to accelerate process but be mindful of throwing everything but the kitchen sink at the ‘builder’ or you’ll end up with chaos, rework and dispirited teams that went from amazed to disappointed.
None of this is an argument against the builder model. It’s an argument about where it belongs. Below roughly fifty people, in one product, with a founder or a handful of senior operators who can hold the whole thing in their heads, full-stack building is probably the right call, and LinkedIn’s own experiment sits inside a company big enough to run it as a contained programme rather than the whole operating model. Past that size, across multiple products, multiple customer segments and multiple regulatory environments, the thing that made the small team fast (one person owning the full context) becomes the thing that makes the large organisation fragile, because context that used to live in a specialist’s head now lives nowhere at all.