Should Product Managers be Product Builders?

Is it a good thing when product managers are hands-on and use AI to build prototypes and generate code? Will it increase productivity and job satisfaction? Will it deliver better products faster? Or will it result in poorly designed applications full of technical debt that nobody wants and needs?

Listen to the audio version of this article:

Once Upon a Time in Product Land

My first experience of working in product management was mixed. I loved the actual work, especially determining the value a product should create and discovering its features. But I was put off by the heavyweight waterfall-based processes: Product managers conducted market research, built detailed feature-based roadmaps, wrote comprehensive requirements specifications, and handed them off to the development teams. In sum, they created lots of paperwork but hardly engaged with product delivery. That was in 2001.

Around the same time, I started to apply agile frameworks, which offered a radically different approach: Instead of communicating via detailed documents, product people would collaborate with one or more dev teams to jointly discover and deliver the right product—to learn faster, speed up development, and deliver better products. Maybe I was young and naive, but I was optimistic that an agile way of working would change product management for the better. And the early agile adoptions I was involved in largely succeeded in applying this new collaborative product management approach.

But the wider agile practices spread, the less this was the case. Product owners morphed into backlog managers, user story writers, and Jira ticket jockeys. The stories stopped being a promise for a conversation and turned into elaborate requirements. Product backlogs grew bigger and bigger, and features were no longer discovered and described collaboratively. The organisational inertia had beaten the new ways of working. Innovation, autonomy, and cross-functional collaboration were stifled by red tape.

With new, powerful AI tools being available, I see organisations challenge the traditional product manager role again and expect product people to be more hands-on and help co-create the actual products. But is this a good thing? Will it deliver better products faster? To answer this question, let’s start by exploring what a product builder is.

What is a Product Builder?

A product builder is a product manager who actively participates in the creation of a product—for example, by crafting mock-ups, prototyping features, or vibe coding—rather than solely directing others. It’s a new, emerging role employed by companies like Amazon and LinkedIn, and it’s sometimes also referred to as an AI product manager.[1] Some regard the role as a paradigm shift, a fundamental change in the way product managers work: they (co-) create rather than plan and coordinate.

The co-creation element distinguishes the product builder from other “modern” approaches, including agile development and continuous discovery.[2] In Scrum, a product owner discovers features together with the developers and guides product delivery by reviewing product increments. In continuous discovery, a product manager forms a product team—or product trio—with a tech lead and a designer. Jointly, they discover the right features and guide product delivery.

When product managers make hands-on contributions to their actual products, they require skills which are traditionally associated with design and engineering. These include the ability to create effective UI prototypes, as well as to architect, vibe-code, and test a software application, using tools like Loveable and Claude Code. This enlarges the skill set product managers require, which makes the role even more challenging. That’s especially true when a product builder acts as a full-stack product manager who engages in product strategy in addition to product discovery and delivery.

What are the Pros and Cons of the Product Builder Role?

To determine whether being a product builder is helpful, let’s look at its benefits and drawbacks. What’s exciting about the role is its promise for positive change: helping product managers break free from spending most of their time influencing people and orchestrating work at best, and being a feature broker and backlog administrator at worst. More specifically, the approach can offer the following three benefits:

• Higher productivity and job satisfaction: When product managers take on some of the tasks traditionally associated with designers and programmers, more can potentially be achieved with smaller teams. Additionally, working as a product builder can give individuals a sense of achievement and be more satisfying than planning work and creating documents.
• Faster decisions and shorter time to market: Being actively involved in product delivery can reduce communication overhead and eliminate waiting and delays. Instead of writing user stories, a product builder may develop a prototype and use it to validate ideas and collect feedback.
• Better products: A deep involvement in product delivery can avoid a strategy-execution chasm, result in better collaboration with designers and engineers, and lead to products that offer the right user experience and features—assuming that product builders also look after the product strategy.

But working as a product builder also has drawbacks. Building prototypes and generating code can distract product managers from their core responsibilities. It can make their work too tactical and technology-focused. It risks deprioritising the strategy work or becoming permanently overworked.

• Strategy neglect: When product people build the actual product, they risk focusing too much on the solution and not enough on the problem. Before you build, you must understand what problem you are trying to solve and if you should address it in the first place. With AI, you can create an app in an hour. But should you do it? Is the hour well invested? Or are you jumping to conclusions and possibly worrying about design aspects before you have validated the market need? And if there is such a need, is the current strategy still right, or does it have to be adapted? Strategy guides product discovery and delivery.
• Technical debt: Building successful digital products requires more than the ability to knock up a prototype and vibe code using the latest AI tools. The right design approach has to be chosen, the right architecture and tech stack have to be selected, and the code quality has to be right. If product builders don’t make the right design and architecture decisions, and if AI tools generate code that is difficult to understand and maintain, technical debt is incurred. This can negatively impact the user experience and increase future development time and costs.[3]
• Role confusion and burnout risk: Product builders may unintentionally step into design and engineering domains, undermining the team members’ autonomy, and leaving people confused about who owns what. Additionally, product people are usually busy enough with their core responsibilities. Taking on additional tasks and acting as a product builder can be overwhelming, create an unsustainable workload, and lead to burnout.

What Now?

Given that the product builder role has both benefits and drawbacks, where does this leave us? Should you become a product builder? Should your organisation start hiring for the role? Here is my take: Given the rapid technological changes we are experiencing and the opportunities they present, product managers should try out AI tools and explore to what extent they help them do a great job. As the person in charge of the product, set some time aside and experiment with tools like Figma or Lovable and Claude Code or Codex—especially to validate ideas and accelerate product discovery.

But building software should not be the main focus of a product manager—nor should it be writing user stories, administering backlogs, and fulfilling the wishes of every single stakeholder. Their real job is to maximise the value the product creates. Empathising with users, synthesising their feedback, deciding which problems actually matter, and setting effective product outcomes are still at the heart of product management.

Product managers consequently require not only product discovery and delivery expertise—they must also be skilled in product strategy: Strategy determines if and why a product should be built. Based on it, discovery identifies the right features and user experience (UX), and delivery creates the actual product.[4] If you neglect strategy—if there is no (clear) product strategy or if it is wrong or outdated—chances are that you’ll move fast in the wrong direction and offer a product nobody wants and needs, especially when using AI. Strategy guides discovery and delivery. The three areas of product management must be balanced.[5]

Note that strategy skills are also required when a senior manager, like the Head of Product or the company founder, determines the product strategy.[6] Otherwise, product managers will find it hard to effectively engage in strategy conversations, constructively challenge assumptions, and successfully influence strategic decisions. What’s more, they may struggle to effectively execute the strategy and make the right discovery choices.

If you find that the product builder approach sounds promising for your company, experiment with it to better understand the specific benefits it offers to your organisation and the challenges it presents. Choose one or two digital products that are at an early lifecycle stage, comparatively small, not overly complex, and loosely coupled to other assets. Allow the product managers to acquire the necessary builder skills and enable them to take an idea to launch as quickly as possible. Once you’ve collected enough data, review the approach together with the people involved and decide if and how to continue to apply it. As product management is context-sensitive, you may find that some product portfolios are better suited for the builder approach than others, especially in larger enterprises.

But whatever you do as the Head of Product/CPO/VP of Product, help your product managers minimise the time they have to spend on creating documents and writing requirements.[7] Empower them to regularly speak to real users, review and adapt strategic decisions, set clear product goals, collaborate with tech teams, and decline requests from stakeholders. If that’s achieved, the right paradigm shift has started.

Notes

[1] Fun fact: While researching product builder job ads to understand better which companies are hiring product builders, I found that the term is also used for manufacturing jobs where workers assemble products on a production line.

[2] See the Scrum Guide and Marty Cagan’s and Teresa Torres’ writing on product discovery and product teams. If you want to learn more about my recommendations on the latter, read the article Building High-Performing Product Teams. If you want to learn more about my recommendations on the latter, read the article Building High-Performing Product Teams.

[3] “In the AI era, code quality becomes more—not less—important. (…) Good code helps AI reason clearly, while bad code confuses both humans and AI,” writes Nan You in a Thoughtworks article published in January 2026. See also my article Technical Debt and Product Success for insights on how software quality influences the value a product creates and how to remove and prevent technical debt.

[4] This does not imply that product strategy, discovery, and delivery are sequential processes. The opposite is true. Insights gained in product delivery and discovery help evolve the product strategy. Strategy and execution are connected, as I discuss in the article The Product Strategy Cycle.

[5] I’ve been arguing for many years that product strategy is best understood as malleable and adaptive. Consequently, it has to be reviewed and updated regularly, as I explain in more detail in the article Continuous Strategizing.

[6] I generally advise against as senior managers making strategic decisions for individual products as a longer-term solution, as I explain in more detail in the article Should a Head of Product Make Strategic Product Decisions?

[7] To do this, review how product managers accomplish their work and whether the processes used are effective. Next, remove or exploit bottlenecks and eliminate wasteful tasks. Check if the status reports really are beneficial, for example. Ask if all user stories have to be captured in detail upfront (they usually don’t). Finally, explore how AI tools can be used to automate the remaining tasks and further reduce the workload of the product managers. Automating a broken process with AI creates workslop and creates little impact on employee productivity.