The Product Manager

Vibe Coding 101: A Zero-to-One Hands-On Workshop (with Drew Falkman, Principal at Moves The Needle Studio)

• Hannah Clark - The Product Manager

Share episode

If you’ve heard the buzz about Vibe Coding but aren’t quite sure what’s real and what’s hype, this episode is your shortcut to clarity. Recorded live at our hands-on Vibe Coding Workshop, this 30-minute seminar with Drew Falkman (Principal at Moves The Needle) unpacks what Vibe Coding actually is, where it fits in the product lifecycle, and how non-technical folks are already using it to ship tools and prototypes—without writing a line of code.

Joined by co-host Katie Sanders, Hannah leads a myth-busting session that tackles common misconceptions (spoiler: engineers aren’t going anywhere), showcases real-world use cases from Reddit and their own team, and offers tactical advice for PMs who want to explore this fast-evolving space responsibly.

Resources from this episode:

Hannah Clark:

All right, guys. Episode disclaimer—if you're already an expert Vibe coder, this episode might not be for you. But if you've heard of Vibe Coding and you wanna know the facts versus the myths, and you're curious about how you can use the technology to advance your own objectives, you are gonna love this. If you haven't been following our newsletters, as in the ones you can subscribe to at theproductmanager.com/subscribe, I haven't been able to shut up about the awesome hands-on Vibe Coding Workshop we held a few weeks back, Moves The Needle Principal, Drew Falkman. This episode of the Product Manager Podcast is actually a recording of the 30-minute seminar we did before jumping into our live prototyping session. You'll hear a breakdown of what vibe coding is and isn't, inspiring use cases for the tech, and tool recommendations to start playing and discovering use cases of your own. Let's jump in. Oh, by the way, we hold conversations like this every week. So if this sounds interesting to you, why not subscribe? Okay, now let's jump in. I'm Hannah Clark. If you don't know me, I'm the Executive Editor for The Product Manager and the host of The Product Manager podcast. And I've got my co-host, Katie.

Katie Sanders:

Hi everybody, I'm Katie Sanders. I'm Executive Editor at The CTO Club. Maybe also from The QA Lead. There's some people that we merged those sites. So I'm excited. This is my first workshop and really excited to be doing this with Hannah,'cause there's a lot of blend between product and CTOs. So yeah, I'm excited to get to know everybody. Welcome!

Hannah Clark:

I'm very excited to be working with Katie on this. If you don't follow her on LinkedIn yet, Katie Sanders, she's such a badass. She's got great content, so I really am excited for you guys to get to know each other. I'd love to introduce our featured speaker as well. We've got Drew Falkman here. Drew is a product leader, an advisor, an educator focused on pre-seed to seed product strategy. He's streamlined early teams. He's optimized for product to market fit. He's done it all. He's a great friend of the publication. He's worked with us tons. And he's worked with me a lot, which tells you that he's a very patient man. So you guys are in good hands today. And he also experiences he's got a lot of experience in web, mobile, blockchain, and AI products. So we have an amazing expert here. Drew, do you want to say hello to the nice people?

Drew Falkman:

Hey everyone, super excited to be here. This is gonna be fun.

Hannah Clark:

So we're gonna start by some myth busting and I'll kick us off with the first question and then my lovely co-host, Katie, we'll go through some myths and have Drew debunk them for us. So we'll start by setting some context. Seems like everybody is talking about vibe coding and it comes up in every LinkedIn post right now, including a lot of my own. And people either seem to be very excited by it or very scared or very confused. So let's talk about why Vibe coding is so popular. Why is it so important right now? Let's get into the myth around that.

Katie Sanders:

All right, so first myth, vibe, coding is replacing engineers. Obviously there's a lot of, in general, AI is replacing everyone's job. That's what it's saying. I would say that that's a myth and that maybe it's changing the engineer's job and it is creating app ready code, but it's certainly not completely replacing the job of an engineer. As always, with ai, we wanna keep a human in the loop, and so I would say nothing's gonna get shipped without human eyeballs, and so I think we can bust that myth.

Hannah Clark:

Drew, did you have anything to add to that?

Drew Falkman:

Yeah, I would say it's something to be aware of and be cognitive of as an engineer that's coming down the pike. Just could speed up your process. And as a designer and product manager and non-technical founder, you guys now have the ability to create MVPs and create and validate prototypes and do things, and then hand it off to the engineers. When you wanna get into production level code, generally speaking, pass an MVP. In this day and age, certainly you need to be doing code reviews and going over and making sure that everything is tightened up, especially. If there's any sort of compliance issues or anything you need to be aware of.

Hannah Clark:

We'll move on to myth number two. So some people say the vibe coding is a world outside of the dev cycle. So in other words, if you build something in a vibe coding app, that you still like that it's not really usable and that you have to rebuild it completely from the ground up with a developer who's hard coding whole thing. Drew, is this really the case?

Drew Falkman:

The tools have evolved so much and it's one of those things where it's literally changing every day. Claude just released a new sort of iteration of their code generation within the last month or so, and it's miles better than it was before. So it's continually improving. It does just like all generative AI stuff. It can hallucinate, it can do goofy stuff. It can do things that are unexpected. So as part of the cycle it can work into the cycle and you can actually create these sort of code pieces. Hand them off to engineers, but you really need to be conscious that they're going to probably need some reworking. You might need to reuse some components, and I think some engineers might be somewhat surprised at how good the code actually is.

Hannah Clark:

Okay. Another myth that I've heard a lot is that you don't need a PRD or a product strategy in order to vibe code a tool. Drew, Katie, thoughts on that?

Drew Falkman:

Look, you always need to think. I think what happens is sometimes people think if I'm vibe coding, I can just jump in, open it up and have an app tomorrow. And just like anything else, if you don't put any forethought into it, it's not going to be what you want. You wanna think about who your audience is, who your target market is. You want to think about what your value proposition is. You want to think about what the core features and flows in the app are going to be. And so it's really worth your time to. Put together something. Now, the beauty of it is you don't have to create a five to 10 page PRD that defines the tech that's gonna be used, and that diagrams all the flows and all that. You don't have to think about that. You just wanna outline what your vision is, what it is you're building, and in fact, I've come up with a little vibe, PRD, and that's like one to two pages, and it's just for you and anyone else who you might be collaborating with so that you're on the same page and that you can come at it with an organized approach. And that your code is cleaner in the long run.

Hannah Clark:

Good to know. We'll move on to the next myth here about highly regulated industries. Now, Katie represents the CTO Club, so did you wanna take the myth on Katie?

Katie Sanders:

Yeah, I think one other one I wanted to touch on is. That this is new and tell you like we've been vibe coding for years. We didn't call it that until recently, but, copy pasting from GitHub or Reddit or Hacker News, wherever, like great engineers, they solve problems. They search and pattern match and adapt and build. So I think this prompt is just the next evolution of what's always been there. And then, Hannah, what was the other one you wanted to bust?

Hannah Clark:

Just that if you're in a highly regulated industry that you can't vibe code. Oh it's not secure.

Katie Sanders:

Yeah. Like obviously when we think about like healthcare or finance, those are highly regulated industries. So it's just with any other industry you wanna make sure that you're HIPAA compliant and all of those things. I know that LLMs can sometimes pull. Yeah. So just consider compliance issues. Really in the industry. But I think that there's a little bit of an extra guardrail when you're thinking about healthcare or finance or something like that.

Hannah Clark:

Yeah, I think it's kinda like a lot of different development processes where you still, the vibe coding tools don't replace your personnel. They're just like a compliment to accelerate the development cycle. But yeah, like a good rigorous code review process, it's probably more essential than ever now that we're outsourcing some of that work. All right. Let's talk a little bit about some use cases. It'll be fun to explore a few different ways that people are using vibe coding effectively right now. Katie will run this section of the show here and go through some of the use cases that were pretty cool.

Katie Sanders:

I actually, a lot of these I pulled from Reddit when Vibe Coding first started happening. Like I wanted to see real world examples of this. Everybody was talking about it, but I wasn't really able to see anything that was successful. So I did an article about this and one of the things we talked about was this person who built, I think it was like a soccer, it was like a niche soccer game organizer, just like his, a personal in interest hobby. He was not a developer, but he understood how full Stack apps worked, and he's always had to hire developers to bring his ideas to life. But as he started playing around with lovable and cursor and all these other things. He built this niche soccer game app and it was just help his to organize his weekly games and he ended up shipping this and I think successfully. Yeah, shipped a hundred line AI generated app profitably. Within weeks, I think was bringing in something like, was it Michael? Was it like $700 a week or something like that. Another example we found was this one called Work aid, which would, it's a gamified task management powered by ai. So like revolutionizing your to-do list with apps to make work feel like a game. So those were like a couple of successful examples that I pulled from Reddit and we can link you guys to that Reddit post. There were a few more examples of that and I think, a lot of people are just gonna play around with this, but there are some people who are gonna be really successful with this, which is really cool to see.

Hannah Clark:

Yeah that's a very cool example. I didn't wanna just interject quickly 'cause we have a very good question from Katya. Katya says, I was wondering, as a PM would I even have to still create wire frames and mockups for the front end? I could just create it with vibe coding and then the devs can use my front end as a starting point for their own development.

Drew Falkman:

Yes, 100%. In fact, I would say that it would be more difficult with Vibe coding with most of these tools to try and implement an existing design. It's hard to import screens and do all that. It's actually easier to define it and you can work with the generative AI to get the look and feel right and all that kind of stuff, and then hand it off to them and they can make sure it's in compliance with any design system or anything else that you're using.

Hannah Clark:

Thank you for for fielding that Drew. Sorry Katie, to, to interject there. Did you wanna get back to some of the use cases? I know you got a couple more up your sleeve.

Katie Sanders:

Michael, do you wanna share that we have one like use case from someone within our company, they created this layoff impact analyzer. Michael, I dunno if you wanted to share that as a great example.

Michael Mordak:

Definitely. So this is a, an awesome example that one of our colleagues used on their site where they are working for an HR publication and wanted to build a tool that folks could use to analyze the impact of a layoff if they were planning on. And the way he's done this is he's actually coded it so that, or bot coded it so that folks who wanna use this have to fill out a survey ahead of time. That way he's collecting data on people that are using it, which is something that he wanted to do for his own purposes. So once he completed that survey, then the app brings you into this calculator. And so there are a few examples that he's got built into it. So if you're, at a manufacturing company and you're looking to lay off 200 employees, then you can select this example just to see how it works. But essentially you put in all these different details and talk about okay, how much knowledge do these people have? How much time would it take to retrain somebody for this role? And then you can calculate the impact of that layoff and it'll tell you exactly what kind of effect this will have. So this would be a great tool for folks who are working in HR who are planning a layoff and he's just given it to, for free, for folks who wanna play it around with it and give them feedback. But that's one example that we have just from someone on our team. The second example I could share, which is the polling tool that we were just using, I just coded it on myself. I have no experience coding or very limited anyway. And so I built out this pool so that, or this pool's app basically, so that we could. Take voting from the live audience and display the results instead of having to pay for something that did it. Because it's, a lot of times what happens is apps will have that as a feature, but you gotta pay into it and they, you're paying for all the other features that you're not really using. I only really care about the pool, and so I built this all so that I could create my own pools. I can give it whatever name I want, add as many options as they want. I can preview it before it goes live, and then I can either launch them from here or turn them off, get rid of them, et cetera. And then this is how they're displayed on screen. So you folks are voting on the app that I created. I'm not collecting any data from you. Don't worry. It just lives in here. And yeah, so that's where we saw those results there. And that was something that I just threw together. I was actually working on it 30 minutes before this call, but in total it probably took me, one to one to two hours just to put this together and give it some branding that I thought looked nice. But I'm also not a designer, so don't take tips from me.

Katie Sanders:

Yeah, I mean we, we've talked about the upsides here. Of course, there's some people who are playing around in this and thinking that they are just never gonna need anybody technical ever again. But there's this one example of this guy, Leo Junior. His post went viral on X, but he's the founder of Enrich Lead, which is a tool that collects IP addresses and uses an LLM to generate sales leads. So he built the entire app using Cursor and he said very proudly, like zero handwritten code AI is, the builder. You can whine about it or you can start building just like a lot of bravado and no humbleness. And so of course the internet chose violence and within 48 hours, the hackers took over and his subscriptions were bypassed and his cost skyrocketed. And the LLM started hallucinating lead data out of thin air. So Leo had to post like an SOS to Twitter and say, Hey, I'm under attack. Random things are happening. I'm not technical, so this is taking me longer than usual to figure out. And so now he's learning how to code the hard way. So of course, again, just the lesson that you always need a human in the loop and it's fun to play around with as a non-technical person, but you always need a technical person reviewing the code.

Hannah Clark:

Actually, Michael, did you wanna give people like a quick rundown of what that learning curve was like for you when you very first started playing around with the tools?

Michael Mordak:

Sure. I, like I said, I have very limited know, like coding knowledge, and so this is something that I feel like, I see this sometimes where people will say something like, oh, I'm an ideas person. I've never actually built that something before and that's a hundred percent the camp that I fall into because I'm often thinking about, different ways that. I could try to cut down on internal process or do things without having to like, pay for third party apps, but actually building it out is difficult. So in response to Grand there, he was asking what the learning curve is like in practice and the tool that we're gonna be using today lovable. And it's gonna be similar across the other apps that are out there as well. It's honestly the learning curve is really gradual. It was really low because there's, there like you see it's just text prompting. So you out outline exactly what it is that you'd like to see, like the things that your goal for building the app would, what the kind of outcomes you wanna see. And then it'll spit out some examples of what it might build for you. But you can also provide additional details as well. So if you've got something that you're basing it off of, like for example, for this one, I said I want to, I wanted to look something like slido.com, which if you're familiar with Slido, is a polling app. And so it can use examples from the real world to base those off of, and then you can input your own branding. Any other requirements that you need the app to do when you're putting it in? Once it's built out, the initial iteration, it's also that's not the end of it. You can keep chatting with it. There's a chat mode so you can ask it questions before it actually changes the code or builds anything. In addition to that, what I found worked for me too is when things got a little bit beyond my knowledge, I actually went to, I took some of the things that. Lovable would tell me that I was doing, and I'd take that, I'd copy the chat GBT and I'd say, explain this to me like, I'm five. And so it would dumb it down for somebody like me who doesn't understand all the technicalities and explained it really thoroughly. So yeah, it was really smooth process and I made it really easy to try building something like this.

Hannah Clark:

That is so cool. And I hope that's very encouraging for those of us, including myself, who are starting like really from scratch. I did want to bring up a question here from Tal. We're gonna pitch this one to Drew. So Tal asks, what would you suggest is a good workflow for existing product companies? I'm a PM working at a startup. We have a design system and a working product with users. Why do you think I can use Vibe coding for specific features or ideas? And when would it go back to design or will it skip the design and go straight to Dev?

Drew Falkman:

So I think this whole workflow is 100% work in progress right now. There are no best practices yet. It's still the wild west in terms of putting all this stuff together. But the way I would do it if I were at a company is I would skip design, but I would coordinate with the designer. So I would do and I'll show you my vibe, PRD, I would put something together that sort of talks about the screens and elements. Now, make sure to get buy-in from the designers. They can even be collaborators on this too. So remember, this isn't something we need to do in silo. We can all be looking at the same project and working on it together. And then what I would do is I would create it. There's no like magical way that I've heard of, at least with lovable to integrate design systems. Some of the other tools like Cursor is actually a lower level tool for this because you can plug in the chats and everything, but you're really working in the code. In like an integrated development environment, and it often requires like running command line thing. So it's a little more technical for totally non-technical people, but it does allow you for a little more code integration and interaction. So that might be a better tool for this use case. But if I were doing it here, it will actually do a two-way sync to GitHub, which I'll try and show if we have time today. So you could do an iteration of a screen, you could post it to GitHub. And then your devs could pull it down. They could apply all of their components and design systems and push it back up. And then when you went back in all that stuff, you should be able to see it and it should hopefully, ideally work great.

Hannah Clark:

Wicked. This question is from Donald for Drew. What's your experience around vibe coding for something that is more cloney in brackets via another task manager versus something that is more unique, like a sonification of Google Trends data? So in other words, vibe coding for something that is more like a version of something that already exists in multitude versus something that's a completely unheard of, never really been done before idea.

Drew Falkman:

That's a great question. So my experience in general with prototyping tools and vibe coding tools is that anything that exists is fairly straightforward. It can add them, it understands. Like our sort of default example today is a travel app. It can do travel apps all day long, but when you get into something like Sonification of Google Trends data, it's going to be more of a battle. And I would add, if you get into anything that's outside of, that's going to require like very custom sort of visualization tools other than your standard sort of UI elements with dropdowns and buttons and things like that. You're gonna struggle with these kind of tools, at least with lovable and where we are today. There may be other tools that will make this easier, but right now those are things you're gonna need to pull dabs in and work with if you're doing something crazy and really out of the norm.

Hannah Clark:

All right. That brings us to time. I wanna give a huge thank you to Katie for being part of this, and of course to Drew for being such an amazing resource for volunteering your time and expertise. Thanks for listening in. For more great insights, how-to guides and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The Product Manager wherever you get your podcasts.