There’s a particular kind of product manager I’ve come to value above all others. They’re not the ones with the most polished presentations or the most impressive frameworks. They’re the ones who can look at an ambiguous problem and just start building something. They’re not afraid to take risks and more than ever they realise that just building trumps perfection.
Builder PMs are the most valuable players on any product team. Back in the day a PM might be judged on the quality of their strategy or presentation. Those are important things but honestly, in our world where AI has sped up so much of this, I want a PM who can just ship stuff and get data back to keep moving.
The Distance Problem
Here’s what I’ve observed across Google, my agency work, Healthily, and now Hilo: the further a product manager sits from the actual work, the worse their decisions become. When you’re only coordinating through Jira tickets and specifications, you lose the texture of the problem. You lose the feel for what’s hard and what’s easy. You lose the ability to spot when your elegant solution doesn’t actually work in practice.
Builder PMs shrink the distance between customer truth and product decisions. They don’t wait for engineering to tell them something’s impossible – they prototype enough to understand the constraints themselves (And this stage can be done in minutes using AI tools such as Lovable). They don’t wait for design to explore options, they sketch enough to frame the problem. They don’t wait for data science to run analysis – they pull the data and look at it.
This isn’t about replacing specialists. It’s about building enough context that when you collaborate with specialists, the conversation is richer and the decisions are faster. And if a PM can’t ‘do it all’ then at least empower them to reach out to the teams for speedy insights – stuff doesn’t have to wait to be fed into a process.
What “Builder” Actually Means
Let me be clear: being a Builder PM doesn’t mean you need to be able to ship production code or create pixel-perfect designs. It means you’re willing to get your hands dirty enough to reduce uncertainty before you ask others to invest their time.
In practice, this looks like:
Instead of: Writing a 10-page spec and waiting three weeks for engineering to estimate it.
Do this: Spend four hours building a rough prototype with no-code tools or AI to understand the technical shape of the problem, then have a 30-minute conversation with engineering about the real constraints.
Instead of: Requesting a data analysis and waiting for the queue to clear.
Do this: Pull the raw data yourself, do basic analysis in a spreadsheet, form a hypothesis, then ask data science to validate or challenge it. And if you’re not able to do then build a trusted network of people who don’t mind helping out ad-hoc.
Instead of: Describing what you want users to be able to do.
Do this: Create a clickable wireframe – even if it’s rough – so everyone can experience the interaction rather than imagining it.
The goal isn’t perfection. The goal is concrete evidence that moves the conversation forward.
The Tools Have Changed Everything
This matters more in 2026 than ever before: the tools are too good now for PMs to be helpless. Today, PMs can go from idea to interactive prototype in minutes with AI tools like Replit, Bolt, and Claude’s artifacts. The list goes on.
When I started in product, building anything meaningful required weeks of engineering time. Now I can have a functional proof-of-concept in an afternoon. The barrier isn’t technical capability anymore – it’s willingness to try.
This changes what it means to be a good product manager. If you have an idea for a new AI feature, you should be able to prototype it yourself before you ask engineering to build it. Not production-quality – just enough to learn whether the idea has legs.
As one CPO I respect puts it: “Stop telling – start showing. That’s PM 2.0.”
Understanding How Product Work Gets Done
Builder PMs understand how product work gets done across roles. They’re not experts in every role, that’s impossible and unnecessary. They’re fluent enough to ask better questions and surface evidence earlier.
This means:
- Knowing enough about engineering to understand what’s actually technically complex versus what just sounds complex
- Knowing enough about design to distinguish between aesthetic choices and fundamental UX problems
- Knowing enough about data to spot when an analysis is meaningful versus when it’s correlation noise
- Knowing enough about GTM to write copy that sells, not just describes
When you have this fluency, you reduce uncertainty before alignment becomes necessary. You don’t need a two-hour meeting to decide whether something’s worth exploring, you can build just enough to know.
The Opposite of Builder: Coordinator
I’ve worked with plenty of talented PMs who aren’t Builders, and some of them are very successful. But the ones struggling most in 2026 are the pure Coordinators – people whose entire job is moving information between other people.
Coordinator PMs schedule meetings, write tickets, update status reports, and manage timelines. All of this is necessary. None of it is sufficient.
When structure thins out, and it is thinning out across the industry, Coordinators lose their footing. They need the structure to know what to do. Builder PMs create structure by doing the work that clarifies what work needs to be done.