Dan Olsen - Vibe Coding: The New Product Team Superpower? (with Dan Olsen, Product Management Trainer and Author “The Lean Product Playbook“)

you know, in my book and in my talks, you know, the second to last step of the lean product process, top of the product market fit pyramid, is UX design. I'm a big fan of, hey, before we do any, invest any engineering resources and code something, let's create a prototype that we can test with customers and let's iterate on that until we get to the point where, you know, customers love this thing, there's no complaints, then we can very confidently go to engineering and say build this, because we validated it, right? No one's one-shotting anything good, right? The first time you do vibe coding, you're like, build an Airbnb clone, and it spins and it does it, and you're like, check it out, and you're like, yeah, you know, but that, what you just built is not gonna compete with Airbnb, right? Hello, and welcome to One Night in Product, a show where I chat to some of the brightest minds in product from across the globe to help you see product management in a whole new light. If that sounds up your street, don't forget to dive into the back catalog on your favorite podcast app or on YouTube, and of course, follow, share, or drop me a comment or review. It all helps keep the lights on. Tonight, I'm delighted to welcome back my good friend and most extroverted person I know, Dan Olson, product management trainer, consultant, author, and speaker, author of 2015's The Lean Product Playbook, organizer of the Lean Product Meetup, and guaranteed to be the one talking Spanish to the restaurant owner at the end of the night, even if it's not a Spanish restaurant. These days, he's running workshops on vibe coding and trying to help PMs make sense of all this AI stuff, but is it an opportunity or a threat? Dan, thanks for coming, and welcome back. Thanks, Jason, always awesome to talk with you. Well, you know, let's not tell anyone, or they'll all be trying to do it, but, you know, yeah, it's good to see you again. It's been a while since you've been on the podcast. Obviously, we've seen each other a couple of times since, and I do have to say that you are definitely very much, that you're always the one that's talking to everyone. Like, there's this kind of cliche about friendly Americans, and then there's you. So, like, I just want to kind of tip my virtual hat to the kind of flying the flag for all of us. You mentioned I'm half Spanish, too, so, you know, Spanish people can be extroverted as well, so I hope we get to have some yummy Spanish food again sometime soon. Well, one day, one day. You never know your luck. So, as, you know, we've kind of mentioned, it's been a bit since you've been on the podcast, but, you know, also, we've not really spoken for a little bit now, so be kind of curious before you kind of jump into it. What's kind of keeping you busy these days? What are you working on? Like, what's taking up your time? Yeah, you know, so I have a mix of, I've been on my own for over 20 years now, you know, and what keeps me busy mainly is, like, training workshops. So, private training workshop for companies. It used to be 100% product management training workshops, where I would just teach my book, and then, starting last summer, I started teaching vibe coding workshops, which are a lot of fun. So, I do private workshops for companies. I try to do public workshops when I can. Occasionally, I have a public workshop coming up this weekend, where, like, if I go to speak at a conference, and they have a workshop, I do it there. So, really, training is the main thing. I also do some consulting and advising on the side for a few companies. As you mentioned, I run a lean product meetup. This month is actually, February will be 15 years of running it every single month. So, we've got quite a big community there. I also run product leader summit once a year conference. So, you know, like a mixed bag of a lot of stuff. Try to blog and write when I can, and I love talking with people like you, you know, when I can as well. So, yeah. I think we, these days, are supposed to call it a portfolio career, right? Like, we've got all these different, fingers in all these different pies. We're the worst product people in the world, because we can't concentrate on anything. We've got to do all of the things, because there's so much opportunity out there. We're like founders. We're like, you know, really passionate founders that can't, you know, focus on anything. I'm a solopreneur. I consider myself a solopreneur, right? I've had my own business for a while now, and yeah, and it's actually good. The diversity is good, you know, because sometimes, so one thing's like, every October is just slammed with conferences and events and things like that, right? So, it's nice to have other stuff different times a year. Absolutely. Well, you just mentioned writing as part of what you're doing. Obviously, you've got the book, which I've put there for you, just in shot, just in case, you know, anyone wants to go and pick it up afterwards, but also on your website as well. And one of the things, you know, kind of to sort of segue us into this vibe coding topic that we're gonna talk about tonight, you have an article on the website that I sort of picked up on recently, which kind of tickled me a little bit, this idea that, you know, there's so many people these days, so much hype around sort of AI in general, and also just whether this is the final sort of death of product management, and whether, you know, we need product managers or product management anymore, if it can always just be done by other people or agents or whatever else. And obviously, you've written a pretty decent length article on it. Yeah. I'd be very curious to kind of, you know, kick it off and just try and get your opinion on, like, is product management dead, you know, or at least on its way out, or has it still got a lot, you know, a bit of life left in the old dog yet? Yeah. Not dead yet. I'm hiding Python parrot skit. All right. Yeah, you know, and it's funny, because I wrote that article a year ago. So, a lot has happened in a year, right? So, I wrote that article because, you know, 18 months ago, 16 months ago, you were starting to hear people saying, oh, I don't know, with AI here, I think PM is dead, you know? And I just, I didn't feel like that was accurate. I mean, it's easy for anybody to make any claim. So, I kind of wrote that article. The funniest thing is, I think the pendulum has completely swung now, right? Or swung a fair bit, right? When AI was new, nobody really knew which jobs is it gonna automate, which jobs is it gonna replace. And so, people were rightfully concerned like, oh, is it gonna replace my PM job or not? And I kind of thought about this in detail. I think you gotta think about the skills and the jobs and what is AI good at. For example, writing marketing copy, it's pretty darn good. Like, most people go in there trying to have it write marketing. Obviously, you can tell sometimes it's AI, it's getting better. But the point is, it can write decent copy. So, if you're like, you know, so, if you were a copywriter or, you know, kind of a marketing person whose job was to create copy on a frequent basis, if you, unless you were really, really good at your job, there's a threat that it could replace you, right? So, same thing with engineering, like front-end coding, for example, right? If you're just writing JavaScript, HTML, CSS, you know, and, you know, there's a bell, for all these skills, there's a bell curve, basically, right? And I think that what I see with it is the AI is starting at the bottom of the bell curve and it's moving its way up, right? So, certainly, vibe coding tools today can produce front-end code that's at the quality level of, say, a 20th percentile junior developer. So, you know what I mean? So, that's how I think about it, like each, there's a bell curve for each skill, well, it's, or there's copywriting, or front-end dev, or product management. And obviously, product management is a collection of a lot of different skills and tasks and activities that we do. But the funny thing is, you know, people are actually going the other way. What they're finding, historically, is if you think of, like, product development as a factory line, it's like, it starts out with the business folks or the product folks coming up with the requirements and the objectives, and then, ideally, the design, you know, obviously, we don't want it to be waterfall and serial, they're collaborating. But then the designers sort out what's the user experience gonna be, and then we pass on the developers to develop it and go out. Typically, the bottleneck, any factory line has a bottleneck, or any system has a throughput constraint, was always been engineering. And it was always, like, the mantra was, make sure your backlog's full, make sure you're keeping engineering busy, you know, that's the worst thing you can do is not have some engineering to do, you know. And if you haven't had time to do discovery, just give them some bug fixes, or tech debt, or something, right? That was the old mantra. Well, what you're starting to see is as engineers are using the vibe coding tools as productivity boosters, right? It's, you know, like, you know, the above average developers, back-end developers, they're using it, their productivity's increasing. And so, you know, that was kind of my sense that PM might be more valuable, and so I was really happy when Andrew Ng, who's one of the pioneers of machine learning, he was speaking several months ago at a Y Combinator event, and he said, hey, you know, one trend I'm seeing with my AI startups is the traditional ratios of PM to engineers are kind of changing, right? And just a quick aside on that, these are not the end-all, be-all, but I've found in my experience working with, you know, hundreds of companies that you can predict a lot based on the PM to engineer ratio, right? If you have like 12 or more engineers on average for each PM, there's no way those PMs can keep up. They're JIRA jockeys, they're living in JIRA, they're doing the scrum ceremonies, they have no time to do discovery, or strategy, or anything like that, right? And so when you get down, typically, I like, you know, six to eight is kind of a healthy range. If there's more UI stuff involved, maybe it's more like five or six. If there's less UI stuff involved, maybe seven, eight, whatever, you know. Anyway, Andrew was just saying, hey, now, you know, basically his startups were saying that now with AI helping his engineers become more productive, the bottleneck was moving upstream to product management, and therefore they wanted to have a lower ratio of engineers to PMs, and he was saying like four to one, things like that. And then he closed out by saying, and just yesterday, I had a founder come and say, I want two PMs for every engineer, right? So that flipped the ratio. No, and he kind of caveated that by saying, well, I don't know if that's really right, but he just shared that data. But the point is, I think that the kind of throughput optimization, the bottleneck is changing as engineers get more efficient. And I think that if you think about the tasks and activities that product managers do, yes, some are rote tasks that might be able to be automated, but, and I think we'll get into this as we talk about by coding, the thinking work, the why behind it, the discovery, the data, the evidence, the forming of conclusions in light of, you know, nothing's ever black and white. They're always making decisions under uncertainty, right? And I think that those core skills are more valued now than ever as kind of creating solutions becomes easier than deciding what should we build and why should we build this versus that becomes more important. So I think you're actually seeing for great, for strong PMs, they're even more in demand. And with vibe coding, they're able to do more and be in a sense, more self-sufficient or more capable, which we'll talk about. So, you know, that being said, if you're a PM, if you're in a not a, if you're like, say a weak PM and you're like avoiding AI like the plague and you're like, you know, like you're just not leaning in, then you might lose your job, right? So my biggest advice is, you know, this is not a fad that's gonna come and go. This is a fundamental change. Kind of like, it's like we were talking about, you were saying, you know, should there even be a title AI product managers? Like that reminds me back in the day, it was like, there's a mobile product manager. I'm a mobile product manager. Now we don't do that anymore. It's like, yeah, of course your app needs to live in mobile and the web, right? So anyway, I think that's kind of how I see things playing out. I think the biggest factor, and I think that they're getting conflated is just we do have tough economic conditions out there, right? There's always a pressure for productivity and earnings and profitability. And so you've got that pressure. And I think you frankly have some leaders who don't really know any better and they're like, okay, well, I gotta cut costs. AI is gonna let me cut costs. And you see all these stories of companies that let people go and then they're hiring them back. So anyway, it's hard to sort out, right? Nobody has a perfect crystal ball of how it's gonna play out. But that's kind of what I'm seeing is like good, great PMs that are leaning in to AI and vibe coding and using these tools are thriving, you know? And people that are kind of avoiding it and like just saying this too shall pass are the ones that are gonna end up on the sidelines, I think. The other last interesting dynamic is at my meetup, I've had, when I did my vibe coding hackathon and we have topics talking about AI, I've had multiple product leaders at the director or senior director level, even VP level say, Dan, you know what? I miss getting my hands dirty. I miss being an IC. I wanna leave my director level job at this large company and I wanna go be what we're calling this product creator, product builder role. They're like, I wanna do that at a smaller company. I've heard that from multiple leaders, you know? And it's fun, because when you do vibe coding, this part of your brain fires off. Like you're like, oh my gosh, I'm actually creating something. You're a maker, you know what I mean? It just feels really good, you know? And a lot of people really want that. Yeah, it's funny. I mean, obviously there's a lot to unpack there and probably won't be able to unpack all of it. But like, I think one of the things that interests me about this kind of, because there was this kind of concept that kind of came up in the, whatever, the social media sphere around, I don't know, like super ICs and like, you know, something along the lines of, you know, people that were very senior leaders wanting to now just go back on the tools, like you say. And it kind of feels like, look, first of all, absolutely, I was a developer for years. I know you were as well. Like, it's fun building stuff. I'm building stuff now. It's really cool. I enjoy doing it. I wish that I had some of the tools then that I have now. But it also feels that it kind of, to some extent, this narrative of like super ICs and like everyone's a builder now kind of does diminish a little bit the concept of, for example, strategy, good leadership, team building, all of these things that the more senior people were having to do to try and make sure their companies are steering in the right direction, that they're making the right decisions, that they're de-risking things and not just building everything at the same time. So do you feel this kind of super IC, everyone's a builder, product engineer type narrative, which is starting to sort of appear in certain parts of the bubble, it's sort of detraction of basic good leadership, or do you think it can kind of live alongside it? I think it can live alongside it. And what I would say, I like this. So yeah, super IC was probably the first incarnation of the term. And now people are using term product creator, product builder, or product, yeah. But just to be clear, like, it's funny, because I do think there's an element in what you're saying of truth, which is, oh my gosh, this is fun. This is fun. Yeah, exactly, like, fine. Great, like, fun's fun, right? But come on. My time doing this, because this is more fun than whatever else it is, right? So but just because it's fun doesn't mean it's creating value for the business or the company per se. So I do think there's that little bit of temptation that could be there. And to the extent that people are spending their time more on this as a fun activity, then yes, perhaps they're not spending on the other one. But I don't view it as an either or. And I view it as, again, I would just say, when it's so easy and quick to get to a solution or a robust prototype, it just elevates the importance of what should we be prototyping? What problems should we be solving? What is the real market opportunity? And also, what's the differentiation? If I can just build some, you know, a decent tool with a set of prompts, then so can anybody else. So what's my real differentiation, right? So I do think, and I would just say, you mentioned strategy specifically. You know, I routinely, when I give talks on product strategy, I ask the audience, who feels like your company has a solid strategy, product strategy? And it's always less than 10% of people raising their hands, right? Now, if the heads of product are in the room, the number goes up, because they don't, yeah, we have a strategy, I've made it, the strategy's good. But most people don't have a strategy. So I would say it's, and that's because it's not that it's not necessarily that it's not fun. It's just hard and it's difficult. And there isn't like an approved process. And it takes longer to pay off as well, right? Yeah, no, totally, and that's the other thing, is everybody has short-term fever. It's like, whoa, what are we launching this month? What are we launching this week? What are we launching this quarter? Right, and again, quarterly earnings and capital being a public company, you have that earnings pressure. So like the whole, it takes a really strong leadership and savvy leadership to say, no, we're actually gonna take the time to plan more than one or two quarters ahead, you know, and think about that. It's a luxury kind of for, unfortunately, for a lot of companies to do that. So I don't, I think they can coexist, this idea. I do think that there is this super IC idea. It actually predated, for what it's worth, it predated vibe coding. I used to call those people, like what I would call, when I saw a PM who had some tech chops, you know, like you do, because they did some, either they invested in learning development or they did some coding. So like, ah, I'm kind of technical, you know. Again, it was never the best use of their time to actually do coding, right? That's not the best use of their time. But by knowing, by being technically savvy, they can partner more effectively with their engineers. And, you know, not, one is if the scopes don't make sense, they can question it. But what I found is the most creative thing is, oftentimes, the first response from engineering, if you're technical, you can get under the hood with them, go, well, actually, we don't need this. What about this way? What about this? And next thing you know, you've got a much higher ROI solution that's less scope, right? So that's the idea. And then the other important skill set is design. And I've seen PMs that lean into design. Like for me, when I had my first PM try to get into it, you know, of course we did, you know, discovery research. I wrote the best PRD I thought I could based on the research and then we got in the product cycle and I realized, oh, wow, that we all have, we had to do all that. But if UX design is bad, none of this really matters. So I made it a point to learn a lot about it. So anyway, I call PMs that have leaned into tech, you know, tech learning and dev learning enough and UX learning enough. I used to call them triple threats. That's what I used to call them because they were, it's like a, you know, like a sports player who can also not only, you know, rebound, they can make shots, it can pass or whatever. So I used to call them triple threats. So when I think of super, I see that's what I think of. And I think with vibe coding, the bar has been lowered significantly. You don't even have to be as technical. You don't even have to know as much about UX design, but it's that same mindset of opening your mind up to thinking about those things and trying to be aware of those things. Yeah, and you know, again, it's, I guess like with everything, it's all about balance, right? But just trying to make sure that, and I'm sure we'll talk about this in a minute, that you're not just, you know, just privatizing execution of everything. And again, as like you say, because it's fun or because it's, you know, it feels like you, it's great to put things on a screen with your own hands after years and years of just doing like board reports and stuff like that. So exactly as you put it, I completely get it. I just want to make sure that people are doing the rest of their job. Because actually this is an interesting point, right? Where we're sitting there saying, I don't know, product managers, there was a lot of debate back and forth. Should they be technical? Obviously now maybe they don't need to be as technical. They don't need to go and learn, you know, like C sharp or whatever to start building stuff. They can start prompting away. But at the same time, like, why is it the engineering side that they have to go and vibe, right? But they could just legitimately be going and vibing sales type stuff or, you know, commercial marketing, go-to-market stuff or strategy stuff themselves. It shouldn't, like, it feels just like, maybe it's just the frustration that many PMs feel that they're not seen as builders, that they are kind of seen as kind of process people that kind of move stuff around and carry water. Like maybe engineering is just the fun part that's easier for them to get into. I don't know, it's just. I don't think that's the motivation. I don't think it's an identity crisis of I wanna be, you know, viewed as a bad-ass builder. I don't think that's what it is. I think what it is, and actually the way I couch it is when I give talks on this, is, you know, in my book and in my talks, the very last step, you know, the second to last step of lean product process top of the product market fit pyramid is UX design. And so you wanna, I'm a big fan of, hey, before we do any, invest any engineering resources and code something, let's create a prototype that we can test with customers. And let's iterate on that until we get to the point where, you know, customers love this thing. There's no complaints. Then we can very confidently go to engineering and say, build this because we validated it, right? That doesn't happen for a lot of reasons, right? So the thing is, and I have a slide. So I basically have a slide where I talk about what are the design artifacts a product team can create along the way and they categorize them by fidelity and interactivity. The lowest one is a hand sketch, right? Hand sketch is great, whether it's on a whiteboard or a digital whiteboard or paper for the team to kind of get aligned. Then the next one up is wireframes, right? Like Balsamiq, I'm a big fan of Balsamiq. I think Balsamiq's great because a lot of people rush to the colors and the pixels and the fonts before you've even thought about the layout and the information architecture. So by doing a wireframe, it forces you to answer those more fundamental questions. And you can actually test with a wireframe. You can test, are we missing some key feature? Does the layout make sense? Does the flow make sense, right? And then the next thing, which is the most valuable and useful is like a clickable or tappable mockups basically, right? So like in the old days, we'd do Envision or something. And now of course, Figma makes it super easy. So a clickable Figma, it's high fidelity, it's clickable. And people hire me to apply my process. We use clickable Figmas to do it. And then finally after that is the live product, which is the highest fidelity and activity. And the very next slide I show is, everybody, most people get that and they wanna do that, but they're not doing it. And when you ask why, a lot of them have what I've called the design gap. And this is one of my oldest slides that I created from working with my very first product teams. I realized, gosh, like, you know, there's no, they wanna do this, but there's no one to create the prototypes, right? And again, when I'm in my audience and I ask people, I show this design gap, it has a maturity model where like the lowest maturity model is all you have is engineers, you know? And then the next level up is you have engineers plus PMs, but no designers. And then the next level up is, well, maybe the engineer's a little UX savvy or the PM's a little UX savvy and they can kind of close the gap a little bit, but they can't fully close it. And the next level up is, hey, between the two of them, they close the gap. And the final level is, of course, the trio, the triad we always talk about, hey, it's PM, design, and engineering all working together where the designer can step in and drive that prototyping, right? So again, when I ask people who here feels like they have adequate UX resources to do prototyping, it's less than 10% of people raise their hands, right? Even though design's a thing, it's appreciated. Everybody understands it. It's just, you know, your team may not get the designer. There might not be enough resources to go around. You might have open headcount. They might be out sick. Who knows why? So that's why I think vibe coding is so valuable because now, whereas you previously would be blocked. It's like, well, I guess we can't prototype. Let's just write our user stories and have engineering code it. So you skip the whole testing and validation step because you couldn't create a prototype, you know? And so now, it enables, it unblocks product teams that used to be blocked that you don't have to have a designer, you don't have to have someone technical. You can create a frickin' pretty good prototype that you can test with someone. So that's the way I, that's why I see it rising is not any frustration with engineering per se. It's not any I wanna be a builder, I think that's cool per se. It's just, hey, I can more quickly get to a visual representation of the product, of the idea that we have in mind. And as I've worked on this, you know, I've taught over 1,000 people now, I realize there's actually multiple audiences for the Vibe prototype. There's four distinct audiences. The first audience is actually yourself because inevitably, no matter how good a job you did with discovery research and no matter how good a job you did writing up your requirements which turn into your prompt, you get the first prototype and you're like, oh, there's a table. Oh, I forgot to specify how it's sorted. They kinda sorted it in this weird way. It should really be sorted by date. So then you go back and you revise your requirements and say, okay, sort it by date. By getting the prototype, it helps you actually, you know, I talk a lot about problem space, solution space. The prototype is solution space. But by seeing the prototype and reacting to it, you're gonna be like, oh, I forgot these problem space requirements and you're gonna actually iterate on your own before you show that thing to anybody, you're gonna iterate, you know, five to 10, maybe 15 times to really answer all those questions that you didn't even think about, the unknown unknowns that you didn't think about. That's the first audience. The next audience is now you can take it to your product team and you guys say, hey, here's what I'm thinking and we could build, you know, designer, what do you think? You know, I'm not trying to, you know, take your, I'm not trying to do design for you, you know, this, you know, by definition, they kind of pick kind of a plain vanilla design or whatever. And so you could talk to them and the engineer could give you feedback from them. Once they're happy with it, then that's great. The next audience is stakeholders, like senior stakeholders, right? And my insight here is like, you know, you may have written a nice PRD. There's no way those senior stakeholders are taking time to read it. So you're trying to like share your ideas and concepts with them, which usually sadly means you're creating a Google slide deck of your PRD just for their consumption, right? So you have extra busy work to create another version of your PRD that they can consume. And even then you're talking about, you're using like text bullet points to explain something. Who knows if they're really grokking what you have in mind if you have shared understanding. When you have a prototype you show to them, there's certainly a shared understanding. That's very engaging. They engage with it. They go, what about this? What about this feature? What about this, right? So people can just engage in a better discussion. Like non-product trained people can react to a prototype and have a better discussion. And then of course the fourth audience, the most important is users. Well, we can go and test this with customers to get their feedback. So I've found value in all four levels of those different audiences when you vibe prototype, you know, which again, if you go back to the old workflow, if you didn't have a designer, you couldn't do any of that. If you did have a designer, you would kind of write your user stories in PRD and then you'd wait for the designer to come up with their initial design. They'd show it to you. You'd have some discussion with your team and then you'd kind of go test it, right? So it's just, in a sense, it's a richer process. It's more iterative because each turn is so quick. Like each iteration is so fast. It's just you talking to the vibe coding tool. So that's how I've seen a lot of value for teams. All right, well, let's dig into that then. I mean, obviously you've gone through some of the use cases and I'm sure there are many people thinking about additional use cases because, you know, there are some people out there sitting there saying, oh, you kind of mentioned it earlier. We can just build any old thing and just one shot an app, right? You can make a new hub spot just by typing into some tool or something, which, you know, maybe we'll come back to that bit. But obviously you're training a lot of this stuff at the moment and I can think of a number of different ways that vibe coding, the actual process, like what it is you're actually doing could be defined. So how, I mean, you've talked about vibe coding, you've talked about vibe prototyping as well. Like if you kind of think about vibe coding as a concept, how are you defining it specifically? Yeah, well, the first thing is we should get clear on who defined it, right? That's what's so funny is someone actually got in, tried to argue with me on LinkedIn, like, well, vibe, they like put the definition of vibe from like Merriam-Webster dictionary because they were like, they were trying to, it's so funny because anytime you have a new term, people misinterpret it, they bring their own baggage to it, right? And so this person was feeling like, oh, it's not real coding. Vibe means it's loosey-goosey. And then I just kind of replied and said, well, yeah, well, cloud computing doesn't mean the servers are in the sky, you know? Like you can't, like it doesn't, but basically, you know, I didn't create the term, right? The term was created by Andrej Karpathy actually almost one year ago to the day. The other thing I love asking people is, hey, how long has vibe coding been around? And I'll do a poll, I'll be like four years, three years, two years, you know, and it's less than a year, it's coming up, the one-year anniversary is coming up. On February 2nd, he said in tweet, and he said there's a new kind of coding, I call it vibe coding. And what he said is where you fully give into the vibes, embrace exponentials, man, whatever that means, and forget that the code even exists, right? So I think it's, you know, but the point is that last part, forget the code even exists, right? So vibe coding for me means basically you're generating code without like actively coding. Like you don't have to write, like in before vibe coding, you have to type every character. Yeah, yeah, maybe there was auto-complete. every character, yeah, maybe there was autocomplete in your IDE or something that could accelerate a little bit, right, but the point is, it's the AI, so it's gen AI, and it's like there's gen AI for code, right, gen is generational AI, it's generating that stuff for you, right. So that's the idea, and you know, when I got into this, and again, I really appreciate it because I do have that, it's funny because I spent time way back, a long time ago, after my third web product, I'm like, okay, I'm just gonna learn how to code this web stack stuff, because I like to be, I like to know, right, and then I used it for a few years, and then it just sat in the back shelf in my brain, and I haven't used it really that much, and then I also learned a lot about UX design, now with vibe coding, you get to use all that stuff, which is, so when I got into it, I'm like, oh, there's so many different tools here, I wonder if anybody's kind of sorted them out, and nobody had, and as you know from my book and other stuff, I'm a frameworks guy, so I'm like, all right, I'm gonna create a framework for how to understand these vibe codes, so I have a framework called the vibe coding spectrum, and the main thing is it goes from less technical on the left to more technical on the right, and part of the problem, like same thing with MVP is when you have one umbrella term that spans so many different categories, of course people are gonna misinterpret it, they're gonna say, and it's for this category, not this one, other people are gonna go, no, it's this category, not this one, right, so anyway, it's a spectrum, and there's six categories, basically, going from less technical to more technical, and I actually, in the chart, it has a lot of things, it has like, what's the UI, so the less technical ones are browser-based, you just run it in a browser, there's no installation required, right, there's no app or anything like that, and then from there, it progresses up to an extension for Visual Studio Code, then it gets to a standalone IDE desktop app, and then it gets to command line, that's kind of the progression of the technical stuff, and then I also talk about the roles, the ones on the right end, the more technical, obviously the sweet spot target user for those is developers, right, and I would kind of reserve vibe coding if I had to, you know, split hairs, I'd be like, hey, vibe coding is the right side, and the left side, that's more targeted at PMs and designers, I would call that vibe prototyping, and in the middle between the three categories, there's a big shift, when you use any of the tools on the left half of the spectrum, the default UI is, when you're in the tool, is the actual UI of what you're vibe prototyping, that's what you, the code is there, you can switch to a code view, but it doesn't show you that, so like, literally, you could vibe code a product and never have to look at the code, that's kind of the cool thing about it. On the right side, the default view is the code, you can, of course, look at the UI, you might have to launch a local host in a browser, or maybe they have a separate browser view or something, right, and over time, these two categories are starting to merge a little bit, but that's a fundamental thing, it just tells you right there, the default view is either the UI you're creating, or the default view is the code you're creating, right, so that's the idea, and, you know, really quick, on the far left, it's not so much that they're less technical, it's just that there's a category of tools that are really optimizing for designer, things that designers would care about, like, if you do wanna replicate your look and feel, you have a design system, you wanna integrate with Figma, right, then those tools kind of live there, so Figma Make is obviously in that category, designers love Figma, and so a lot of them, Figma Make is right there, so they use that, and a very popular, another one that's not, it's a smaller startup, but they're getting a lot of traction, it's called Magic Patterns, and so I've used them at a lot of my hackathons, and so that's another example of a designer-friendly one. The next category up is, I would, you know, and anybody can use any tool, right, so I kind of show these bands of ideal user as gradients and fades, I think the next is kind of more PM-centric, is like Lovable, and Bolt, right, and Base44, and so things like that, and it's basically, you know, Lovable's got a lot of traction, I think they have a great brand name, they have a great logo, it's, you know, they've, they're just, they really, I've been, you know, using these tools since the spring, and it's incredible to see what they're doing. So they're, you know, but they're all kind of, you can go in and you can create your tool, it's pretty straightforward, and then, so that's kind of, so that's the starting point, if you're a designer, start with Magic Patterns Figma Make, if you're a PM, start with Lovable, Bolt, and then if you're like, ah, this is kind of, I wanna do more, I'm more technical than this, then it's natural for people to migrate up the spectrum over time, they move to the right. They might graduate to Repl.it and go, okay, like, for example, this model predicts things like the GitHub integration, and Lovable and Bolt, they actually have their own version history, so you don't even need to use GitHub, but if you wanna move your code around, it can be problematic, but their GitHub implementation is very limiting, whereas in Repl.it, it like gives you a kind of full control of what you can do, you can do more backend stuff, things like that. So it's natural for people to maybe start with Lovable or Bolt, and then move up to a Repl.it or V0, right? And then I think if you're a developer, you know, if you're very comfortable in Visual Studio Code, then hey, try one of the IDE extensions out, like GitHub Copilot, you know, Codex, Gemini, or, you know, Cursor's very popular, so I think that those are some good entry points. And if you're like, hey, I don't need any UI, then just go straight to Cloud Code. If you like command line and you, that's your, that's your, you know, cup of tea, then you can go there. So that's pretty, you know, pretty much it, just jump in at the lower end, and you can move up over time. As you run into a constraint, I'm trying to do X, but it won't let me, you know, you can go Google and be like, hey, does this other tool let me do it? You'll usually find that there are, you know, fewer constraints and more things that you can do as you move up to the right. So the long and short of it is that you pick whichever one of those tools, you know, suits you the best, as you kind of just described. You put some kind of, you know, natural language specification or description of what you want to come out the other end, it goes off and does it, and it's either in Lovable, and it's all wrapped up, and it's in a box, or it's, you know, just one step before that, it's a prototype, or, you know, all the way through to some full, like, zip file of, you know, React application that you can put up onto a server somewhere. But ultimately, you've got some kind of app that's come out of the back of it. You know, that's the long and short. Well, they actually, just to be clear, there's no zip file. Like, they actually deploy it. So that's what's cool, is it's all in 10. Well, in Lovable and such. Yeah, yeah, yeah. Yeah. Oh. No, I'm talking about more like on the code side, for example. That, well, that gets into a fundamental thing that as you get into this, there's like a Grand Canyon in the middle of this spectrum that's invisible. Let's call it the chasm, right? The Vive coding chasm, right? Which is, you're like, you know, I've seen, and this is where you see the haters on LinkedIn. They're like, you know, the people that, the coders that have the code base, and they're like, okay, that's great that you created that Lovable prototype on its own island in isolation, but now if you wanna get this into the code, it's gotta, like, live in our code. Like, so, you know, but every once in a while, you'll see some technical person poking fun and saying, yeah, you can't ship that Lovable stuff, and people like to show up, throw up the security flags, and let's see, whatever flags, and all this jazz, right? But again, going back to my use case, I think the fallacy is, like, well, why, there's value in just rapid prototyping. There's value in just using it for rapid prototyping, especially if you didn't have a designer who could have done it for you anyway. So I think, you know, people are missing that aspect of it. Now, as people get more advanced and they're more savvy, like, I see this in my workshop all the time, they'll do, and by the way, real quick, we should talk about, no one's one-shotting anything good, right? The first time you do vibe coding, the first time you do vibe coding, you're like, build an Airbnb clone, and it spins and it does it, and you're like, check it out, and it's like, yeah, you know. But that, what you just built is not gonna compete with Airbnb, right? So what's funny is over time, you know, people are, instead of talking about prompt engineering, they're talking about context engineering, the importance of context. So it's kind of funny because before vibe coding, PRDs were kind of becoming less and less fashionable. It was like, oh, we don't do that, shorter, shorter, shorter, da, da, da, da, da. And now people are realizing, yeah, my main takeaway is anything you leave to chance, anything you leave unspecified, the tool is gonna have to make a guess out of the N,000 possibilities. The odds that it's gonna guess a great one that a smart human would have picked are pretty low. So what, yeah, I call this like degrees of freedom. If you leave any degree of freedom in there, it's gonna like take a guess and, you know, then you'll get in there and you'll be like, oh, yeah, no, this really shouldn't be a table. This should be this, you know, and then you go in and you start to do it, right? So that's the first thing I wanna say is like you've gotta actually, you know, provide a lot of context to these things in order to get value, you know, out of them. And, you know, when I run my workshops, the PMs will, they'll do the, I'll have a little like vibe coding template that provides the context, you know, and I try to be short with bullet points, and then they get it, and then inevitably when I run my private workshops, after 10 minutes, the first PM or designer goes, oh, this is cool, but this isn't actually our brand colors. I'm like, ah, you didn't think of that before, did you? You know, then it's fine, because I want them to discover it by touching the hot stove. And so then they go, oh, yeah, so that's the perfect example. It's like, okay, well, now let's go, let's get our style guide, let's have a replicate. It's super easy for it to replicate your style guide. That's an example of how can we reduce the differential? If we were, if we did want to take this vibe prototype thing and try to get it into our production code base, you know, in coding terms, we call it a diff, like what's the difference in the code, right? How can we minimize that merge diff? So that's one example. The next example, if you keep thinking that thinking is, well, you know, we've got these components, we've got these UI components, why are we just building random stuff with a vibe coding tool, building whatever it is? Why don't we just reuse our existing components? Well, a lot of times it's because teams are not at that level of sophistication. They haven't got components, they haven't got it in a format but the teams that do, that's for example, like magic patterns that you have your component library so that you're actually starting with your actual component. So you're seeing people coming up with ways to cross that chasm, right? But even if you don't, I think there's tons of value in just rapid prototyping. Cause even if it's like, okay, yeah, worst case, they're going to have to completely figure out how to write this in the code base. You validated the product idea, it's valid, right? So that's where you get into the other thing. If you start on the left by prototyping, you're starting from scratch with a blank slate. Yes, let's be smart about, you know, using our existing styles and things like that. When you start on the right side, it's by definition, we have a code base. We know whatever we're building is going to have to get integrated. And so it's within that context that you are creating new things, right? So over time, obviously be great for things to be truly end-to-end and the people on the left are trying to grow, go down the spectrum. So like Cursor launched a new browser thing where you can actually drag and drop UI layout and change, make visual changes, which, you know, wasn't there on that side of the spectrum before. You know, Lovable is, you know, doing other things like they now they have a separation between production and test environments. So they're all trying to, everybody wants that ultimate thing of, you know, without knowing anything about the code base, I can create new stuff that's really easy to merge in. You know, that's the holy grail if we can get there. And people are trying to get there, but again, there's huge value in the ability to wrap a prototype and test stuff, even if there's, you know, it doesn't necessarily decrease the coding burning by a whole lot. I guess though, I mean, you talked about the kind of the tech haters and stuff. And obviously there's, you know, there's some that are way out there and kind of complete advocates on the other side as well. But there is the potential risk when everything feels so easy. Like you say, like you put some prompt in, it comes out and it looks amazing and you think it's all gonna work and maybe you can put the right colors in and it all looks like it's just gonna hook. You just hook it straight in, right? You can just send it straight to the development team and off you go to the races. Like it's basically done, right? And obviously the developers that need to kind of integrate this stuff, they know that that's not the case and they probably use AI to do some of it. But there's maybe this danger that things become so easy that people that don't know that there is still some, you know, we know there's complexity around it, but people that don't know that are now expecting that all of a sudden we could just bang everything straight into the product. Is that a risk? It definitely is. No, I think senior stakeholders, now let's pick on our friends in sales. This is awesome, ship it. And they have, you know, they don't really understand all that's required in that this is a separate stand. This isn't our code. This is a separate standalone throwaway code thing. It's a rapid prototype. They don't get it. Or even senior stakeholders, right? Your C-level people, your VP level people that aren't technical, that don't really understand, they don't understand the effort, right? And what's involved. So there's definitely that risk. And actually it's kind of sad. I think I was talking to someone, even some PMs that are not technical fall into that trap. They are talking, they're like, they're going to the engineering counterparts and going, hey, why can't you just do take this and launch it? Like, and you know, it's like, it's like, oh my gosh, are you serious? Like, let's go through all the reasons why we can't just, you know, even if we wanted to, like it's not integrated with our office, it's not integrated with our database. Like, you know, so, but if somebody doesn't know all that stuff, it can definitely have, you know, make mismatches and expectations of, well, we've already, it's there, just go launch it, build it and launch it. So I think that's, you know, I do think that's a risk. And it's not like everyone's suddenly magically going to understand the tech effort required. So it's going to be a conversation, right? And yeah, so, but that being said, vibe coding on the right, it does make PMs more, I'm sorry, engineers more productive. Like they can, you know, generate code. It is creating a new problem, which is a large amount of pull requests and having to review a lot of changes. So even if you're using, you know, these tools that the engineers are busy with that. So now people are creating AI tools to make that more efficient, but that is a new thing. As more and more lines of code are generated, then the diffs are bigger and the pull requests are bigger, right? Well, that's an interesting point though, because again, you know, you know coding, I know coding, we can both build stuff if we wanted to at our hands. I don't imagine we would be doing that these days because again, who's got the time, right? But also there are so many ways to use this stuff to accelerate, even if you are a good coder. But then, you know, if we look under the hood at what's been produced by, you know, you said earlier, like, oh, you don't need to know that there's any code there at all. But obviously there is some code there. When you look under the hood and you're like, well, actually that's just a bunch of spaghetti or it keeps building new stuff, reusing stuff all over the place, security holes, potential kind of attack vectors that have been introduced because it kind of just went the wrong way. Now, obviously, again, from a vibe perspective, you just sit there and go, well, it works, it looks kind of good. But from a technical perspective, people are sitting there saying, well, you can't put this stuff out there. Like there's a joke about like in two, three years, the hottest job is going to be getting proper engineers who can come and fix all of the vibe coded code. But it is a narrative out there that like, sure, do what you want for prototypes and kind of quick checks and doing some of the stuff you talked about, but never put this stuff live is what some people are saying. Do you think there's something to that? Or do you think? The funny thing is people know they know, right? They know that people on the left end of the spectrum know that's the criticisms. And so that's why like they have security reviews and checks. And so like in the very, and you know, the biggest thing is they are listening to market feedback and they're acting on it. So they're not like, they're not trying to be like, no, no, there's no security risk. You know, in the interest of expediency, it would basically like save your secret keys in some text file or something in the early days. And then as people realize these are bad patterns, now the tools don't do those bad patterns anymore. They just don't do it. Like now they've created a separate, you know, secure place where your secrets go, you know, like all this jazz and they have a security center. So, you know, is that gonna like fully get you to enterprise grade security? I don't know, but they're trying to at least address the main issues, right? The flip side I will say is there's a whole other audience. I mean, I know most of our audience are product people and product teams inside of companies, but there's a whole other audience, which is the solopreneur audience. And actually it may be a PM who's working at a company and this is their side hustle. I mean, there are people going, launching businesses on Lovable and these other tools. They're deployed, they're making money. Some people are making, you know, five figures for sure. I'm sure some people are making, a few are making six figures. It's just a matter of time before we, you know, hear about the solo coded, vibe coded business that got a billion or whatever. Yeah, right, it's just a matter of time because you really can. So it's, you know, again, it's easy for haters to poke holes at stuff, but at the end of the day, the other thing is they're getting better and better. And one of the hacks in the earlier days, you don't have to do it as much is, you know, this is also when you would get stuck. If you're trying to make a change and you're just kind of going around what I call the debug death loop or just the, you know, the vibe coding death loop, where it just doesn't get what you want. It's not making the change. You take your code to a different tool and you get a second opinion. It's like a doctor getting a second opinion. It can often get, solve the problem that the other one didn't. And it can also, you can be like, hey, analyze this for security holes, like cloud code, go analyze this for security holes, right? So, or you can be like, hey, go refactor this. Like, you know, I think part of the best practices is you self, you self, every once in a while you stop and you say, okay, we've been coding for a while. Analyze the code, what's inefficient, what's not necessary, you know? And it'll go and it'll, so part of it, that's what's funny is, in a sense, you don't need to be technical in the sense of knowing how things work, but you do kind of need a little mini architect, mini engineering manager hat to be like, well, let's just, you know, how, you know, it helps. I think it helps a little bit to kind of, I don't know, to kind of, but the tools are getting better and better, where a lot of that is just getting automated under the hood that you don't need to know about or worry about too much. Yeah, it reminds me of the thing I saw recently. There's some automation script or something called Ralph Wiggum, which basically just takes, like, you give it a task and you tell it what success looks like and it goes off and tries to do it. And if it fails, it just tries again and it just tries again. Like, you know, like the slow-witted, but kind-hearted, you know, Simpsons cartoon character. And it just keeps going and going and going and going until eventually something comes out the other end that kind of passes all your tests. But that does then speak to exactly what you say, you need to be able to define the end state, you need to define the boundaries and what you want to happen. Even if you don't know how to make it happen, you need to kind of understand how that might happen. Which is interesting because it kind of feels like the people that maybe get the most benefit out of, for example, the vibe coding stuff and they can just go and prompt and it can go off and do it. Maybe you're not going to develop that because they didn't ever work in that kind of area and they almost need more support. Like, so are there tools that you recommend people use to try and maybe even help them with architectural choices or design patterns that they could use? Because otherwise, if you just got, like you said earlier, like they'll just go and type, make me a CRM and it'll just go and pick stuff off the shelf itself and maybe that's not the right ones. Right. Well, I think that brings up a few really important points. One is, you know, again, I said that when you give it a prompt, it's basically going to like pick, it's going to make all these decisions for you that you didn't even think about. Right. And so one of those examples would be layout. And so you're like, make me an app like this and then you get a layout. And if that, so the interesting thing is- It's like all the other apps. It looks like all the other apps. Well, who knows? Yeah, it looks like all the other apps or all the other apps. Let's say there's like four or five different ways that they look. It's going to look like one of those four or five and it maybe it picks the one that's the worst out of those four or five. Right. So the interesting thing is it goes against another best practice, which is divergent thinking. Like when you do design properly, you don't explore a hundred different directions, but you say, oh, well, we could do it this way. We could do it with two columns. We could have a list. We could have a map. Like you kind of play around where you do a little divergent thinking, right? Well, most vibe coding tools, you just get one solution instance or iteration. That's what you get. So, you know, it's kind of like a random roll of the dice. You might end up in a part of the 3D topology where you're going to be like at a local maxima and there's only so much you can do. If you're not UX design enough savvy to realize that, oh, this kind of isn't the best layout or whatever, you're going to keep going down that path, optimizing, optimizing, optimizing, right? So that's why, again, like, I think it's good. Well, people realizing that people are really good. They'll do divergent thinking. They'll put the same prompt even in the same tool because these are non-deterministic tools. If you get lovable the same prompt four times, you will get different, you know, at least slight variations, maybe more, or you might put it in a different tool like Magic Patterns or Bolt or Cloud Code and see what they come up with, right? And so that's interesting. And that's actually one of the things that Magic Patterns has, again, that reinforces that it's kind of designer-centric is it will actually, kind of like Midjourney would do, it'll give you four designs. It'll give you four high-level designs and then you can kind of, oh, okay, I like this one. And then you can pick a direction to go down. So I think that's something that's really important. And I think that, again, it just highlights the importance of having some UX design savvy. You don't need to be super detailed, but just knowing like, hey, like there could be different layouts or it could be different flows here. How do we want to do that, right? So that's, you know, that's, I think, an important thing. The other thing that's really valuable is, and this is kind of an interesting concept that lives somewhere between technical and somewhere between UX design, but I think more within UX design is in my vibe coding template, I added a section that I normally would not have PMs think about this early, which is what's the object model? And I'm not talking about the database table designs, but it's kind of like at a high level, hey, we've got regions and we've got stores and we've got employees and we've got products and we've got SKUs. What is that entity relationship, high-level entity relationship diagram of the objects or the data? Because again, if you don't specify that, it's going to take a stab in the dark and it's probably not going to get it right, right? So that's why I add, that's like a pseudo-tech, pseudo-UX thing where you got to think about. So it is interesting that to get the best outcomes, you do got to stick your toe into the solution space a little bit and start to think about, you know what I mean, and have an opinion about stuff. Otherwise, you're going to get kind of random stuff. So that's another aspect that I found people, is helpful for people. But one narrative that I have seen, again, if you go on places like X and stuff these days, where a lot of people are talking about it, there's almost this kind of vibe in some quarters. And you touched on it a little bit earlier about kind of PRDs being in and out of fashion and such. And obviously you can even use AI to create the PRDs these days as well. But this idea of like, waterfall is back, baby. It's like, we need to kind of specify it all up front. You touched on the fact, you need to provide a bunch of context and you need to make sure that you don't let it make assumptions. But at the same time, there's almost this push from some quarters to say, okay, well actually, we need to kind of over specify everything again, because that's the way to get the best results. Now, from my perspective, having done a lot of work in this area myself on my own side projects, you sit there and you think, well, actually, these things can still iterate, right? Like, yeah, sure. You're not going to be able to just put like a few lines in and get a perfect result. You're not going to one shot a CRM like we talked about already. But at the same time, you can give it to do that first pass and then look at it and say, oh, okay, actually, we may want to do these things. And then you can almost, you can iterate within the tools as well, right? So it feels a little bit premature to sort of sit there and say, oh, well, you know, waterfalls back, we've got to over specify everything, but kind of the revenge of the PRD, because for me, like iterating with these things is like the biggest part of the fun, right? Like, do you see it that way? Or do you think that there is more of a bias towards the specification? I don't think it's waterfalls back. I think people are realizing that if I spend five seconds thinking about what I type in for a prompt versus spending five minutes, I'm going to get better output for five minutes, right? It's just garbage in, garbage out. It's basically that, right? And I think it's not like the more specification, the better. I think that's like a Goldilocks thing. If you provide too little context, it's going to just guess, it's going to guess a bunch of stuff and it's going to guess wrong. And the question is, are you going to detect it? Are you going to realize, oh, this layout really isn't the best or not? Are you going to keep going down that path, right? And that's the other thing is, so I actually think these things accelerate iteration. So I think that yes, you want to start with a solid opinion or hypothesis, you know, and that's why I have this vibe coming down, but like, who's our customer? It answers all the key questions. So at least starting in the, hopefully starting at the best point. Again, I think of like a 3D surface, you know, like typical, like local maxima, global maxima kind of stuff. And it's like, where are we starting? We want to start with a solid foundation and then we're going to, we're definitely going to iterate. Cause like I said, the first audience is you, you're going to realize, oh, I forgot these five, specify these five things in the PRD. So then I would call that iterating, we're iterating, we're learning that. And then we go back and revise the PRD. The other thing is, what's really important is to have the judgment to be like, okay, I've been working, we landed in a certain spot on this 3D graph and I've been working and trying to like, you know, basically the higher up you get, the better, you know, the better it is. And I've been working on this, but I just realized, oh man, like you can only change direction so much. You're better off starting over again sometimes. And it's judgment to know. And so I like to, you know, joke from aliens, the nuke from orbit and start over, like nuke from orbit, just nuke it all. Because once you realize it's super easy, these are like tissue papers, like, you know, generating a new prototype. There's no like, oh my gosh, this is the one that I've been working on. You know, it's like, now you've learned so much, you can recreate it again with what you know now and start at a better foundation, you know what I mean? So that's the trick is, you can get these things to course correct, you know, 10, 15 degrees, but if you suddenly realize, oh man, we had the whole wrong model, we forgot this one key feature, you're probably better off just adding, and actually I saw this, just to share a very specific example. I was doing a private workshop and it was a CPTO. So she had both engineering and product and design under her and so the engineers were there and so as a result, they wrote really, most of the teams wrote really good PRDs, like thoughtful, detailed, and again, getting into the solution space a bit so that they would get the right output. And this one team, they put their PRD in, their first shot PRD in, and they got a tool and it looked pretty good, but as they were clicking around, they realized, oh, they realized a couple of things that they had missed or forgot. They decided to nuke it. Mr. Forgot, they decided to nuke from orbit, they went back, they added those things to their PRD, and the second shot, they were like, this is amazing, and it was amazing. It actually did like four levels deep. What I mean by that is like there was a dashboard page, you click on a doctor, and then it went to the doctor page, and it listed their patient. You click on a patient, and it went to their sessions that they had had, and then, you know, and so it was just on my, and it did that, what I call a four, if you think of like a sitemap, it was four deep, just from a really thoughtful PRD, so. But the flip side is, you know, you can over-specify, and that's what people are realizing, too, is like it's not like a book report back from grade school, like how thick is it, how much does it weigh, it's like it's gotta be valuable information, and if there's too much context, these things have limited memory and context windows, they'll like forget. By the time it's on page 80 of your long doc, it's forgotten what's on page one, right? And so that's the other thing, there's another thing, which is more of a PM thing, a little bit of an engineering thing, is like, okay, I've got this complex application that's probably gonna span like six to eight features and have like 20 pages, should I try to do the whole thing all at once from the beginning? Or should I like focus on, first off, the global nav and like the first module? And you know, so there's this scope management of how do I break this into bite-sized pieces that you also learn by doing, right? And that's why I really think it's important to get your hands dirty, because you learn by doing, you realize, oh, I tried, and a perfect example. First time I prototype anything, I basically stuck to the front end, and I iterated, iterated, iterated, and it was great. Second time, I'm like, okay, let's go full stack this time. So I'm gonna go full stack from the get-go, and I was like, you know what, I was really excited, because I'm like, I'm gonna add Google Auth, you know how all the websites have Google Auth? I'm like, cool, I don't have to code it, I can vibe code it. Well, after 30 minutes of debugging the darn thing, I'm like, why am I wasting 30 minutes debugging Google Auth? That has nothing to do with the value proposition of the actual app that I am testing. If I had a rapid prototyping mindset, I'd be like, who cares, just fake it. You click a button, and you Auth. Like, you know, that's the MVP kind of thing, right? And so, and same thing, once you add that database and that back-end, now you have technical constraint. You used the technical debt counter, just started, and if you wanna make changes, now it's more complicated. Next thing you know, you're debugging back-end stuff, again, that doesn't really matter. So I kinda, after trying both of those, my mantra now is focus on the front-end as long as possible, put off Auth and back-end database integrations as long as possible. Fake it till you need it, right? Get some sample data in a CSV file. I love using, like, browser local storage as a hack for having a database, all that jazz. So it's all these kind of things, so that you're, it's really about speed of iteration and quickly getting to, you know, going back and forth between solution space and problem space till you really get to something that people really like. And then we can say, great, now how are we gonna implement this thing in our back-end and things like that? We could talk about this for hours, but I think there's a very important question that people maybe that have started listening to this and, you know, started thinking about this and been like, okay, that all sounds great, Dan, but, like, you've kind of touched on it already, there's so many different options, there's so many different things that people could do. If someone wants to get started with this stuff, like, you and I have both got started with it, we know we've probably got our own, you know, half a dozen side projects that we're already working on on the side. Someone's sort of coming into this, maybe they're a bit of a holdout or they've been told they can't do it or they've now been pushed to start doing it, like, where do they get, you talked about Lovable, is it just Lovable, or is there some kind of concrete first step you sort of think they should be taking to get going? One is what tool to start with, I would just recommend Lovable as a default, right? And then the second thing is, like, hold on a second, I'll just share this URL with people, it's fine, it's like, it's my, I created this, so it's just bit.ly slash vibebrief, V-I-B-E-B-R-I-E-F, it's a simple, lightweight, like, PRD for vibe coding that people can fill out, and so I think that, again, it's kind of like PM, you learn best by doing it on the job, by doing it, right? And so I think, and for example, I have someone, I'm teaching a workshop this weekend, and she's a PM doing it for the first time, she's gonna create a personal website, you know? Like, you don't need WordPress or any of this jazz anymore, it's just like, you can create a really slick looking, and you can get all these JavaScript animations and all this cool stuff without knowing any of the code, so that's, so I would say as a default fallback, if you're like, I wanna do vibe coding, I don't have a project in mind, then just, great, create a, you know, even if you have an existing website, create a V2 website and see what you can do, that's a simple thing you can do. I do think a lot of, you know what's funny, is that when I ran my hackathon, so in July I ran a hackathon with over 250 people, most people created their own app for their own use case, like one person collected stamps, so like, I wanna create a stamp collecting app the way I like to, someone else, like, I wanna track my nutrition the way I want to, so it's kinda like the iOS Apple stores, like there's an app for that, well now it's like everybody can create, you want, you're like, how you do to-dos, you create your to-do app, right? Like, and my daughter, who's 14, went to it, and she created two apps, one was to track her money and her finances, and the other was to track recipes, because she likes to cook and bake, so that's the other thing I would recommend, is think of some, you know, some side project or something, even not for money, but just your personal passion, like I'm into nutrition, right, and I have a certain way I like to think about the macronutrients that I think is like a good visualization, like if I had some spare time, that's what I would kinda play around with vibe coding, right, something like that, so yeah, so that's the idea, I think you just, you know, try Lovable, all these tools, by the way, have free tiers, and you're probably not gonna hit the paywall, if you do, you're probably gonna be glad that you did, because it means you're making really good progress, and you know, and they've all added rollovers, you know, it's gotten very consumer-friendly, the rollovers and all this other, you can just pay as you go, you can just buy as you go, no one's trying to lock you in any long-term contract, but I think, and actually, you know my mantra after doing so many vibe coding things, this is what's funny, Jason, is they've got the tool set up, they fill out my vibe coding brief template, and they're sitting there staring at the empty box with their cursor blinking, and I'm like, and they're just like a deer in headlights, I'm like, copy, paste, go, I've had, like, that's the first speed bump or hurdle, like, it's just a mental thing, they're like, is this, and it comes from the old school, like, perfectionism, like, is this right, is this gonna do the right, it's like, you have to understand, this is not about perfection, just jump in and go, and you'll change it, you're gonna iterate, if you realize it was all junk, then start over again, right, so I just quote to everybody for vibe coding, my top piece of advice is the Nike slogan, just do it, just do it, just jump in and do it, get your hands dirty, there's plenty of people that haven't started yet, and so it's not too late to start learning today. But there are some people out there that might be sitting there saying, that sounds fantastic, I'm definitely gonna try and do that, but there's organizational inertia within whichever, maybe they work in a bank or something, maybe they've been told explicitly not to go and do that, because, I mean, obviously, they can't stop people doing stuff for side projects, but if they wanted to start bringing this into their actual day-to-day work, have you seen any kind of tactics or approaches you can use to persuade skeptical people and maybe slightly laggardly businesses to maybe start letting you experiment around the sides, or are there some times you just have to give up and just stick to your side projects? Well, one, I would say, if you're in an environment where you can't do it in your work, then definitely do it on the side, and I would advocate even maybe doing it on the side, because you can just, you know, you might even have more motivation for your own personal projects to do stuff, and it's kind of fun, and you'll learn by doing, which is fun. Inside a company, I think the number one thing is to make sure that people understand, like, what'll happen is typical big company stuff, somebody'll be like, oh, security, oh, security, you know, and so the first thing you have to say is, no, none of this is going into our code base, none of this is getting deployed, this is just a prototype. You know the Figma things we used to do? This is just that, you know, so that people understand that it's just like a substitute for a Figma clickable Figma, that's all it is, really, right? So that's it, and then typical change management is like, hey, can we pilot this on one team and see how it goes, you know, and I think that, you know, I think that the team will find that they will be able to iterate more quickly and get customer feedback more quickly, and stakeholders will like it, I mean, as soon as stakeholders start seeing these robust prototypes instead of some boring PRD or something that they're not gonna read, they're gonna want it too, right? And then the problem there is, then they can start, you know, telling you, they can start giving you modifications to the thing that are all, or now we're back to solution space, well, they'll just, and that's another aside is, I've had more than one product leader say, I want us to do VOD prototyping so we can go and talk to engineering and be like, look, it didn't, you know, why are these things taking so long? Kind of in a respectful way, challenge this. Oh, baby dragons. Yeah, not be, not in the coding, but just like, you know, and it's funny because sometimes, you know, it is, we are able to do things that people, you know, seem faster, would take longer or something like that. So it's just interesting. Yeah, it's interesting, if nothing else, it's a way to get people to and aligned on a product idea much more quickly, right? Well, we could all do with a bit of that. Now, you've got this book here that's been around for some time now. Yes. You're talking about your framework that you've now have for vibe coding. So are we to expect a vibe coding book from Dan Olsen soon at some point? You know, it's interesting. I don't, I've, you know, I've seen some AI books come out. The sad thing is, speaking of waterfall, the publishing industry is very waterfall. I've seen AI books come out, and then like, it was before like Gemini even came out. And now the whole book is kind of irrelevant. I think, and I'm a love books. I, you know, listened to over 100 books on Audible last year. I wrote a book. I love learning education books. And I'm hesitant to ever say, oh, I don't know if I'd write a book on that topic. But AI just feels like such a fast moving topic that I feel like most books would be out of date by the time they get printed. So I don't think I would write a book on it. That's why I like focus on the workshops. That's the cool thing is actually doing a workshop every two or three weeks. I see the changes in the tools. I see the new features they're adding every two or three weeks. You know, I obviously I get the release notes and the updates, but then I see it. Actually, in one workshop, we were using Lovable. In the middle of the workshop, the UI changed. Like the button name changed. I'm like, they just launched something while we were doing this, right? So I think that that's the way, I think with AI, you just have to use, and look, we're all busy. So you have to figure out how to do that, how to figure out which things are worth investing in. Because you can't learn a bazillion different tools, obviously, so, but you do need to spend a little bit of your learning budget and time, just your time, on those tools, right? And so one way I stay on top of it is with email newsletters that cover AI. And so a lot of people who ask me which ones do I read. So I'll just give them real quick. The Rundown AI is one, Superhuman AI is another one, and Pivot 5 is a third. And every morning, I just read those to see what's going on, you know? Because it's changing so fast. Well, fair enough, but, you know, I'll still keep my eyes open, just in case. I'm not saying I wouldn't write another book, I just wouldn't be a big AI, you know? I do hope to write another book one day, but. About nutrition, you can do one about nutrition. Oh, well, you know, I thought about, yeah, I thought about it would be a whole other thing, but I thought about it, I've geeked out a lot on it, but maybe create an app on it, we'll see. But speaking of AI, for all the people that have managed to stick to this point, I have a joke for them. Ready, Jake? Let's do it, let's do it. All right. As long as it wasn't written by AI, because, you know, come on. No, no, no, it wasn't, it wasn't, so. And we were talking about, you know, some people, like, are leaning into AI, some other people are scared of it. What do you call someone who's afraid of AI? I mean, let's, for the sake of argument, say I don't know. What do you call someone who's afraid of AI? Claude Strophobic. Ha, ha, ha, ha, ha. I knew it was coming, I knew it was coming, but. Hey, I'm a dad, I gotta do dad jokes, man. Wow, yeah, well, you know, I've met your kids, I'm already feeling sorry for them again. It's funny, though, because Claude Strophobic now, you know, they'd probably have to re-brand, you know, because of the trademark thing from the. I saw the, I saw the Claude bot had to do it, yeah. Everyone's up in arms, apparently the fundamentals of trademark law are now up for debate, but Claude Strophobic, I think, you know, we can take that, we can take that. Well, if people are feeling Claude Strophobic and they wanna come and find you and, you know, learn a bit more or, you know, sort of tap you up for some resources or just generally catch up and see how all this stuff works, where can they go to find you off this? Well, my website is my name, dan-olson, O-L-S-E-N.com, that has links to everything else. I do have a YouTube channel, youtube.com slash danolson, where my talks are there, so my vibe coding talks are there, of course, all my product management talks are there, but the other thing, there are way more talks from my speakers that I've hosted at Lean Product Meetup. For 15 years, I've been hosting a speaker every month, so like Marty Kagan's on there seven or eight times, and I have a lot of AI speakers lately and vibe coding speakers, so that's a good resource, and of course, obviously, I'm on LinkedIn, so. So no one will find you there, because that's the last place you can find anyone these days. Oh, heaven forbid you have an external link anywhere, right, it's so funny, because it used to be like link in first comment, and now they're hiding the first comment, like they default to most relevant, where for some reason, if there's only one comment that links externally, it's not relevant, I don't know. That, this is a whole different podcast, so we'll be complaining about that, but I'll link all that into the show notes, and hopefully some people will come and feel some good vibes, and try and work out what they can do next, but Dan, obviously, it's always a pleasure to chat, always fascinating to dig into what you're working on, and obviously, it's been fun kind of batting some of this stuff back and forward, but as for now, all I can do is thank you for taking the time. Jason, thanks so much, man, it was great chatting with you about this stuff, and I hope it's helpful for people.