The Builder PM

Welcome and Speaker Introductions

Cynthia Petti & Rina Alexin | 00:00:00 – 00:02:52

Hello. Thanks for coming in, everyone. We have a few more people joining. If you want to get started, feel free to tell us your name and where you’re joining from: city, state, country.

Hi, Dean. Good to see you. Dean is going to get some shout-outs today.

All right. I think we’re going to get started shortly. My name is Cynthia Petti. I’m located in Austin, Texas. Normally I’m sitting right next to Rina, but we thought that might be a bit confusing doing the webinar side by side. So, hi everyone. And hi to all the folks joining us from LinkedIn Live.

Rina Alexin | 00:01:30 – 00:02:52

Hi everyone. My name is Rina Alexin. I’m the CEO of Productside. I’ve been running the company now for eight years, and I’m excited to be sharing my thoughts around the Builder PM with you today. Please pop into the chat, say your name and where you’re calling in from. The more engagement there is from all of you, the more valuable this webinar really becomes. And we have Robin behind the scenes keeping it all going for us. Thanks, Robin.

About Productside

Cynthia Petti | 00:02:52 – 00:04:05

Before we get into the content, a little bit about us. We have been around for many years, and we work hard to teach people not only to deliver products that get used, but that people truly love. Whether that’s getting your stakeholders aligned, understanding your customer needs, or managing the endless backlog, we’ve seen it all and we’re here for you.

At Productside, we believe in:

• Outcome-driven partnership: complete solutions for transformation from strategy to execution
• Tailored expertise: your challenges are unique and we listen to you
• Invested experts: consider us an extension of your team, someone to lean on
• An obsession over your success at every step

Webinar Logistics and Community Connection

Cynthia Petti | 00:04:05 – 00:05:35

A few quick logistics before we get going:

• This webinar is being recorded and will be shared with all attendees
• Use the Q&A feature to ask questions as we go through the content, we will be monitoring them
• The chat is open as well. Keep in touch and connect with us there
• We have a LinkedIn group where like-minded people share best practices, ask questions, and even post opportunities. Scan the QR code on screen or look for the link in chat

And some of you are joining us from LinkedIn Live, so welcome to everyone watching there as well.

Goals of the Webinar

Rina Alexin | 00:05:35 – 00:06:35

So what are we doing today? I have a few goals. First, I want to help define the Builder PM, the product engineer, or whatever other term is being thrown around online. Then we are going to talk about what it really takes to build, and more importantly, how to create leverage. This webinar is really split into two parts, and as always, we will leave you with a few concrete things to do after this session ends.

One thing I want to say upfront: if you were expecting more anxiety, more things to do, or more “here are your 10 AI skills you need to know now or you won’t succeed,” this is not that webinar. My goal is actually to cut down the noise and make it more tangible and real.

The Myth of the Unicorn PM

Rina Alexin & Cynthia Petti | 00:06:35 – 00:09:13

The Builder PM is sometimes talked about like a mythical creature, a unicorn, someone who can:

• Solve the CFO’s headcount problem single-handedly
• Do product, UX, and understand the market
• Build the solution and shape it end to end
• Handle three jobs on one salary

While we did talk about compression of roles in our previous webinar, I am not insisting that this unicorn is what we are trying to get to. This is not a promotion.

The more I talk with leadership, the less I think this is actually where the future of product management is heading, even though there is some overlap and AI certainly has a role.

Here is what we are actually here to think through:

• AI has collapsed the cost of building. How does that change our roles?
• Are we supposed to be moving faster?
• Do leaders still need the same types of people on their teams?
• What should the real expectations of product managers be?

At Productside, we think a lot about roles. We want to be a partner to the product community to help understand what is working and what is not, because this is the storming and experimenting phase as people adopt this new technology.

The question should not be: how do I as a product manager take over engineering now that I can work within an AI coding tool? The question should really be: how do I embrace AI and help it make me a 3x, 5x, or even 10x product manager?

When AI collapses the cost of building, it also collapses the cost of learning. And the product manager who learns how to use AI to learn faster is the person who is really going to win. That is my goal today.

Poll: How Is AI Changing Your Role?

Rina Alexin & Cynthia Petti | 00:09:13 – 00:11:28

Here is our first poll. It helps me get a lay of the land on how AI is changing your role today. How do you work with AI and AI agents right now?

• You use AI tools, notice when output is bad, and fix it case by case
• Your workflows have defined success criteria you use to improve the system
• You have feedback loops that improve the system automatically
• Not quite there yet

There is no right or wrong answer. You are here showing up for yourself so you can learn and apply things.

Let’s look at the results. About 58% are using AI tools. And I notice that nobody answered that feedback loops improve the system automatically. This is perfect. This webinar was built to help with exactly that. I am glad to see it reflected in the room.

The 10x Product Manager

Rina Alexin | 00:11:28 – 00:15:48

So what does the Builder PM actually look like when it works? Here is what I am positing: a product builder is a 10x product manager. Someone who has understood how AI can really enable them, and who also does not let go of what is core and valuable about product management.

About six months ago when I was talking to leadership about role compression, there were a lot more voices saying, “Yes, I want to see product managers build.” Companies were experimenting with the term “product engineer,” trying to find someone who can navigate both what do we build and how do we build it.

But now when I talk to leadership, the ones who have tried it are identifying real negatives with that approach. A couple of important ones:

You lose something real when one person is responsible for the whole thing. Diverse teams with diverse backgrounds and skill sets tend to perform better. They come at problems from different perspectives and stress-test ideas. When you remove that and bring in AI, which is not a creative thinker, you can create suboptimal outcomes from the lack of human interaction and productive friction.

The unicorn is genuinely rare, and rarer still is someone who wants to be one. I have talked to leaders who had an engineer who got excited about becoming a product engineer because they saw it as a promotion. But once they found out they needed to talk to customers and drive business outcomes, they said: this is not for me. Similarly, designers do beautiful things. If you ask them for a business case, they might pause. The idea of one person doing it all is not where we are going to end up.

What is changing is the expectation that people get better at the core of their job, understand how they create value, and use AI to do that more powerfully.

The real value a Builder PM brings is this: learning faster, understanding what to build, and generating much higher-definition evidence for why a decision is the right one.

What Stays the Same vs. What Changes

Rina Alexin | 00:15:48 – 00:17:24

What does not change:

• Deciding what to build and why
• Voice of customer and discovery
• Prioritization, which actually gets harder in this world
• Driving to outcomes: why something is valuable for your user and for the business

What is changing:

• How we interact with data and with the various agents we can build to assist our work
• How we interact with our decision-making tools
• The failure mode. A lot of the changes here have to do with the solution space

Proof of concept is replacing the PRD. A proof of concept can have a lot more value and can speed up the product development cycle. However, it does mean you are spending more of your time in solution space, and strategy and problem space thinking can suffer. Those are going to become more important failure modes to watch for.

The AI-Augmented Workflow

Rina Alexin | 00:17:24 – 00:20:28

I wanted to put together a high-level flowchart of what a Product Development 4.0 cycle looks like with AI. Here is how the stages break down:

Stage 1: Signals. Market data, user data, support team feedback, sales team feedback, these still come in the same way. Where AI augments this is in having agents analyze patterns and user behavior much faster and generate insights at scale. Signals remain important and relatively unchanged.

Stage 2: Validate the problem. Do not skip this step. This is the validation step: confirming a problem is real before making any moves on developing a solution. Voice of customer research and discovery remain essential here. Tiny acts of discovery, as Dean says, still matter. You still need to be in front of your customers proving that whatever insight you are getting is real, painful, and worth solving.

Stage 3: Proof of concept. This is where things change. You can now work with coding agents to develop what a solution could look, feel, and behave like at a much earlier stage of the development cycle. The cost of building being lower makes this possible. The risk is going deep into solution space without truly understanding the problem. When you put a working prototype in front of people, assumptions are already baked into how they interact with it. That is a real limitation to keep in mind.

Stage 4: Development cycle. Organizations using coding agents typically have multiple gates and multiple agent types accelerating the cycle: a coding agent, a review agent, and a human engineer doing the final pull request, reviewing for quality and security. When you hear “90% of our new code is AI generated,” this is what that means.

Security, Hallucinations, and Engineering Gates

Rina Alexin & Cynthia Petti | 00:20:28 – 00:25:13

There are two important risks in this workflow that deserve a direct conversation.

Security. Product people without an engineering background often do not know what questions to ask about security, and that is a real gap. I know of a team that wanted to publish an MCP connector with Claude fairly quickly and accidentally and unintentionally exposed their entire codebase through the integration. Security is not a joke. Keeping a human engineer in the loop before you ship is very important. Product managers who learn more about where security risks can appear will become much better partners to their engineering teams, not to take over that role, but to ask better questions.

Hallucinations. General LLMs have about a 60% accuracy rate, which is actually much lower than most people assume. AI can hallucinate all the way from pointing out insights that are not real to inventing people at companies who do not exist. Our team members have experienced this firsthand. This is why:

• Success criteria are very important
• Evaluating outputs with clear eval frameworks is essential
• Feedback loops that improve the system over time are not optional, they are critical

The more you train your models and the more you build in those correction mechanisms, the better the output gets. We will go deeper on feedback loops shortly.

One more point: everyone in the system owns improving it. Product managers and engineers together. That is the new type of relationship. You understand this is a system, and you find ways to work together to continuously improve it. That is what the best product development teams are doing.

Managing Mental Load and Discovery Time

Rina Alexin & Cynthia Petti | 00:25:13 – 00:29:23

Even if the mandate is not to suddenly become three different people, you are doing more work. That is the reality. And more work means more context switching.

Product leaders and chief technology officers are reporting significant increases in shipping velocity because of higher-definition problem framing with proofs of concept and faster development cycles with coding agents. But moving faster means switching context more often, and that carries mental load. Burnout is a real risk, and if you burn out, you will go a lot slower. So protect yourself: lunch walks, meditation, whatever works for you. Just be aware of it.

On discovery time, please protect it. A few critical points:

• Do not skip the validation step. Validate that a problem is worth solving before committing to a solution
• This mode can feel very execution-heavy. Your job is to be the person who understands the value of discovery and the value of saying no
• There is more pressure to say yes to everything. If you do not have the discovery evidence to push back, you will end up in a negative loop, not knowing why things are failing
• Feature bloat is a real cost, even when the cost of building appears low. Your stakeholders will not understand it until it is too late

Protecting decision-making around why you are building something is your core mandate. It protects the future of your product.

You will rarely hear me recommend adding meetings to your calendar. But if you are seeing fewer interactions with your designer and engineering counterparts because you are working more with agents, I do recommend adding some sync time back in. Slack huddles, something informal, to pressure-test ideas. That friction might actually be worth adding back.

And I would add: at the start of building a new system, a little more communication helps show the why and the value. Those conversations make things smoother later and reduce the need for meetings over time.

Poll: The Build-It-Yourself Ladder

Rina Alexin & Cynthia Petti | 00:29:23 – 00:31:01

Here is our second poll: how far up the build-it-yourself ladder are you?

• You have not started yet
• You have played with a no-code AI builder
• You are using real development tooling
• You are shipping AI-assisted code to production

Take a quick few seconds and answer.

All right, a lot have not started. That is perfectly fine. And I see one person is already shipping AI-assisted code to production. Amazing. For those who have started, you are ahead. For those who have not, I have words for you in the next section.

Practical Starting Points

Rina Alexin | 00:31:01 – 00:33:38

For everyone who answered that they have not started yet: the best advice I can give you is the Nike slogan. Just do it.

AI has a steep learning curve, but it helps you climb it. The best way is to start. When I first used Claude Code, my mind was genuinely blown. It saved our company money on various items I could handle using Claude Code and MCP connectors. You can just ask it to teach you, show its thinking, and explain why it did something.

The tiers of getting started:

Tier 1: No-code AI builders (Lovable and similar tools). When Lovable first came out, a lot of people just tried something to solve a problem for themselves. My husband built an app in about two hours: you take a photo of your food and it tells you the nutritional content. The point was not that he needed it. It was that he wanted to learn what these tools are capable of. That is your first job. Start simple. One hour on your calendar within the next two weeks. That is your homework. Connect with me on LinkedIn and tell me how it went. You will surprise yourself.

Tier 2: Coding agents (Claude Code, Cursor, and similar tools). These are more like an IDE. Lovable sets everything up in its own environment with front end and back end included. One of our team members built a scheduling and logistics tool for an event in Austin using Lovable. It took him a few hours and it worked much better than their previous solution. These tools can surprise you.

Mastering Advanced AI Skills

Rina Alexin | 00:33:38 – 00:37:47

As you go further into how AI can help you be a better product manager, there are additional skills to develop:

Vibe prototyping. Building to learn, not just building. Creating an early proof of concept is really about building something to test an assumption. It is its own skill. And when we are talking about that early stage, creating a proof of concept means creating early prototypes, which is a deliberate practice.

GitHub and version control basics. If you have never used GitHub, you do need to understand it before going further. Use AI to learn the vocabulary: branches, repositories, pull requests. Have AI teach you. Product leaders are standing up GitHub repositories for their companies and marketing departments are now joining in. It is becoming less an engineering tool and more a tool for everyone.

Agentic workflows. There are various ways agents can assist in the product management and development process. If you are going to really embrace AI, you will want to learn how to design them, think through them, and test their output with clear evaluation criteria.

Feedback loops. Similar to evaluations, but a step further: actually building correction mechanisms into your process, your system, and your agent. We will talk more about this in a moment.

On tools: I try to be tool-agnostic because it depends on what kind of product you work on. If you work with physical products, you might want to explore AI simulations. If you just want to start building, Lovable is probably the easiest entry point. If you only have one tool to choose, I would personally lean toward Claude. But your context and your company’s approved tools matter too.

Security awareness. Product people will become better partners to their engineers the more they learn about where risks can appear. Not to take over that role, but to ask better questions and catch things earlier.

Productside Test and Learn Program

Rina Alexin & Cynthia Petti | 00:37:47 – 00:39:21

If you are looking at that list and thinking it is overwhelming, you are not alone. And that is actually why we built this.

At Productside, we have a Test and Learn Program. It is essentially our alpha and beta user group. Here is how it works:

• You get to try out various content and skill sets before they are fully released
• That is how we test our material and get better as a company
• You get access to AI skills for free

Robin has already posted the sign-up form in chat. If you are interested in getting access to AI skills and being part of shaping what we build next, that is your link.

And for those who said they do not know where to start, our Optimal Product Management course actually incorporates AI across the entire product management process. It teaches you the foundational skills and already shows how AI can make you a better product manager right inside the class. Dean, who has been chiming in throughout today, is actually the co-author of our AI Product Management course. Follow him and his blog if you have not already.

Collaboration with Engineering

Rina Alexin | 00:39:21 – 00:40:52

A couple more things I want to address before we move to systems thinking.

Engineers remain critical. I do not want anyone to start thinking engineers are going to take over product, or that product managers will take over engineering. There is still a meaningful division of labor here, and it works better when we work better together.

If you see in your organization a growing emphasis on the product engineer archetype, where engineering is being asked to take on more product work, I encourage you to stay closer and closer to the customer. The valuable piece is knowing what should get built, and the only way to do that well is to remain close to your customers. Keep validating problems even if engineers are increasingly selecting what to actually build in your organization.

Product managers and engineers are now in a new type of relationship: you understand this is a system, and you find ways to work together to continuously improve it. That is what the best product development teams are actually doing.

Defining Systems Thinking

Rina Alexin | 00:40:52 – 00:43:22

I want to try to demystify systems thinking, because I think one of the issues with thought leadership is that people say words that sound good but leave you wondering what they actually mean.

Systems thinking is about thinking across multiple steps at the same time. That is the simplest way I can put it.

The reason people are talking about systems thinkers now is that when working across various roles, the complexity of product development requires you to hold the whole picture in your head. And when there is AI and automation in a system, if you are only thinking about one single use case, you will miss how to create real leverage.

Here is what thinking in systems looks like in practice:

• Understand the different steps of the system and where AI belongs in each
• Identify where AI produces leverage and where it introduces hallucination risk
• Understand which phases of the product management process are dangerous to automate and which benefit most from it
• Build strong practices and feedback loops so the system produces great outcomes over time

As a product leader, think about this not just for yourself but for your team. At Productside, we think about our product management blueprint and ask: where does AI belong across each of these phases and activities? Where does it create leverage? Where does it create risk? That is the systems thinking question.

Implementing Feedback Loops

Rina Alexin & Cynthia Petti | 00:43:22 – 00:47:33

Feedback loops are the reason systems get smarter. AI can also learn. It gets better the more it learns. And smart product people are inserting ways for the AI to get better right within the system.

Here is a real example. We talked with a fintech team that wanted to enable their users to work with an AI to generate reports. Reporting features in finance SaaS tools tend to be fairly limited: filters, options, but constrained by whatever is built into the UI. What they wanted was to let users ask an AI CFO-style questions about their financial data and receive custom reporting back. A much better use case for what AI as a technology can actually do.

The issue is that general LLMs, untrained, do not always have high accuracy. This team realized their AI output was not always right. So here is what they did, and it was really smart: they added a single question at the end of every AI-generated output. Was this correct? Their users were now correcting and training the AI right inside the product. Not in a separate quiz. Not a separate feedback bubble. Right there in the flow, where people are most likely to respond.

That is the feedback loop in action. And the key design principle is this: make the feedback mechanism natural and embedded in the workflow. Because if you just do your role and validate that a problem is worth solving, you can do more things. But if you get the system to be smarter, that is what product leaders are starting to see as being genuinely valuable.

If we are talking about unicorns, be this kind of unicorn. Not the person who holds three skill sets in their head, but the person who designs the system to learn, improve, and create better outcomes over time. That is the one to invest in.

Judgment Is Still the Job

Rina Alexin | 00:47:33 – 00:51:09

This is what I built this entire webinar to land on, and I wanted to end with it explicitly.

Discovery. Do four. Having a deep understanding of your customer, your market, and your business. The “should we build it?” decision. This is still what you get hired to do.

The more we go faster. The more we go into solution mode. The more this can suffer. And this is what creates a negative cycle. If you do not have a good understanding of what you are doing to drive business outcomes, or why your customer cares about it, you lose the ability to say no, even to executive leadership asking you to build things. You lose the evidence to push back.

Do not skip the validation steps. If you do, you might end up moving faster in the wrong direction. And that is exactly what we want to prevent.

As you start using Lovable, Claude Code, or whatever tool you choose, remember that your core job is still this. This is what you were hired for. You still own these things. And I find that liberating. Because this is what has not changed.

So here is how you actually 10x with AI:

• Build those skills across all levels of the ladder
• Understand your role clearly: what is valuable, how do you create value for your business
• Remain extremely strategic. Even fast-moving startups want product managers focused on what to do next and why, and building the case for it
• Create leverage. Understand that you are working in a system, understand the different steps, and use AI to make the system smarter

For product leaders: think about the blueprint of how product management works and ask where AI belongs across each phase and activity. Where does it produce leverage? Where is it dangerous? Where does hallucination create real risk for your organization? And then build strong practices and feedback loops so the system produces great outcomes.

That is how you 10x with AI. And judgment is still the job. I wanted to end with that because it is so important.

Q&A: Managing Engineering Velocity

Cynthia Petti & Rina Alexin | 00:51:09 – 00:54:38

Question:
How do you see the PM practice changing to manage increased engineering velocity across all functions?

Rina Alexin:
There are more expectations of product managers, and the expectation now is to really know how to leverage AI in your role. There are ways to build agents for some of the hard skills, analytical skills, some of the design skills. That is what a lot of companies are testing. But the soft skills are going to be what stays critically important to take advantage of what AI can bring to your job.

A couple of specific things:

First, on the left side of the process, understanding your market and your users still matters and still takes time. Companies are starting to grapple with the fact that it takes time to validate that problems are worth solving. AI can help you move faster in discovery, but it still does take time. Making sure that if product development is speeding up, you have internally set up systems to help you do discovery faster is essential.

What slows people down most is not having a good way to source customer interviews or collect feedback from their user base. The companies moving fastest have communities they have built, communities that help them do discovery and market research at scale. That is not an AI problem. That is something you need to be mindful of as things speed up: where are the real roadblocks, and are they solvable with AI or not? Some of them are not.

Q&A: Advice for Chief Product Officers

Cynthia Petti & Rina Alexin | 00:54:38 – 00:55:58

Question:
What should be the main focus for a Chief Product Officer right now?

Rina Alexin:
If I were a Chief Product Officer, I would be grappling with three things:

Where does AI fit, and how do I want my team using it? That means deciding which tools are approved, what basic practices you want to install, and what guardrails make sense for your organization.

Maintaining a high bar. I had a one-on-one today where AI output was presented to me that was clearly false. You need to figure out how to maintain a high bar so that does not happen, and when it does happen, you correct it. Chief product officers need to actively manage the risk of people using AI outputs without checking them. The human element is not going away.

Understanding the risks at both ends. Where is AI creating leverage for your team, and where is it introducing risk through unchecked outputs or hallucinations? Both questions matter equally.

Upcoming Courses and Final Wrap-Up

Cynthia Petti & Rina Alexin | 00:55:58 – 00:59:30

Thank you all so much for joining us. Before we close, a few things to share:

• The recording will be shared with all of you. Take some time to review your personal notes and think about what you are going to focus on for your own learning
• The State of AI report is available for download. We compared large companies, small companies, technology firms, and manufacturing firms. The varying degrees of adoption are interesting and not as extreme as you might expect
• In-person training in Chicago in August: Dean Peters is leading Optimal Product Management live and in person. And yes, Dean, you are everywhere. Our Optimal Product Management course now includes AI across the product management process. If you do not know where to start, this is actually a great place because it teaches foundational skills and incorporates how AI can help you be a better product manager right inside the class
• Our next webinar will be The Portfolio Scorecard: How Enterprise PMs Prioritize What Matters, with David Nash and Roger Snyder presenting from their wealth of experience managing enterprise products and portfolios
• We run a mix of live online and in-person programs on Eastern and Western time zones. If you are in Austin, the next in-person session is in December, and Rina and I usually drop in to say hello

Please connect with both Rina and Cynthia on LinkedIn. If you enjoyed the webinar, or even if you did not, we would love to hear from you. Thank you so much for spending your time with us. Bye, everyone.