Stop managing, start building
How the best PMs are reinventing themselves as product builders
For the past decade, “product manager” has meant many things — strategist, roadmap owner, cross-functional diplomat, team glue, meeting facilitator. But as AI reshapes how products are built, a new archetype is now clearly emerging: the product builder.
The title change isn’t just semantics. It aligns with what I’ve argued for years: PMs need to step up, or risk becoming completely irrelevant. Many companies like LinkedIn, Zapier, and Prolific are redesigning roles around building, not managing.
AI has automated the mechanical side of product work, such as documentation, synthesis, and coordination between teams. This shift doesn’t erase the fundamentals of product craft; it amplifies them. Your job is still to find meaningful problems and deliver value — but now, your ability to think and execute with AI determines how far and fast you can go.
First principles still matter
The fundamentals of good product work haven’t changed:
Deeply understanding your customer — their jobs-to-be-done and the gaps in completing them
Deeply understanding the market you’re operating in, its competitive landscape, and how your product stands out
Choosing and building a solution with the highest ROI
And, as always, working with internal stakeholders and leading a team of designers and engineers to achieve the above
AI doesn’t alter these principles — it distinguishes PMs who apply their taste, critical thinking and judgment from those who merely facilitate. As AI makes the busywork disappear, there’s less room to hide.
So what does it actually look like to be a product builder? Among the many great PMs I’ve had the pleasure of working with or mentoring, I’ve noticed shared patterns — traits that define what it means to be an AI-fluent product builder:
1. Bias to ship, learn, and loop
AI shortens every feedback cycle. Prototypes that once took a week now take an afternoon. Summaries, analyses, and design variants appear in seconds.
Dharmesh Shah, HubSpot’s founder and one of the biggest proponents of AI, put it simply: “Never spend more time debating the priority of a product improvement than it would take to just do it.” HubSpot teams revived their “daily delights” ritual — shipping one small user-visible improvement every day. The compounding effect of that rhythm is enormous.
AI makes that cadence attainable for everyone. The learning loop tightens from weeks to hours. But here’s the catch: You have to treat this as a superpower for learning, not a license for shipping shitty features for the sake of speed.
Try this:
Every week, pick one friction in your product workflow
Prototype a fix using AI and test it
Share what you learned, not what you shipped
2. Cross-craft fluency
I’ve touched on this in my last article: the days of staying in your lane are gone. AI makes it possible — and expected — for PMs to cross the old boundaries of design, research, data, and engineering.
Product Builders build prototypes to test flows, write SQL to analyze metrics, and tweak front-end code with AI assistance. We are seeing more and more roles converge. Instead of four specialized contributors — analyst, designer, PM, engineer — you now see pairs of hybrid builders who can execute together. You don’t need mastery of every craft, but you do need literacy, and build it up to fluency.
Try this:
Pick one adjacent skill (design, data, or code)
Use AI to complete one small task in that domain — e.g., generate a SQL query or design a wireframe
Ask your expert peer to review and give feedback
PS: To be clear, this isn’t about taking anyone’s job. AI is a leveller. Designers, engineers, analysts, and PMs can all reach across the aisle to prototype, test, and ship. When you learn each other’s languages, you can move faster together.
3. Judgment and taste
AI can generate endless options. The new skill is knowing which one is worth doing.
Judgment now differentiates great builders from fast ones. When everything can be built, what should be built becomes the next hard question.
Dhanji Prasanna, Block’s CTO, warned that “we’ll need human taste to anchor these AIs so they don’t go off-script.” Taste isn’t aesthetics; it’s discernment — the ability to know when simplicity serves the user better than cleverness. In her latest blog, Elena Verna framed it nicely: “Taste is how a product earns trust. If it looks and feels like everything else, it gets forgotten like everything else.” As algorithms dominate distribution, the only moat left is emotional connection.
AI can help you brainstorm design, copy or flows, but it can’t sense when something feels off. That’s your job.
Try this:
Build a “taste library”: five products you admire for clarity and emotional pull. Reverse-engineer why they feel good to use.
Run “taste reviews” in your team — 15-minute critiques of microcopy, motion, or tone.
Ask the AI to generate five versions of a message, then pick one and explain why to a peer. You’re training your discernment muscle.
4. Systems thinking
In product work, a system is any process or product loop that gets smarter or more efficient over time.
“Systems thinking” means you stop viewing your work as a chain of isolated tasks (launch this, fix that) and start seeing how each decision feeds back into the next one — through data, learning, or team habits.
For example:
When you automate how user feedback is categorized, you’re not just saving time. You’re building a system that improves every week as more data flows through.
When you design metrics and review cadences that teach the team something after every release, you’re building a learning system.
When you set up shared AI tools that remember context across projects, you’re creating a knowledge system.
It’s the shift from “How do I deliver this feature?” to “How do I make the whole process of delivering features faster and smarter next time?”
AI supercharges this because it can connect and optimize across these loops — automating data capture, summarizing insights, or spotting patterns you’d miss manually.
Try this:
Map one workflow you repeat often (research synthesis, roadmap reviews, launch tracking). Ask: what parts teach the next cycle nothing?
Automate or document those dead ends so they feed back into learning next time.
When you introduce an AI tool, define the loop upfront: what gets smarter each time this runs?
Build small data habits: tag feedback, track usage patterns, and share them — you’re gradually building the system’s memory.
5. Ownership mindset
When anyone can automate reports, synthesize feedback, or test a prototype, there’s no reason to wait for permission. Yet many PMs still operate as if someone else owns the solution space. Product builders don’t. They run toward ambiguity and pick up loose ends without waiting around.
In companies where AI transformation worked effectively, it’s usually not because leadership handed down a plan, but because individuals took ownership. Teams built their own automations, shared results, and improved them collectively. Adoption spread bottom-up — a culture of builders solving their own problems.
Ownership mindset shows when you move past being annoyed at a bottleneck and actually fix it. It’s the moment you stop waiting for someone else to clear the path. (A bit of bragging — but this has been consistent feedback from my managers across different companies. At Meta, the note that came with my promotion and “redefines expectations” rating said: “When you find a problem, you don’t rest until you fix it.” That, to me, is the essence of ownership.)
Try this:
Identify one process everyone complains about but no one owns. Try to automate at least part of it with AI tools.
When something feels “not my job,” ask instead, “who’s better placed than me to start it?” — then start it anyway.
6. Hands-on leadership credibility
AI has flattened hierarchies. Many companies now care less about “how big of a team can you manage?” and more about “how hands-on can you be?” It’s now a common expectation for a product leader (GPM, Head of Product, or even Product Director) to do some IC work.
Hands-on product leaders gain credibility not through title or scope, but by staying close to the ground and being resourceful. You can actually make faster, sharper calls because you don’t rely on filtered updates. Staying close to the work doesn’t make you less strategic. It makes your strategy grounded.
If you manage a team, you are also best placed to drive meaningful AI adoption across their teams. When you model how to use AI in real workflows, adoption follows naturally. It signals that experimentation is safe and expected, and it grounds the AI conversation in real impact, not abstract enthusiasm.
Try this:
Block 90 minutes each week to build something yourself
In team meetings, share one concrete way you used AI to save time or improve quality
Run a short “show and tell” session where everyone demos one AI-powered workflow they’ve built
Ask your team where AI has not helped — these gaps often reveal process friction worth fixing
7. Last but not least: Ethical and sustainable judgment
Speed is seductive. AI can help you move 10x faster — but without guardrails, you risk breaking trust just as quickly. Ethical builders know when to slow down. They decide where humans must stay in the loop, how data should be used, and what responsible trade-offs look like for their product.
I’ve seen firsthand how “move fast and break things” turned dire at Meta. (I could speak for hours on this, so don’t tempt me.) Governance and guardrails shouldn’t be afterthoughts. Treat them as design principles, not constraints.
Try this:
Create a three-point check before shipping anything AI-powered:
Could this mislead, exclude, or disadvantage a group of users?
What mechanism do I have in place to alert me when the automation goes wrong?
Can a human audit or override the system easily?
Add a “trust review” to your release checklist — just like a bug bash, but for user confidence.
Final thought
The shift from “manager” to “builder” isn’t a demotion — it’s a return to what made product work exciting in the first place.
AI has stripped away layers of process and admin, leaving us face to face with the real craft: solving problems, making good decisions, and shipping things that matter.
Those who embrace that shift — who lead with clarity and curiosity — will shape not just better products, but a stronger product culture built on first principles.