Should Product Managers be Product Builders?

Speaker A: Foreign. Product Management Podcast When I started out in product management, my initial experience was mixed. I love 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 product managers would conduct market research, build detailed feature based roadmaps, wrote comprehensive requirement specifications which they then handed off to the development teams. So they created lots of paperwork but hardly engaged in product delivery. Now that was back 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 development teams to jointly discover and deliver the right product. The idea was to learn faster, speed up development and simply deliver better products. Now I might have been young and naive, but I was optimistic that an agile way of working would change product management for the better. And the the early Agile adoptions I was involved in largely succeeded in applying this new collaborative product management approach. However, 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 ah, promise for a conversation and turned into elaborate requirements. Product backlogs grew bigger and bigger, uh, and features were no longer discovered and described collaboratively. The organizational inertia had beaten the new ways of working. Innovation, autonomy and cross functional collaboration were stifled by red tape. Now with new powerful AI tools being available, IC organizations 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 or just lead to a lot of poorly designed products full of technical debts that nobody really wants and needs? Now to answer these questions, let's first explore what a uh, product builder is. A product builder is a product manager who actively participates in the creation of a product, for example by crafting mockups, 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. 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, and this co uh creation element distinguishes the product builder from other, you could say contemporary or modern approaches, including agile development and continuous discovery. 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, also referred to as product trio together with a tech lead and a designer, and jointly they discover the right features and guide product delivery. When product managers make hands on contributions to the actual products, they require skills which are traditionally associated with design and engineering. These include the ability to create effective UI UX prototypes, as well as to architect vibecode and test a software application using tools like Lovable and Claude code for instance. And this enlarges the skill set product managers need and that makes the role even more challenging. That's especially true when a product builder is also a full stack product manager, and that means that the individual engages in product strategy work in addition to product discovery and delivery. Now to determine whether being a product builder is helpful, let's look at its benefits and drawbacks. What I find 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 and worst. More specifically, the approach can offer the following three first, 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 the individuals a sense of achievement and be more satisfying than planning work and creating documents. Second, 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. And third, better products. A deep involvement in product delivery can avoid a uh, 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. However, working as a product builder also has drawbacks. So let's look at three major ones. The first one is strategy neglect. When product people build the actual product, they risk focusing too much on the solution and not enough on the problem. Now, before you build, you must first understand what problem you are trying to solve and if you should address it in the first place. With AI, you can certainly create an app in an hour or so, but the question is, 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 a validated market need, is the current strategy still right or does it have to be adapted? After all, strategy guides product discovery and delivery, and without an effective strategy, we risk making the wrong feature UX choices and getting the architecture and tech stack wrong. The second drawback is technical debt. Building successful digital products requires more than the ability to knock up a prototype in 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 and this can negatively impact the user experience and increase future development time and costs. And the third drawback is 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 usually are 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. Given that the product builder role has both benefits and drawbacks, where does this leave us? Should you become a product builder? Should your organization start hiring for the role now? Uh, here's my take. Given the rapid technological changes we are experiencing and the opportunities they present, product managers should definitely try out AI tools and explore to which extent they help them do a great job. So as a product manager, set aside some time to experiment with tools like Figma or Lovable and Claude Code, uh, 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. The real job is to maximize the value a product creates. Empathizing with users, synthesizing feedback, deciding which problems actually matter, uh, 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 and based on it. Discovery identifies the right features and user experience and delivery creates the actual product. Now, if you neglect a 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 really wants and needs. Especially when using AI strategy guides discovery and delivery, as I've mentioned before, and these three areas of product management must be balanced. Note that strategy skills are also helpful when a senior manager like the head of product or company company founder determines the product strategy, which is not something that I recommend, at least not as a permanent solution. But if you are a contributor, you are a product manager, and you lack the necessary strategy skills, you'll find it hard to effectively engage in a meaningful conversation, constructively challenge strategy assumptions, and successfully influence strategic decisions. What's more, you might struggle to effectively execute the strategy and make the right discovery choices. Now, if you find that the product builder approach sounds promising for your company, then I recommend that you experiment with it to better understand the specific benefits it offers to your organizations and the challenges it presents. Choose one or two digital products that are at an early life cycle stage, comparatively small, not overly complex, and loosely coupled to other assets. Allow the product managers to acquire the necessary builder skills and empower 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 ah, are better suited for the builder approach than others, especially in larger enterprises. But whatever you do as the Head of Product, Chief Product Officer, uh, VP of Product Management, help your product managers minimize the time they have to spend on creating documents and writing requirements. Empower them to regularly speak to real users, review and adapt strategic decisions and set clear product goals. Collaborate with tech teams and have frank conversations with the stakeholders. If that's achieved, the right paradigm shift has occurred. I hope you found my advice helpful to deepen your strategy skills. Attend my Product Strategy and roadmap workshop and read my book Strategize. And if you want me to deliver the workshop to your team, then contact me. Thanks for listening.