Welcome to Frank Takeaways. I'm Frank, writing the notes worth keeping from decades at companies like Slack, Etsy, and Google. I run a coaching practice dedicated to guiding leaders through the tricky stuff of building products and high-performing teams.
Join my referral program and earn 1:1 coaching sessions by sharing Frank Takeaways with others - start with just three referrals.
—
A coaching client asked me a question last week:
“What are your thoughts on the emerging ‘full stack builder’ PM model — what do you think about it and what does it mean for product leadership?”
I started typing a response and then stopped. Deleted it. Started again. The question sounds simple but it’s actually three questions tangled together: Is this real? Is it new? And what should leaders do about it?
I’ve been turning it over for days. Here’s where I’ve landed.
The Skeptic's Take
My first instinct was skepticism. I've been in product long enough to see trends come and go. Every few years, someone announces a new model for what PMs should be. T-shaped PMs. Technical PMs. Growth PMs. Now full-stack builder PMs.
So I asked myself: is this actually different from what strong PMs have always been?
Not entirely.
When I hire PMs, I've always looked for one or two hard execution skills. Product management is a leadership discipline, and the best leaders flex to the needs of their team. The deeper skills you have, the more ways you can flex. Former engineers who can debug. Former designers who can mock up solutions. Former analysts who can dig into metrics.
The "full stack builder" is just another station. Useful? Sure. Revolutionary? I'm not convinced.
But Something Is Different
Here's where I have to check my own skepticism.
The tools have changed. Meaningfully. Cursor, Claude Code, Lovable, Replit. These aren't incremental improvements. A PM can now go from idea to working prototype in an afternoon. Not a mockup. Not a spec. Working code that users can touch.
I know because I'm doing it. After my kids go to sleep, I ship real features to real products. Small SaaS tools I've built. Recipe apps. Practice management software. Not prototypes. Production code. A few years ago this would have required hiring engineers or learning to code properly. Now I can build things I couldn't have built before.
That's not nothing.
Asha Sharma put it well on Lenny's podcast recently: "It's all about the loop, not the lane." The old model was lanes. Design stays in their lane, engineering in theirs, PM in theirs. Work moves linearly through the system. The full stack builder collapses that. You own the whole loop: idea to build to user feedback to iteration. No handoffs. No tickets. No waiting for the next sprint.
When the loop gets tighter, learning gets faster. And learning is the whole point of shipping in the first place.
So yes, something is different. The cost of building has dropped. The speed of iteration has increased. More people can participate in the build cycle than ever before.
But I keep coming back to a question: does faster building actually make better products?
The College Town Theory
There's this thing that happens in college towns. The commerce district turns over constantly. New restaurants open, old ones close. The names change. The decor changes. The menus change.
But somehow it's still a lot of bars.
The surface changes, but the underlying structure stays the same. Students want cheap drinks and late nights. The market demands what the market demands.
Product management feels similar to me right now.
The tools are new. The speed is new. The "full stack builder" framing is new. But the underlying job hasn't changed. You're still trying to figure out what problem to solve. You're still trying to design a solution that works. You're still trying to ship something that creates value for users and for the business. You're still trying to learn from what happens and do it better next time.
The loop is faster. But it's the same loop.
This matters because I see people confusing speed with progress. A PM who can ship twelve features in a quarter feels productive. But if none of those features moved the needle, what was the point? You can iterate yourself in circles.
The hard part of product management was never the building. It was knowing what to build. That hasn't changed.
What Leaders Actually Need
The question was about product leadership, so let me try to answer that directly.
If you're leading a PM team right now, here's what I'd focus on:
Hire for judgment, not just execution. Yes, it's great if your PMs can prototype. But prototyping is a skill you can teach in weeks. Judgment takes years. The ability to look at a problem and know which parts matter. The ability to make a call with incomplete information. The ability to recognize a bad idea before it's built. These are the hard things, and they're the same hard things they've always been.
I still interview for hard skills. I still want PMs who can do things beyond the core PM toolkit. But I'm more interested in how they think than what they can build. Show me a candidate who can ship a prototype in an afternoon but can't articulate why that's the right problem to solve, and I'm worried. Show me a candidate who asks uncomfortable questions about whether we should build something at all, and I'm interested.
Close the learning loop. Here's where I see full stack builders get into trouble: they ship, then immediately ship again. The build cycle is so fast that they skip the learning part. They iterate without reflecting. They optimize without questioning.
Shipping is the best way to learn. It always has been. But only if you actually learn. That means talking to users after you ship. It means asking "what did we expect to happen and what actually happened." It means having someone challenge your interpretation of the results, not just your spec before you built it.
The friction shouldn't come before the build. It should come after. Build fast, ship fast, then slow down long enough to understand what you learned. Then build again.
Teach the strategy work explicitly. Vision, strategy, roadmap. These don't emerge automatically from shipping fast. They require a different kind of thinking. Zooming out instead of zooming in. Asking "why this and not that" instead of "how do I build this." If your PMs are heads-down in execution all the time, when are they developing this muscle?
I've started asking my coaching clients a simple question: what did you learn from the last thing you shipped? Not what did you build. What did you learn. Half the time they can't answer. They've already moved on to the next thing. The strategy muscle atrophies if you don't use it, and execution can feel like progress even when you're just spinning.
Model the curiosity. The best product leaders I know are tinkering with these tools themselves. Not because they need to ship code, but because they need to understand what's possible. You can't lead a team through a shift you don't understand firsthand. You don't need to become a full stack builder yourself. But you do need to know what your team can now do that they couldn't do before.
The Question I'm Still Sitting With
Here's where I landed. The full stack builder trend is real, but it's more evolution than revolution. The tools have changed. The speed has changed. But the core discipline hasn't.
Product leadership is still about solving the right problems. Still about building teams that can execute with judgment. Still about creating clarity in ambiguity. None of which are solved by knowing how to code.
The risk isn't that PMs are building too fast. Speed is a gift. The risk is that they're shipping without learning. Iterating without reflecting. Moving on to the next thing before they've understood the last thing.
But here's the question I keep coming back to: How do we develop judgment and taste when the loop is this fast? The answer, I think, is that you develop it through the loop, not before it. You build, you ship, you learn, you get challenged on what you learned, and then you build again. The reps compound. But only if you're actually closing the loop.
The names change. The tools change. The discourse changes.
But at the end of the day, you're still trying to solve someone else's problem. That part hasn't changed. And if you lose sight of it, all the building speed in the world won't help you.
Still a lot of bars.
"Shipping is the best way to learn. It always has been. But only if you actually learn." That really stuck with me.