The AI Product Builder is a new archetype — someone who can identify a problem worth solving, frame it as a compelling narrative, determine what's actually true, and build a working solution in hours. A framework for the role that's replacing the org chart.
"I realized we've been asking the wrong questions for a while now."
That was the CEO of a Chicago-based media, events, and publishing company, a few weeks into working with our team. Her organization had no technology leadership, no product team. What they had was a clear picture of their business problems, access to the same AI tools everyone else has, and our team helping them see what was newly possible. The old constraints had been shaping which questions they even thought to ask.
Around the same time, at another client focused on live corporate events, a semi-technical IT professional who'd never written code built a custom project management system with CRM integration. Complete with UX tailored to their workflows, replacing a legacy SaaS tool they'd been paying for. They understood the system architecture and the business use cases. That was enough.
I've been watching this pattern accumulate for years.
It started at Salesforce, where I was a product manager chafing against learning cycles that stretched into years before code ever touched a real user. The wrangling required just to begin working on something, across exec leadership, design, engineering, and product, was its own full-time job. Building required a relay race across specialized functions, and I wanted to close the loop between insight and artifact myself.
When I left to start my own company, I had to close that loop myself. I learned sales and marketing because I needed to understand authentic demand and product-market fit, and no PM framework could substitute for sitting across from a prospect and hearing what actually mattered to them. That experience rewired my sense of what the role even was. Something more integrated than any single title described.
Then AI tools collapsed the last remaining barrier. I built production analytics and operations systems for a client over a weekend, systems they still use daily. And I watched non-technical people at client organizations do the same, building real tools because the gap between understanding a problem and implementing a solution had narrowed to almost nothing.
The industry is calling this person a "product builder," and the term is everywhere. But most of the discourse treats it as a rebrand of "full-stack PM" or "technical product manager." That undersells what's actually happening.
The AI Product Builder is a new archetype. It requires a different anatomy.
Ravi Mehta's Product Competency Toolkit remains the most rigorous attempt to define product management as a discipline.1 His 12 competencies organize into four quadrants: Product Execution, Customer Insight, Product Strategy, and Influencing People. From these, he draws a key distinction: Product Builders (biased toward execution and people) versus Product Architects (biased toward insight and strategy).2
The framework assumed that building was hard and slow, so specialization was necessary. The Builder drove nails. The Architect drafted blueprints. Both were critical, but they were different people.
That constraint is dissolving. Fareed Mosavat at Reforge calls it the "rise of the builder," where the person with the idea and the ability to show the path forward collapses most of the alignment overhead.3 Figma's 2025 research quantifies the shift: 70% of PMs now create wireframes, 57% of developers prototype significantly, and 65% of PMs engage in at least one design task.4
The AI Product Builder doesn't sit in either hemisphere of Mehta's model. They collapse the distinction, because AI has made the distance between intent and artifact trivially small.
The AI Product Builder operates across four integrated domains, more like the four chambers of a heart than competency buckets to specialize in. Each serves a distinct function. The organism dies if any one fails.
Purpose. What are we building, and for whom? Direction. Which sequence of bets gets us there fastest? Motivation. Why does this matter enough to endure the ambiguity?
When anyone can spin up a prototype in an afternoon, the bottleneck shifts from engineering velocity to product clarity. Andrew Ng has suggested the developer-to-PM ratio could soon flip to 2:1, compared to the old norm of 1:4-6.5 The binding constraint will be knowing what's worth building.
Purpose is the capacity to articulate what you're building and why it matters, clearly enough that others can act on it without translation. The AI Product Builder expresses vision through artifacts, not abstractions. You build a prototype that embodies the bet.
Direction is continuous prioritization under uncertainty. Roadmapping, when you can test ideas in hours, stops being a quarterly planning exercise and becomes a weekly discipline. New information arrives constantly from prototypes that didn't exist yesterday. The job is to absorb it and adjust the sequence of bets.
Motivation is the ability to connect daily building to organizational purpose in a way that sustains effort through ambiguity. When you're iterating on four prototypes a week, the risk of losing the thread is enormous. The leader's job is to hold it. In Mehta's model, "Influencing People" was about getting resources allocated across a division of labor. Here, the builder often is the team, and influence is about creating conviction around direction.
Design. From interface to inquiry. Storytelling. Narrative as the medium of adoption. Sales & Marketing. Reading demand, not manufacturing it.
This pillar has no equivalent in existing product competency models. When execution becomes cheap, taste becomes expensive. When anyone can build a functional prototype, the differentiator is whether it resonates. Jenny Wen, Head of Design at Claude, describes the emerging "block-shaped generalist," someone strong across multiple areas at once.6 For the AI Product Builder, that breadth has a center of gravity: narrative coherence.
Design starts where most people think it ends. Yes, it includes UX, UI, and visual design, the surface-level craft of making things usable and beautiful. But it extends deeper: into user interviews that surface needs people can't yet articulate, into design thinking as a structured method for navigating ambiguity, into the discipline of beginning with what a person feels and working backward to the system. "What does this feel like to use?" before "What does this do?" When you can build anything in an afternoon, the quality of the question becomes the quality of the product.
Storytelling is the connective tissue between what you've built and why anyone should care. Every prototype is an argument. Every demo is a pitch. Framing your work as a story, with a protagonist, a problem, a turning point, and a resolution, will consistently outperform showing features.
Sales & Marketing are here deliberately. Bob Moesta's demand-side sales work makes the point that people don't buy because of features.7 They buy because they're struggling with something and the product fits the progress they're trying to make. The AI Product Builder has an unusual advantage: because they built the thing, they understand the struggling moment at a granular level. They can read authentic demand, distinguish it from polite enthusiasm, and close accordingly.
Structured Problem Solving. Discipline before solutionism. Systems Thinking. Context, dynamics, and second-order effects. Scientific Discipline. Rigor as an epistemic practice.
If Poetry is the heart of this archetype, Strategy is the spine. When building is fast and cheap, the failure mode is shipping the wrong thing quickly and with conviction. Speed without strategic discipline produces a graveyard of functional prototypes that solved imaginary problems.
Structured Problem Solving is the disciplined decomposition of the actual problem before reaching for a solution. This sounds obvious and almost never happens. The temptation to build first and ask questions later is almost irresistible when the distance from idea to prototype is measured in hours.
Systems Thinking is the ability to see a problem in context: organizational dynamics, market structure, user workflows, second-order effects. Donella Meadows' leverage points framework matters here.8 The builder who can identify whether they're operating at the level of parameters, feedback loops, rules, or goals will consistently find higher-leverage interventions than the one who builds what's requested.
Scientific Discipline is the epistemological commitment that separates the AI Product Builder from the vibe-coder. Vibe-coding is a method. Scientific discipline is a practice. Pre-register predictions, design controlled comparisons, update beliefs based on evidence, resist the confirmation bias that comes from having personally built the thing being tested. Mehta's "Product Strategy" quadrant asks whether you can drive business impact through product innovation. This pillar regrounds that question: can you reliably determine what's true? The business impact follows.
Prototyping. Building as a cognitive tool. Data Analysis. Fluency at the speed of iteration. Agentic Orchestration. Directing AI systems as force multipliers.
This is the pillar everyone wants to talk about, and the easiest to overweight. Vibe-coding, the term Andrej Karpathy coined in February 2025, describes building by intent: describe what you want in natural language, let AI generate the implementation.9 By early 2026, roughly 85% of developers use AI tools regularly.10 The developer's role shifts from code author to product director.
Prototyping is the ability to go from idea to working artifact quickly enough that building becomes thinking. The prototype is the spec. The demo is the PRD. The things you make become the medium through which you communicate, test, and decide.
Data Analysis is the ability to interrogate what you've built. When you can ship four variants of a feature in a week, you need the analytical muscle to determine which one actually works. The feedback loop between building and measuring has compressed from weeks to hours.
Agentic Orchestration is the emerging frontier: systems where AI agents handle recurring workflows, monitor performance, and iterate semi-autonomously. The builder doesn't just use AI to code faster. They architect fleets of agents that extend their own capacity, functioning as a one-person team. Mehta's "Product Execution" quadrant was the foundation of PM work, the baseline you mastered before advancing to strategy. Here, execution is abundant. The hard problem is directing it.
Someone who can identify a problem worth solving, frame it as a compelling narrative, determine what's actually true, and build a working solution in hours.
This person already exists. They're the PM prototyping in Cursor. The designer shipping code through Claude. The founder who demos on Tuesday what they imagined on Monday. The consultant who walks into a client meeting, hears a problem, and has a working prototype before the follow-up call.
The question isn't whether this archetype will emerge. It already has. The question is whether we'll build the language, the frameworks, and the development paths to cultivate it deliberately, or keep hiring for roles that map to an org chart that no longer describes how products get built.
The four pillars draw on and extend Ravi Mehta's Product Competency Toolkit, Reforge's product leadership curriculum, and the emerging discourse around the "product builder" archetype.
Ravi Mehta, "How To Become a Peak Product Manager," ravi-mehta.com, May 2020. https://www.ravi-mehta.com/product-manager-skills/ ↩
Ravi Mehta, "What's Your Shape? A Product Manager's Guide to Growing Yourself and Your Team," ravi-mehta.com, April 2020. https://www.ravi-mehta.com/product-manager-roles/ ↩
Brian Balfour & Fareed Mosavat, "Moving To Higher Ground: Product Management In The Age of AI," Reforge Blog. https://www.reforge.com/blog/ai-impact-product-management ↩
Figma, "Shifting Roles: How Product Teams Are Evolving," 2025. https://www.figma.com/reports/shifting-roles-product-teams-evolving/ ↩
Andrew Ng, cited in "Will AI Replace Product Managers by 2035?" Product School, 2026. https://productschool.com/blog/artificial-intelligence/will-ai-replace-product-managers ↩
Jenny Wen, in conversation with Lenny Rachitsky, "The design process is dead. Here's what's replacing it," Lenny's Newsletter. Referenced via Mateusz Litarowicz, "Will AI make us all product builders?" Fundament, March 2026. https://www.fundament.design/p/will-ai-make-us-all-product-builders ↩
Bob Moesta, Demand-Side Sales 101: Stop Selling and Help Your Customers Make Progress, Lioncrest Publishing, 2020. ↩
Donella Meadows, "Leverage Points: Places to Intervene in a System," Sustainability Institute, 1999. ↩
Andrej Karpathy, post on X (formerly Twitter), February 2, 2025. ↩
DesignRevision, "What Is Vibe Coding? The Developer's Guide to AI-First Development (2026)," citing industry survey data, March 2026. https://designrevision.com/blog/vibe-coding ↩
