Vibe Coding to Learn

Welcome & Introductions

Dean Peters & Kenny Kranseler | 00:00:00 – 00:03:40

Hey everybody, welcome to today’s exciting webinar on Vibe Coding to Learn. We’ll get started in a couple of minutes, so give everybody a chance to find us. In the meantime, if you can open up your chat and put where you’re dialing in from, that’s always a good way to get started.

Tell us what the temperature is too. Only because, Kenny, right now it’s about 100 Fahrenheit here in Raleigh, North Carolina. You need to come to Seattle. I know.

Roger Snyder. Do we know him? I’ve heard of him. The legend.

Welcome everybody. Those of you who just dialed in, put where you’re from and Dean wants to know how hot it is. Celsius or Fahrenheit, we don’t care. All right, people are pouring in. A lot of people are interested in figuring out how to do vibe coding for product managers.

They want to get that chat box open so they can ask questions. Definitely snarky remarks. Dean needs lots of snarky remarks. I live off them. I give out bonus points for funny remarks, even at my expense. All right, I think we’ve got a quorum. Let’s go.

Kenny Kranseler | 00:02:00 – 00:03:40

So first we’ll introduce ourselves. My name is Kenny Kranseler. I’m going to be assisting Dean in our presentation today. I am a principal consultant and trainer at Productside and have been in product management training and doing product management for the last 30 years or so. I am dialing in from just outside Seattle, specifically Bellevue, Washington.

Dean Peters | 00:02:45 – 00:03:40

And even though I’m on the other side of the country in sizzling Raleigh, North Carolina, we both bring decades of experience in product management. I’ve got 20 years of product management experience prior to coming to Productside, and 15 years of software engineering experience before that. I worked with a lot of data, connectors, APIs, and early AI. So when it came to vibe coding, this is very exciting for me. Kenny circled that.

About Productside & Housekeeping

Kenny Kranseler | 00:03:40 – 00:07:44

Before we dive in, some shameless plugs. At Productside, we know how hard it is to deliver products that don’t only get used but that users actually love to use. We have resources whether you’re figuring out how to align stakeholders, understand customer needs, or manage endless backlogs. We’ve seen a lot of it. We’re here to be your outcome-driven product partner. We are not just providing generic solutions, but making sure they fit your organization specifically.

We enable complete transformations:

• From sales-led or customer-led to product-led
• Tailored to fit your unique scenarios
• Guided by people who’ve been doing product management for a long time and have the scars to prove it

A couple of housekeeping items:

• You will get a recording. If you attended or signed up, you will get the link and can share it with others
• Use the Q&A feature inside Zoom during the session. Don’t wait until the end, ask as questions come up
• The chat is also open. Connect with us and with other attendees, share your own experiences, or just cheer Dean on
• Connect with us on LinkedIn. There is a QR code on screen and a link in chat

Our LinkedIn community is more than a place to follow Productside. It’s where we share leadership best practices, conversations about the role of product management, and tips for being more impactful, and where you can network with others going through the same challenges.

What Is Vibe Coding for Product Managers?

Everyone’s Vibing, But Nobody’s Learning

Dean Peters & Kenny Kranseler | 00:07:44 – 00:12:21

Here’s our agenda for today. We’re going to:

• Talk about why everybody’s vibing but nobody’s learning
• Walk through shaping the story to shape the solution
• Cover low-code versus coding agent approaches. If you don’t know what those terms mean, we will explain them
• Show you a lot of different tools and techniques live
• Close with special offers and Q&A

Kenny, everyone’s vibing but almost nobody’s learning. I think people are playing. And I feel the exhaustion of that when I go on LinkedIn. The guys at 37signals’ podcast said: “Oh my goodness, another model came out. Can we not have all the breathless screaming about coding agents?” Everyone’s using it, everyone’s doing it.

In fact, there are really two failure modes we keep seeing, and I’d say they’re both back-to-the-future scenarios.

The full build fiasco. I worked with a company in Redmond, Washington that went zero to end. They speced the whole thing out for a new version of their platform. They had great ideas. We launched late, didn’t quite land on budget, and the result was a release that shall live in infamy. People call it Vista.

The death march. A reference to Edward Yourdon’s book. I kept hearing from stakeholders: “If we don’t put all the features in, nobody will buy it. You can’t miss the drop-dead date.” Everyone’s working long hours, burning out, and we get it out the door exhausted. The customers saw it and said, “I mean, it was good, but not worth all the weeping and gnashing of teeth.”

I just feel like we’re getting back to both of these scenarios with vibe coding. Either someone’s trying to vibe code an entire Airbnb or Salesforce experience in a month, or it’s a classic death march with better branding. As product managers, we have to avoid these traps.

And this is reflected in our recent State of AI for Product Managers report:

• 80% of product managers are using AI regularly in their work
• Only 23% have a clear strategy in their organization
• Only 34% have a documented policy
• Very few are measuring impact at all

People are starting to play with AI but they really don’t have an idea of where it’s going or how to get there. And that gets us to our first poll.

Poll 1: Where Are You on the Vibe Coding Curve?

Dean Peters & Kenny Kranseler | 00:12:21 – 00:13:49

Here’s your first poll. You can choose just one. Where are you on the vibe coding curve?

• I haven’t tried it yet
• I’m dabbling on some side projects
• I’m using it for daily work
• I’ve already built agents and scaffolds
• I’m the one asking for the prototypes (I’m that leader)

All right, let’s share the results. About 41% haven’t tried it yet. Think about that. Another 28% are dabbling. Some people using it for daily work. No one’s building agents yet, at least not in this crowd. And interestingly, nobody clicked “I’m the person asking for them,” which is going to be interesting as we talk about how the demand usually arrives.

The Arc: From Low-Resolution Demand to High-Resolution Decision

Dean Peters | 00:13:49 – 00:14:46

Over the next 45 minutes or so, we’re going to be going through five motions to take a problem from a low-resolution demand to a high-resolution decision: is this the right thing to build? Is this the right direction to move?

Here’s the arc we’ll follow across the five motions:

• Demand: the email lands, the ask arrives
• Context: understand the problem, gather data
• Assumptions: make your bets explicit
• Win condition: define what success looks like
• Narrative: visualize the human story
• Prototype: build only enough to learn
• Decision: pursue, pivot, punt, or pause

This is not a maturity ladder. It’s a clarity ladder. You’re trading off clarity with each motion you take. And good context beats a clever prompt every time.

Then the HiPPO Charges In

Dean Peters & Kenny Kranseler | 00:14:46 – 00:17:01

Everything starts with our favorite dangerous animal in product management, the HiPPO. The Highest Paid Person’s Opinion. Notice that they’re not evil. They are just certain.

And our use case for today: “Build me a dashboard that shows everything AI and its ROI.” Here’s where they got their inspiration: they took our State of AI report and weaponized it. The email arrives:

“Hey, I just read the Productside AI PM report. Tool spend is way up but measurable lift is not to be found. The board has asked me the ultimate inconvenient question: what business value are we getting from our AI investment? I need an executive AI productivity dashboard by Friday.”

So the HiPPO’s problem becomes our problem. And if you’re just vibing off the cuff from that email alone, your result is going to look like a Rube Goldberg disaster. How do we avoid that? Five motions.

Key things to notice about this demand:

• It arrives as a solution request, not a problem statement
• It has urgency baked in (“by Friday”)
• It has a hidden question underneath: “Are we getting value from AI?”
• It has stakeholder pressure behind it (“the board asked”)
• And it has zero context about what “good” looks like

This is what most vibe coding starts from. And this is exactly what we’re going to transform, step by step.

The 5-Motion Framework: From Demand to Decision

Dean Peters | 00:17:01 – 00:17:51

Here are the five motions, with different technologies introduced at each stage:

• Motion 1: Set the Context: cast the ask, fill the gaps, and persist your findings using chatbots, notebooks, and projects
• Motion 2: Shape the Hypothesis: frame a testable bet, set a win condition, and build a solution hypothesis using skills and project context
• Motion 3: Scaffold the Narrative: create a minimum viable narrative instead of a full spec, using your chatbot and portable story structure
• Motion 4: Touch and Feel: visualize with design tools and low-code to get a clickable prototype from your narrative
• Motion 5: Shake Out the Solution: use a full coding agent with persistent files to build, validate, and collect real user feedback

Motion 1: Set the Context Before You Touch Any Tool

Dean Peters & Kenny Kranseler | 00:17:51 – 00:26:15

Good context beats a clever prompt every time. How do we narrow down the ask? In our Optimal Product Management training, Kenny and I both teach an exercise around people walking in the door with solution speak, and one of our jobs is to get behind that to the “why” and understand the true job to be done. The good news is AI can be very helpful here.

Setting the context has three equally important sub-steps:

Step 1: Cast the Ask. Categorize, label, and classify the incoming request without turning it into a data science project:

• Start in your chatbot (not your coding tool) to create artifacts and context first
• Bring in the email or Slack message screenshot and run an incoming request breakdown prompt
• The AI will classify what it is, identify the underlying problem, surface the sentiment and subtext, and list must-haves, nice-to-haves, and hard negatives
• Take that output and put it in a file. Start building your pantry.

You could do this in any browser. I’m using Copilot here because it’s being very responsive today. Apparently it knows I’m in a demo.

Step 2: Fill in the Gaps. Do research to augment your understanding and persist it:

• Use the deep research tool in Copilot, Gemini, or ChatGPT to get a structured document on the topic
• Run the same prompt across multiple tools, as they give different points of view and different citations
• Do competitive research on your competitors, and do the same for yourself using external artifacts, so you get an apples-to-apples comparison of how the world sees you
• Persist everything: save it to a project, a file, a notebook, or a shared directory

Tools for gathering and persisting context:

• NotebookLM
• Gemini Gems
• Claude Projects
• ChatGPT Projects
• Microsoft Copilot Researcher

Kenny, any thoughts on filling in the gaps? I think what you want to do is understand that space better, capture what’s understood, and put it somewhere you can use later. That context can include your own product, competitors, how certain things work. It doesn’t just have to be deep research on things you don’t know.

Step 3: Persist the Ask. This is the theme that ties the whole process together:

• Saving as organized files is what separates vibe prototyping from just prompting in a chatbot
• Use projects, repos, or shared directories, whatever fits your toolchain
• The coding is no good unless you have persistence across all five motions

And one powerful way to make casting repeatable is to use agent skills. Anthropic introduced a standard for skills back in November. Essentially, you take things you prompt about frequently and turn them into repeatable processes at the tip of a finger. Instead of cutting and pasting that same long breakdown prompt each time, you just invoke the skill. One word, and it runs the same context-setting process. That’s the whole point of persistence.

Build your pantry. Get things in the kitchen. Get the data persisted. I know we haven’t gone into actual vibing yet, but trust me, this is going to save you a lot of time and agony.

Motion 2: Shape Your Hypothesis with a Testable Bet

Dean Peters & Kenny Kranseler | 00:26:15 – 00:34:45

Now that we have context, we can start shaping a hypothesis, creating what I call a testable bet rather than a hunch. The difference between guessing at a solution and framing a bet is important:

• A bet has limits; it is a known quantity
• A bet has a known win condition
• It becomes very obvious quickly when you’re moving in the wrong direction

Using ChatGPT inside a project (which already has the State of AI report, the research, and the executive briefs as context), I ask: based on our incoming request, what are some ripe solution opportunities? Notice it didn’t say “dashboard.” Instead it came back with ideas like:

• AI Value Mapping Gap Radiator (a leadership decision radiator)
• Outcome-to-AI Ratio View (an intervention recommendation moment)
• Faltering Team Drill Down
• AI Activity Theater Alert

Love that last one. So we’ve got choices. I narrow it down: what are your top three? Then: get a suggestion for a solution that combines those three into a single solution that meets the underlying needs.

Kenny, can you do this in Claude Code? Yes, you can. You can use the file system exactly like this. In Cowork? Yes. In Codex? Yes. Right now I’m just showing you different tools you can start with.

Once we have our solution direction, we capture it in a solution hypothesis template:

• If/then framing: what we believe the solution will do
• Persona: who the user is and what their goal is
• Obstruction: what’s getting in their way
• Win conditions: how we’ll know we’re successful
• Known unknowns: what we’re still not sure about

Now I have something I can share both with people and with the machine. It knows what the solution is, who the persona is, what the goal is, and how we measure success.

Kenny, how do we know what our riskiest assumptions are? You could do a step before this: run a problem framing canvas and stack-rank the top opportunities. You could use the Osterwalder value proposition canvas or the customer circle, and then exploit based on the top pains, gains, and jobs to be done.

And because we’re inside a project with all those source files, when I make those asks the AI is answering in context, not starting from zero. That’s the point of context engineering.

Motion 3: Build a Minimum Viable Narrative, Not a Spec

Dean Peters | 00:34:45 – 00:41:38

Once we’ve got all that scaffolding and context, the most important thing we’re going to do in vibe coding, instead of writing a full spec, is to see and visualize the story.

I’ve seen a lot of people talking about test-driven development and eval-driven development. Not yet. For the prototype, I want a minimum viable narrative. A great narrative of the human experience of what someone is trying to accomplish with our solution is going to get great results across a variety of tools.

Here’s the structure of a minimum viable narrative:

• Setup: who the person is and their situation
• Trigger: what sets the story in motion
• Reframe: the intervention or shift in perspective
• Signal: the indicator that something needs attention
• Choice: the decision moment presented to the user
• Learning: what we take away from the interaction

I’m running this in Copilot right now, feeding it the story context and asking it to create a minimum viable narrative. This narrative is very portable. You can:

• Use it to create an explainer video
• Use it as a splash screen to set the limits when showing stakeholders
• Feed it directly to any prototyping tool as the primary input

Think of it this way: AI tools like Lovable, Stitch, and Claude Code are the beast, and they don’t have a whole lot of context. They can’t infer who the user is or what the situation is. So we’re going to feed that beast in the form of a narrative, not a specification.

Your solution hypothesis and your minimum viable narrative are the two files you must have before you start prototyping. Everything else is noise until those exist.

Motion 4: Visualize with Design Tools and Low-Code

Dean Peters & Kenny Kranseler | 00:41:38 – 00:45:57

Now we can actually visualize what our prototype is going to look like. I went to a design tool instead of going straight into something like Lovable, and here’s why: by looking at it visually first, I can find gaps. Think about how we used to do this: sketching on paper, wireframing with pencil. All a design tool is really doing is being an AI-assisted digital scratch pad, a whiteboard that helps us look around the corner and into the future.

Design tools for this motion:

• Stitch
• Figma (with a ChatGPT connector)
• Vizly
• Reloom
• Claude Design

All I gave Stitch was the minimum viable narrative and a design guide for the look and feel I wanted, and it took a while, with quite a few prompts. Some of the initial design wasn’t right. But I nudged it to a point where it’s something worth seeing.

One important thing I noticed while working with design tools: instead of looking at features, I was able to look at gaps. I said, “Wouldn’t it be great to combine RACI with something that shows the work behind a decision?” Now the design has a board that shows exactly that, something that came directly from seeing the mockups, not from the original email.

Once you have the design, you can move to a low-code tool:

• Lovable
• Bolt
• Base44
• Gemini Canvas (in canvas mode with reasoning enabled)

Low-code tools have rules of the road:

• A narrative and a win condition, plus perhaps a design export, gives you dramatically better results than just prompting from an email
• The killer prompt: “Generate a fully functional, highly interactive, premium-grade HTML5 single-page application. Fully functional yet throwaway. Self-contained HTML5.” That self-contained constraint means all the JavaScript is included in one file you can pass around for look-and-feel testing, and deploy very cheaply
• It creates a reusable prototype that deals with your riskiest assumptions and has guard rails built in

All that production came from giving it the narrative and the design. Not a spec. Not an email.

Kenny, what prevents the design tool’s screen-by-screen output from just becoming the solution? When I was working with the design tools, instead of looking at features, I was looking for gaps visually. It’s an AI-assisted digital scratch pad, helping us shape what to build, not lock us into what was first rendered.

Motion 5: Shake Out the Solution with a Coding Agent

Dean Peters & Kenny Kranseler | 00:45:57 – 00:51:31

And finally, we want to shake out the solution. One of the reasons to use a full-blown coding tool (Claude Code, Codex, Cursor, VS Code with extensions) is that we can introduce validation on things like:

• Feasibility
• Branching logic
• Logging and evidence collection
• Simulation engines to test with synthetic data

In other words, we can build something we can actually deploy in a much more mature sense than a clickable HTML5 app.

Rather than opening Claude Code and saying “here’s the email, build me a dashboard,” you get around the early foot-shooting by creating three files first and dropping them into your repo:

• README: the context, what this project is and why
• Contract: what to build and how to build it
• Constitution: the guardrails and constraints

Kenny, take one guess how I generated these three files. Use your chat assistants. Exactly. I used my chatbot and it just created them for me. Now, when I drop these files into my repo and type `init` in Claude Code, it picks them up, understands what the project is, and builds from that context, not from scratch.

I built one of these last night and iterated on it. I took what Lovable gave me and improved it. I added better navigation, a drill-down on individual boxes, a simulation engine on the back end, and synthesized what data from Jira would look like so I can actually run scenarios.

Here’s what it enables in the prototype:

• Click on a failing team to see all the touch points
• Understand how a team is using AI, creating lots of artifacts, but not getting outcomes
• Simulate interventions and see the impact on the plan
• Ask users directly: should we pursue, pivot, punt, or pause, and collect their live feedback

So what stops us from just shipping this?

• Security and authentication
• Infrastructure
• Compliance and guardrails

Remember: throwaway code. We vibe to learn, not to earn. This is a whole different conversation from how you vibe as part of an engineering team in production. The goal right now is to get ourselves to a pivot, punt, or pursue decision, to decide where to spend real money, before we spend it.

And we did it through five motions. Kim, it’s time for the second poll.

Poll 2: What Did You Take Away?

Dean Peters & Kenny Kranseler | 00:51:31 – 00:53:15

Here’s your second poll. What did you take away from today? Let’s see where people landed.

While you’re filling that out, somebody asked for a link to some of the libraries Dean referenced. He’s dropping those in chat now. We’re going to have some Productside repos up soon too, so those are going to be awesome.

All right, most people have jumped in. Let’s share the results.

Good mix. People picked up different parts depending on where they started from. That’s exactly what we wanted. The takeaways here: be product-aware, name the riskiest assumption, scaffold the context. Nothing yet, but now you know what to watch for.

Resources & Upcoming Courses

Kenny Kranseler | 00:53:15 – 00:55:13

While people get ready for Q&A, a few things to know about:

• The State of AI for Product Management report: the link is in the chat, or scan the QR code on screen. Fill out your information and you’ll get the full report. We also had a webinar on this a few weeks ago – 5 Steps to AI Product Success
• In-person training in Chicago in August. Dean will be running more vibe coding there. When you come to live training, it’s all this stuff, and what happens during lunch and after hours is where the real vibing happens
• Upcoming webinar on the Builder PM: what that PM doing vibe coding looks like, how to prevent it from becoming your whole job, and how to keep your core product judgment intact
• OPM Live online courses: Kenny in early August, Dean in September
• AI Product Management courses, live online in July and September

FAQs: Vibe Coding for Product Managers

Kenny Kranseler & Dean Peters | 00:55:13 – 01:00:34

All right, it’s time for questions and answers. If you haven’t put a question in, please do. Drop it into the chat or the Q&A. We’ll stop sharing slides so you can see our smiling faces.

Question:
What’s the best way to gather user feedback during a vibe coding session?

Dean Peters:
You’ll notice in that very last exercise, I actually built the feedback mechanism right in. When users reached the final screen, they could deliver feedback live. That’s one of the key advantages of using a full coding agent like Claude Code or Codex over a low-code tool:

• You can bake a feedback mechanism directly into the prototype
• You can collect analytics, not just clicks, but actual user responses
• You can add analytic tracking throughout the entire flow

That’s the advantage of a full-blown coding agent for prototypes that need to capture real signal.

Question:
How do you explain to management who might want to port a finished vibe coding project directly to shipping?

Dean Peters:
A lot of this has to do with framing ahead of time. When you take that minimum viable narrative, you can go into the create feature in Copilot and generate an inexpensive explainer video before you ever show the prototype. Remember, the narrative is portable. Or add a splash screen to the prototype itself: “Welcome to our prototype. Let me set the limits here.” Either way, framing the conversation before the demo is what prevents it from being mistaken for something ready to ship.

Question:
How do you manage tokens across the five motions?

Dean Peters:
Did you notice I was using my chatbot quite a bit before I ever got to the coding? Did you notice me setting up the files first? That’s what saves you tokens. I could have done the whole thing in Claude Code or Codex, but I would have burned three times as many tokens. By using:

• Deep research in the chatbot rather than the coding agent
• Repeatable skills
• Projects and pre-built artifacts
• Only then dropping files into the coding agent’s directory

…I limited the token burn in the most expensive part of the process. Design tools also burn tokens, but not as much as asking a coding agent to figure out design from scratch. Use the most efficient agent for the task at hand.

Question:
Let’s be honest: how often do we actually have time to walk through this whole five-motion process with real deadlines?

Dean Peters:
I got through it in an hour today. End to end, including all the design tools, maybe two hours max. If you can’t afford two hours on this, you’ve got different problems you’re working with.

Kenny Kranseler | 01:00:10 – 01:00:34

I think we’ve hit the top of the hour. Thank you everybody for your participation and your questions. There are some tools and links in your chat on how to follow us. If you do have follow-up questions, go to productside.com to find out when we have webinars, when we have training, participate, and become part of the community we are building. Have a wonderful day and a great rest of the week.

If you’re ready to put vibe coding for product managers into practice, this workshop gives you a repeatable process to start tomorrow.