Dan Olsen | How I Test With Vibe Coding
Dan Olsen - Product Management Leader, Consultant, Trainer & Speaker
In this episode, Dan and I discuss the evolution of product management, the impact of vibe coding, and the importance of cross-functional collaboration.
Have a Listen
Summary
In this conversation, David J Bland and Dan Olsen discuss the evolution of product management, the impact of vibe coding, and the importance of cross-functional collaboration. They explore the challenges of prototyping, user research, and the role of AI in product development. The discussion emphasizes the need for strong product management fundamentals and the future of product management in a rapidly changing landscape.
Takeaways
The awareness of product management has significantly increased over the years.
Vibe coding allows for rapid prototyping and testing without heavy technical resources.
Cross-functional collaboration is essential for successful product development.
User research is becoming more valued in product management.
Prototyping should focus on learning rather than just building.
AI can assist in generating ideas but lacks judgment in prioritization.
The pace of innovation in product tools is accelerating rapidly.
Understanding customer problems is crucial for product success.
Rushing to high fidelity prototypes can lead to missed opportunities in the problem space.
Product management fundamentals will be key in differentiating successful products.
Guest Links
Website: https://dan-olsen.com/
LinkedIn Profile: https://www.linkedin.com/in/danolsen98/
YouTube Channel: https://www.youtube.com/danolsen
Lean Product Meetup: https://www.meetup.com/lean-product/
Vibe Coding Product Brief: https://dan-olsen.com/vibe-coding/
Vibe Coding Spectrum: https://dan-olsen.com/vibe-coding/
The Lean Product Playbook: https://amzn.to/1EYCUdP
Transcript
David J Bland (0:1.395)
Welcome to the podcast Dan.
Dan Olsen (0:3.340)
Hey David, it's great to be here with you today.
David J Bland (0:5.801)
I'm so excited to have you on. You've been on my list for a while now. I felt like we had to establish some credibility, you know, first and now we're 40 some episodes in. I was like, man, Dan is doing some cool stuff. And I want him on here to talk testing because you're one of the few people that I've met over the years. I think maybe 2011 or 2012 was when I first met you. And I was just blown away by how you think about testing, how you structure your own work and how you kind of apply that to help other companies and product managers.
Dan Olsen (0:11.374)
⁓
David J Bland (0:35.007)
And I thought, wow, it would be a great to get you on and just hear about what you're up to today. And we can kind of go back and forth and educate our listeners on what you're up to.
Dan Olsen (0:43.278)
That sounds awesome. I've been watching your podcast from the sidelines going, gosh, it'd be great to be on there. So I'm glad the stars aligned, likewise, I'm a big fan of your work. And ⁓ ever since we met back in the day, like you said, ⁓ so I'm excited to chat with you today about that.
David J Bland (0:57.567)
Yeah, so I I moved to the Bay Area, I think it was like early, well, I started working in the Bay Area around 2011 and then finally made the move in 2012. And I was always looking for like, who are these thought leaders? Who are the people that are like the cutting edge of stuff? And I met you, think at a Lean Startup Conference or something or Mac, even before it was called that. And I just remember you talking about, know, here's how we think about our assumption, our hypotheses and product. Here's how we test by building things, but we're building to learn, not building to build.
Dan Olsen (1:16.738)
Yeah.
Dan Olsen (1:26.563)
Right.
David J Bland (1:26.791)
I'm just curious for listeners at home, how has your thinking evolved over the years from back in the day when we didn't have all these tools related that we could just pull in ⁓ and we were trying to do this really scrappy, ⁓ what has changed for you over the years? What's the big aha moments for you over the years?
Dan Olsen (1:46.094)
Yeah, I mean the challenge is, you know, I've been working in product management for a long time and what I would say is the awareness and the level of effort and difficulty.
if you wanted to follow best practices, right, was high. So you had to have, you had to be like, yeah, yeah, we should use prototypes. We should use this InVision thing and we should, you we should, and you need a designer. We need someone who's gonna create the, ⁓ you know, who's actually gonna think about the UX and create the mockups. And then we're gonna upload those to InVision. And then I'm gonna string it together. And then we're gonna go recruit people. And we know how to conduct user research and we know how to do it well, right? We know how to learn and iterate and we know how to like separate our hypotheses from our, you know,
from what we're actually doing. And ⁓ you know, I've been beating the drum on problem space versus solution space forever in my career. And so it's cool that ⁓ one, there's much more awareness. mean, also PM just exploded, right? I mean, compared to 2011 when you and I met, it's interesting because just around a little bit before that time,
here in the valley where I live, were debates about like, well, if I've got engineering and I've got UX design, why do I even need a PM? You know, it was kind of like this, because design was having its moment. It was coming up. I actually did an event with a designer friend where we debated this. I'm like, well, yes, you need both actually. So that's the cool thing is product management has exploded.
And the way I like to summarize that is, know, Marc Andreessen said, software is eating the world. He said that a long time ago. It took the tech world a while to realize, yeah, and if you want that software to succeed, you need product managers to make sure you're actually solving a customer problem that matters and things like that. So I think the awarenesses ⁓ of all the things we talked about, and I think Lean Startup, there's like a Venn diagram of Lean Startup and product management, help product management tremendously by giving you a vocabulary and frameworks and things like that. That's why my book's called the Lean Product Playbook. It could have just been called the Product Management Playbook, but I saw the synergies there. ⁓
Dan Olsen (3:33.824)
And then the other thing too is just user research is having a moment too, right? I'm meeting more and more user researchers. I was very fortunate in my career. I started my career at Intuit on the Quicken team.
And because of the proctoring gamble roots of their founder, they very much valued market research, right? These companies have to convince you why you should buy this toilet paper instead of that toilet paper. So they do that through customer research. So we had a PhD in market research on my team. So it's nice to see user research be more valued. You see more more like SaaS products like Dovetail emerging, know, user testing emerging, things like that. So I think that it's never been easier. If you want to follow lean practices, it's never been easier with less effort.
David J Bland (4:14.687)
Yeah, your book's amazing and it's still going strong. I still see it all in my feed and people recommending it all the time. It's one of those like timeless product management books, in my opinion. And coming back to your capability statement, you know, I feel like one of the least used aspects of my book is the capabilities. Because for every experiment, I was like, oh, here are the capabilities need. You need a designer, you need a researcher, you need legal. You're like, nah, nah, I don't want to pay a ditch. Like, just tell us what theme it is, DVF, how much it costs.
Dan Olsen (4:34.912)
Right. Yeah. ⁓
Yes. Yes.
David J Bland (4:44.743)
I put a lot of painstaking work into modeling out each experiment with all capabilities and it's completely obsolete now. It feels as if all those capabilities are just being pulled into the tooling we use.
Dan Olsen (4:47.278)
Yeah, I know. I'm sure.
Dan Olsen (4:58.954)
I totally agree. totally agree. Right. So it's like.
everybody, like all the thought leaders say, okay, to build a successful product, you need these three key functions. And it's not trying to minimize any other functions, by the way. It's like we need a good strong product management, we need strong UX design, we need strong engineering. And it's like a Venn diagram, and we want those three functions to be skilled, and we want them to be working together collaboratively, effectively. And that's the secret to creating successful products. Obviously, there are other roles, UX research, DevOps, and QA, that is not meant to exclude anybody, but just kind of saying, hey, we need those three things. ⁓
And historically, it was like a factory line. It's like, okay, product management starts out by figuring out the requirements and the needs and does discovery. And then we hand it off to, it's like a baton race, relay race. We hand the baton to design. Obviously, it's done collaboratively. And then last, we give it to engineering. Well, ⁓ what's going on with all the AI tools and vibe coding and all these do-it-yourself things is those circles of the Venn diagram are converging more and more. And ⁓ if you're willing to kind of...
poke your toe and do more of the other circles, you can do more of it on your own, right? I've always called those kind of people triple threats. Like if there's a PM who can also do some UX design, and can also do some front end coding, or an engineer who can do those other two things, I call them triple threats. And they're very rare, but they've existed. Now we're seeing that being even more enabled, and you're seeing a new term emerge called product creator or product builder, which acknowledges that hey, a solo person can kind of wear all three hats.
and get most of that job done. So it's very exciting times and know, Vibe Coding for me, know, GNI was exciting. I was kind of excited with GNI, but when Vibe Coding came out, you know, actually just turned a year old. The term was coined a year and four days ago by Andrea Caparthi. And by the time I got into it, was like springtime. And I was like, my gosh, GNI is cool, but this is a game changer for product teams. And so that's why I just like jumped in with both feet. And I think it ⁓ even more creates these standalone tools that people can use if they want to be a product creator, product builder.
David J Bland (6:55.070)
I think it's really challenging our initial framing of the DVF kind of framing of the three circles. ⁓ And even some of my recent stuff, I would say, well, we want representation from each theme to walk through risk. as ⁓ those collapse, we have to really challenge that role framing on the edges there of, well, desirability. ⁓ Traditionally, I would say, well, that's research, that's design, that's... ⁓
Dan Olsen (7:1.517)
Mm-hmm.
David J Bland (7:22.756)
sales, it's a lot of value props, sometimes product, also viability, it's product, accounting, finance, people understand that. For feasibility, it's often tech, legal, ⁓ compliance, governance. And as those shrink and kind of collapse, it's really challenging that framing, which I always viewed this as something these people should be talking to each other and we're collaborating on that. But I do think in practice sometimes
Dan Olsen (7:24.910)
Mm-hmm. Right.
Dan Olsen (7:32.814)
Yeah.
Dan Olsen (7:38.093)
Yeah.
Dan Olsen (7:45.814)
Sure. ⁓
David J Bland (7:49.200)
It's like, that function does that. This function does this. And it can ⁓ unintentionally create silos inside organizations.
Dan Olsen (7:51.734)
Right?
Dan Olsen (7:57.078)
Yeah, no, I think it just, ⁓ I would actually argue the default method is tends towards silo towards versus not. And the reason why is very few people have actually worked in a very effective matrix organization. We're talking about matrix organizations there. And I was very lucky just in my career, my first job out of college was a highly metric matrix technical organization that just because it was.
in the Navy and because it was Department of Energy, was just, that's how we did it. You that's, that's you've, walked into this machine and they had their decision making process and their workflow ways of working and you just walked into it and it worked like a charm. It forced and it forced cross-functional collaboration ⁓ in a good way. And then I went into it, which, you know, wasn't a military government organization, but still had really good cross-functional matrix. So I went, you know, my first two examples were pretty darn good.
But what happens every once in a while, even at Intuit, we get someone who had not worked in a good matrix and they just really don't understand how this ⁓ cross-functional orchestration is supposed to happen. And so I've worked with a lot of digital transformation clients where they're trying to get clarity on roles. And I created this one slide that breaks out the phases. Like I call it the 4Ds, like discover, define, design, develop.
and then we break down the functions ⁓ as rows and then I show who's driving, the driver changes during each phase but you still gotta sync up with your cross-functional peers along each one. So that kind of slide makes, kinda explains it. But yeah, if you haven't seen the cross-functional orchestration, ⁓ it can be difficult for people.
David J Bland (9:22.492)
Yeah, it's kind of like a lived experience. You I was lucky I was at startups, so we were cross-functional by need, if nothing else. ⁓
Dan Olsen (9:24.525)
Mm-hmm.
Dan Olsen (9:28.782)
Yeah, when there's five of you in a room, know, that's why I used to joke when I did my start, I'm like, and we know whenever we'd find a bug or some miscommunication, we're all packed in this little room. I'm if only I best sarcastically be like, if only we sat closer together, you know?
David J Bland (9:42.067)
Yeah, it's interesting to see this collapse. with regards to vibe coding, how are you seeing this in practice change what we think product management is? ⁓ What are you seeing? I know people wax poetically on LinkedIn and everywhere and say these crazy statements and everything, but you live this day in and day out. And I'm just really curious, what are you seeing? What are you experiencing?
Dan Olsen (10:1.815)
Yeah.
Dan Olsen (10:7.662)
Yeah, well first off, so I jumped in with both feet. mean, because I did have a technical background. My parents got me a computer when I was a kid. I was an electrical engineering major. In 2005, I made it a point to just learn the web stack because I realized I was gonna be working on the web. So I had that kind of.
Latent dev skills in the background and ⁓ early in my career I ⁓ realized it into it like my gosh UX design is this important field and so I made it a point to learn about that so for me vibe coding was like okay cool I can use all my PM skills and I can use those dev skills and those UX design skills So I was super excited ⁓ and I just you know The first thing I did is I had my monthly lean product meetup after I learned the tools enough I hosted a hackathon for 250 people hosted a second one I've been training people on vibe coding now. I do as many vibe coding workshops as I do product management workshop
So just want to kind of kind of qualify like the data points that I've got but the way I like to always couch it is back to fundamental principles You know, I've got my product market fit pyramid I talk a lot about problem space solution space the top two layers of the pyramid the last two are features and UX and What and the ⁓ of the pyramid is like it starts with your target customer the second layer is what are their underserved needs and the third layer is value prop the
The biggest thing is most companies, most products fail, most features fail, because they jump in at the feature layer. They jump in and say, let's start, they start with a solution, not a problem, right? And so my biggest thing is cool, get, know, don't, before you build anything, get to the top of the pyramid, which is the UX layer, and then create a prototype and close the loop with the bottom of the pyramid by testing it with customers. So I've always advocated for doing that. I'm like, you know, before you ask engineers to build,
anything, right? You know, just make sure you test this thing. ⁓ And so the thing is, and I used to, I would give ⁓ a description of here's how the artifacts you can use along the way. You can start out with a low fidelity hand sketch. And then if you want, you can do some wireframes that are also low fidelity. Sometimes we skip that step, but the money prototype was always the, you know, clickable, tappable mockups. Like that was the thing, whether it was InVision or Figma, right?
Dan Olsen (12:10.146)
That was the thing and that's my bread and butter. Like when I want to test a product idea, that's the main tool that I use. But then I realized that I've worked with so many companies, they get it, they want to do it. They don't have the capability from your book. They don't have the prototype or resource, you know? And it's like the PM either, why would they know Figma? Why would they be a Figma expert? Why would they even have time to do it on top of all their other jobs? The engineer, same thing, right? So, you know, when I give my talks, I ask people, ⁓ I showed this slide, I call it the design gap.
And David, it's actually one of my oldest slides. It predates my book. It was from 2006. Like when I first started talking after I used to be like an interim CPO for startups and I saw this design gap over and over. This was obviously before design exploded. But even today, when I show the design gap ⁓ chart and I show five levels of maturity, level five being, hey, we've got the triad fully staffed. I ask who's got adequate, raise your hand if you have adequate design resources to prototype. It routinely less than 10 % of people raise their hand. And honestly, sometimes it's less than 5%.
So even in today's modern age, even though everybody understands design's a thing, even though everybody knows they should prototype before they build, people don't because they just don't have the resource. That's where Vibe coding comes in for me as a major unlock. Those teams that were blocked and so they go, I guess we'll just give it to dev. Like that's what they do. I guess we'll just build it then, you know? ⁓ And you know, it's really, it's a bad thing because basically you can never get that engineering time or resources back and you've already silently incurred all this tech debt.
It's like you're a basketball player. You just pivoted your foot. You can move around a little bit, but you're not gonna be able to move a whole lot, right? So you've already kind of incurred a silent tech debt, already constraints in the solution space. So for me, Vibe Coding just lets, now if you don't have a prototype, or guess what? You as a PM, or you as a front-end engineer can quickly crank out an interactive prototype. By the way, it's higher fidelity than a Figma, because it supports more interactions, just clicks. It's actual real HTML, CSS, and JavaScript.
In some incarnations of my artifact document, I would actually have a separate box for HTML prototype, but I took it out because back in the day it was too painful. Like why would somebody bother building an HTML JavaScript prototype? Some people would, but nowadays it's super easy, right? It's super easy.
David J Bland (14:18.042)
It is, and it is also challenging my thoughts on how to approach this because in the past, and I'm really curious about your perspective on this, so I'd like to deep dive into this a bit if you're okay with it, ⁓ is ⁓ I would say ⁓ do a sketch ⁓ or do it like a balsamic or whatever wire framing, but it isn't ⁓ in color. It's really rough. We do it because we don't want feedback on usability. Nowadays,
Dan Olsen (14:28.419)
Yeah.
Dan Olsen (14:37.196)
I love balsamic, I love it.
David J Bland (14:47.196)
we can just tell the LLM or whatever the AI builder is what we want it, it spins up something that looks really good. It looks like it could be live. And we're getting feedback on that. Are you worried about teams ⁓ getting usability feedback ⁓ and inferring value? ⁓ And are you worried about us skipping that wireframing step or ⁓ do you not see that happening in practice?
Dan Olsen (14:50.050)
Yes. Yes.
Dan Olsen (15:13.538)
Well, I think you're touching on a few things that are really important. Like one is now that it's solutioning becomes so easy with Vibe coding, you know, there's a temptation, a further temptation to skip the problem space. I think we're teasing about a few things. That's one thing is problem versus solution. The other is what you brought is once you've got your solution prototype, what kind of feedback are you getting? And I always distinguish between usability feedback and product market fit feedback. Like that is, know, the... ⁓
The fact is UX problems can get in the way, can hide, ⁓ right? Can hide your product market fit. You may very well have the great feature set because your UX is so bad, nobody can actually see the value, can recognize the value. ⁓ I saw this the hard way where I was running user tests and like, know, ⁓ the first five tests we found some usability issues and some bugs and we fixed it. And then the next test, like no one was hitting those bugs and they were getting to the main screen.
and they weren't saying anything negative throughout the whole test. At the end of the test, like, so I started getting a little confident. I'm like, hey, how likely would you be to use this product? And to my surprise, 15 % of people, even though they had not mentioned a single complaint, there had not been a single UX issue or bug, said, oh, I would never use your product. And I was just shocked. And the cool thing is, as you know, whenever you get surprised, that's awesome, because you learn something, right?
And it turned out this was like a news product, like I don't like to get my news this way. So was like a mental model mismatch. That has nothing to do with usability or product market. It was more like product market fit. anyway, but the thing is, ⁓ and then you're touching on a third point, which I've always beat the drum on. Even before Vibe Coding, teams would rush to high fidelity too quickly. That is a pattern. So there's two ⁓ failure modes. One is you rush to solutions too quickly before talking about failure, problems and needs. The other is you rush to high fidelity.
without thinking through and long as you know, ⁓ in the design world, they change the terms every five or 10 years just to keep it interesting and confuse people, right? Back in the day when it was called a visual designer and an interaction designer, it kind of was the clearest and made the most sense. So the reality is actually, again, UX design is so important. I remember the first time I saw Jesse James Garrett's Elements of Music experiment, Matrix, ⁓ the five, ⁓
Dan Olsen (17:23.534)
⁓ the slice five plane, parallel planes, broken, I'm like, my God, like my mind was blown. I'm like, yes, I don't know any of this, let me learn more. And then he adds a simplified just five plane version, like skeleton structure, things like that. But basically what's going on is, ⁓ not to oversimplify it, but there are two very different aspects of UX design. ⁓ One has to do with the mental model, conceptual model, information architecture, ⁓ layout, things like that.
The other one has to do with the visual design, which is the colors, the fonts, and the pixels, and things like that, right? And my mental model that I show for this is like an iceberg, because there are those four layers of conceptual design at the bottom of the iceberg, information architecture, second up, interaction design, third up, and then visual design, fourth up. Visual design is the only part that's visible above the water, and most people, that's all they can engage with. That's how we engage with most of our information. We take 90 % of our information, right? So team, just rush in.
And the problem is nowadays, sadly for a designer, it's kind of like being left-handed or right-handed. You can do both, you can be ambidextrous, but at the end of the day, I think most designers are stronger and prefer naturally gifted at one or the other. And so now we have these confusing terms like a UI designer versus a UX designer. The intent is a UI designer is what we used to call a visual designer, and UX designer is what we call the interaction designer. But unfortunately people mix those terms up all the time. Now we have a product designer, which is the Uber designer of all, right?
But long story short is a lot of designers are frankly more visual designers and don't appreciate those other layers of the iceberg. And so even they will go rush and they get all excited about picking the colors and fonts and things like that. It's like, yeah, yeah, yeah, yeah. I mean, is this like a five page flow? Is this a four page flow? What are the steps in the flow? What are the steps in the process? What's the right layout? What's the right mental model? Right. So all those things can go out the window. The easier it gets, the more expedient it is to get to that high fidelity prototype.
the more tempting it is to skip problem versus solution, to skip, and that's where wireframes come in. If you're not quite sure about the mental model, the interaction design, the flow, the layout, the flows, yeah, you should do the wireframes, right? What I would say, and it may sound a little hypocritical, but it's not, is if you have an experienced team, you can go straight to high-fi, high-fidelity, if you've not skipped any of those steps, if you've kind of worked it through on your own. And so in the interest of experience, you sometimes will do that.
Dan Olsen (19:45.054)
Now that being said, we may not ⁓ go fully creating digital wireframes, but we certainly will sketch ⁓ on a whiteboard, on paper, on some digital tool. We will sketch before we do the high fidelity mockups to make sure we're clear ⁓ on those other layers. So anyway, yeah, so it's tempting. ⁓ And a lot of people think that, know, vibe coding, you can just, it's so easy, just, you know, code it and see what happens, get your feedback. And it's like throwing spaghetti at the wall. And the general idea is the more spaghetti we throw,
we might get lucky, it's like a certain percentage for each strand of spaghetti that hits the wall. But that is not a scientific way, it's a very low yield way to do it, right? That's kind of like the general thing of like why MVPs are bloated, right? Somebody in sales or in other stakeholder goes, I can't believe you're not gonna have feature ⁓ X in your MVP, I think we really need it. It's kind of like this comes from this human thing of insecurity, like, well, I'm worried it's not gonna be valuable, just add some more stuff and the better odds it's gonna be valuable, right?
So I think you're seeing disciplined teams use it in a good way and you're seeing other teams just kind of crank it out.
David J Bland (20:46.151)
Yeah, it's great. I mean, I'm reasoning through this myself and I feel like there's a lot to unpack there. I ⁓ still see teams misinterpreting usability feedback for feedback on value. And I think it's just easy because they're excited and they want to hear what they want to hear. And ⁓ it's really tough to discern the two as we interact with the visual aspects of design. ⁓ The spaghetti one, I feel like it's infinite spaghetti at the moment. ⁓
Dan Olsen (21:4.526)
⁓ Yes.
Dan Olsen (21:11.886)
⁓ totally.
David J Bland (21:13.381)
We talked about niche to win like early 2000s, early 2010s at least. And it was do something very specific for a very specific customer segment, understand their jobs, pains and gains. You know, do they have the problem or they where they actively seek a solution to like dial in on that and then, and then, and then build out from there as you learn. ⁓ And what I see in practice right now, and it's a bit more extreme side. ⁓ I see let's just spin up 30 different apps for 30 different types of people all at once.
Dan Olsen (21:20.248)
Yes. Yes.
Right.
Dan Olsen (21:28.952)
Right.
Right.
David J Bland (21:43.650)
And it doesn't take much. ⁓ mean, let's environment aside, it doesn't take much from a level of effort point of view. ⁓ And then if they don't work, who cares? And we're just like, but it's like, it's almost like we're brute forcing this approach at the moment. And do you see that as well? I think it's not as common yet, but I do see people doing it.
Dan Olsen (21:46.712)
Sure. Sure.
Dan Olsen (21:53.804)
Yeah, ⁓ I know. ⁓ Yeah.
Dan Olsen (22:0.930)
I see the temptation, the old version of it was always like, ⁓ the foundation of my pyramid is who's our target customer? And I would work with a client and they'd be like, we got these three segments. We're not sure which one's the better one. Let's test all three. ⁓ I'm like, well, ⁓ maybe we can do two, but honestly, you're just punting. ⁓ If you don't know, if you can't decide, then you need to go do some research and do some analysis to figure out.
to have a point of view about which one's gonna actually be the best and have a hypothesis. If we learn that that's wrong and we change it, great, but let's at least start right. Strong opinions, loosely held. Have a freaking opinion. So that's the thing. ⁓ sometimes to placate a client, I'd be like, okay, we can do two, we'll run this, but usually it was the same prototype, right? was the same prototype, two segments, whatever. ⁓ But I would try to talk them off the ledge and just try to do one at a time. Because at the end of the day, the funniest thing, man, is obviously,
The first pass through the lean product process through the pyramid, the first prototype you have, that's when there's the biggest uncertainty, the biggest miss you're gonna have with the market. And your learning really starts, yeah, of course we should do discovery. I have a new chart that I show, like, ⁓ like kinda how much uncertainty or knowledge do you have? And by doing discovery interviews before you prototype anything, you're gonna get to a certain point, but there's diminishing returns at some point, because it's just like, okay, I've talked to enough people, I have a theory, if there are hypotheses, let's go prototype and test it.
Testing a prototype is the biggest gain in value, kind of for time. The biggest ROI investment is testing a high fidelity prototype with people and you can iterate on that and basically it's right. So that's really, really important to kind of create value and figure it out. So that's what I see people, you could brute force it. You know, it always makes me think of like, I'm a math geek. So like you have the 3D surface with the spikes and the hills and the mountains. It's like you're trying to find the global maximum.
That brute force approach, like just put 30 random dots down and see where we're at. ⁓ I actually think you cannot, that's not even the right metaphor because you cannot hit the, the other metaphor I use is like an archery target bullseye. You cannot hit the bullseye on your first shot no matter what because you don't know enough. You don't know what you don't know yet, right? So, because to your point, chances are any team that's going for that approach probably does not appreciate the nuances of market segmentation or problem space.
Dan Olsen (24:16.583)
and UX design that we talked about, right? ⁓
David J Bland (24:20.593)
Yeah, yeah, I like that. think with another thing you said there about MVPs and I saw this early days in my consulting was, you know, we would kind of create one inside a company. It would look good. And it took a lot more effort because we weren't, you know, vibe coding or whatever, but it looked okay. Behind the scenes, it was just held together with, you know, duct tape ⁓ and we would show it to a stakeholder and then they would say, this looks amazing. Can we launch this now? And it was ⁓ no, I mean, it's not necessarily well constructed and architected and secure and everything.
Dan Olsen (24:36.066)
Right?
Dan Olsen (24:39.564)
Right.
Dan Olsen (24:47.906)
Right. Sure. Yep.
David J Bland (24:50.527)
using this to test to learn. But I saw a lot of teams fold under that pressure of, need to get this out and launch. Do you see that happening with Vibe coding where it's like, I'm going show this to somebody and they're going to say, oh, that looks great. It probably looks even better than what we did back in the day. Launch it now. Or what's your take on launching these things? My take was always, our goal is to learn, not necessarily to scale. And what do you see going on in your day to day?
Dan Olsen (25:9.410)
Yeah.
Dan Olsen (25:13.550)
Sure, totally. Yeah, well, I mean, even back in the days we were talking about before the time frame where you and I met, I remember I was working with a very talented designer and so they were creating HTML CSS prototypes. And we took it to the CEO who is not had not worked in Silicon Valley was not technical. And so he just he, you know, basically back to that UX design iceberg. All he saw the whole iceberg. He's like, there's the whole iceberg. It's right there. It's all above the water. I see it was just a visual design.
And he was like, ship this. And we're like, ⁓ this is just HTML and CSS. is not, back at the time it was PHP and SQL and stuff like that. So I do still think, it's funny, because you would think in today's day and age that people more realize, hey, what's required for a full stack application and things like that. But I'm hearing the same thing happen. Non-technical stakeholders, be it the CEO or the head of sales or people in sales or other departments go, that's amazing, ship it. And they don't understand.
that there are two very different use cases. So, you when I got into vibe coding, I realized there were so many different tools available. I'm a frameworks guy. If look at my book, I have like over 50 figures and tables. I'm all about visual frameworks, like the iceberg metaphor and the pyramid. And so I realized, man, there's no one's created, I looked around and no one had created a kind of a ⁓ scheme for how to think about these vibe So I created the vibe coding spectrum. And the main aspect of it is it goes from less technical on the left to more technical on the right.
and I created six categories, actually six different categories of Vibe coding tools, and they vary by their degree of technical required knowledge. They vary by their user interface. Is it a web browser, is it an app, is it a Visual Studio Code plugin, is it command line? And they vary by who's the target customer. Is it more a product manager, is it more a designer, is it more an engineer? At the end of the day, anybody can use any these tools, but that kinda is the idea. And the reason I did that, and when after I did it, I realized, know, every once in a you'll see someone on LinkedIn or Twitter hating
that somebody says, oh, you can't ship that level of prototype. And I'm like, yeah, that's not the point. The point is before we could never have created this prototype because we didn't have a prototype because of Dan's design gap. Now we can do it. And so it's all about testing and validation and like, let's polish this thing up and get it to the point where we know people love this thing and then go ask engineering to build it, right? So that's the, so they're really, you know, I actually down the middle of the graph and I call the left side vibe prototyping to distinguish this.
Dan Olsen (27:36.462)
and the right side Vibe Coding when we get into the nuances of it. And the funniest thing is the tell is when you boot up your Vibe Coding tool, is it default view a preview of the UI or is it default view the code? And the Vibe Coding tools default to the code. Of course you can go see the UI in a local host or something, right? But the other ones all default. Yeah, you can go switch to the code view, but you never have to if you don't want to for the Vibe Pro typing tool. So now, so that's how I really view it as two distinct use cases. People are missing the message if they think.
Now that being said, gosh, wouldn't it be great, David, if we could just take this code and ship it? And everybody wants that and sees that, wants that end-to-end thing, and people are working on it. People are trying to close that gap. Like I run my workshops and the ⁓ non-technical PMs will get their first prototype, ⁓ and they're all excited, and after 10 minutes, I just realized this isn't our brand colors. I'm like, well, maybe you should have specified that, right? So then we go and we put it in. Okay, now we match the brand colors. And then you start going, why don't we match all of our style sheet, like our whole style guide?
And so then it looks and feels better, but still as you know, doesn't mean the technical side is different. It's like, ⁓ and you go down that path, you're like, why don't we use our React components instead of starting from scratch? So people are tunneling from both ends, you know, to make connect that as dots, you're seeing that more and more. But I do think there's still two fundamentally different needs and two fundamentally different use cases. Just to be clear, the vibe coding one is, hey, I have an existing code base, I want to modify and extend this existing code base as I'm creating new stuff.
Whereas the prototype one is just, hey, yeah, maybe I start with a style guide or something, but I'm just trying to get a product concept that I can test with people to test it, validate it, and iterate it, you know?
David J Bland (29:9.956)
Yeah, I think that's a great framing. ⁓ What do you think is at the far left and right of that diagram? I think people could, I mean, they can't look at it right now, but what's at the extreme of each side for you?
Dan Olsen (29:18.882)
Yeah, sure, ⁓ So on the far far right is the command line tools. I don't need no GUI, know, it's like bloody knuckle, VI, I'm going in there on the terminal. ⁓ So cloud code is the king of that column all the way to the right. Just inside of that, just to be really clear, are dedicated IDE tools like cursor, ⁓ There are forks of VS code. At the other extreme, ⁓ you've got ⁓ the two leftmost columns.
I'll start with the second column. It's tools that everybody knows like Levelable and Bolt, right? Those are probably the most, two most popular tools. If you're not technical, you wanna just jump in and bang out a quick robust prototype, you jump in there. I actually put that in the second column and I call those kinda PM-centric. Again, anybody can use any tool. The leftmost column I reserved for the designer-centric tools and what these tools are is not so much that they're less technical, although again, they probably wouldn't.
some of them don't support any backend coding, which is something I didn't get to. I'll get to this piece of advice, my long, my long, having done it all different ways, when you're doing the Vibe prototyping for, prove a concept, do not worry about the backend. Do not spend one second on backend, database, integrations, authentication, because you're just going on a rat hole that is not adding any value to your prototype. You can just fake it, just fake it. Sample data, use browser local storage, just fake the darn thing. Because I, first time I did my first Vibe prototype,
I did front end only and I was all excited. Second time I'm like, I'm going full stack. Cause they kind of encourage us to go full stack. Next thing you know, I'm spending 30 minutes debugging Google auth cause I thought it would be cool to add Google auth. And I'm like, why am I, this is not adding any value to any time. again, so anyway, so that leftmost column for designer friendly is Figma make is in there. Obviously Figma is most designers love using that. So they launched make. There's actually a smaller startup that's doing really well in that space called magic patterns. And there are a few other ones too, but basically those tools,
support the kind of things a designer would want that other people, PMs and engineers are less likely to care about. Like can I import and export from Figma? Can I bring my own design system? Can I create reusable components and templates and libraries so that like, you know, I did one workshop for a Silicon Valley company and one person on the design team took the time to use the magic patterns like browser extension.
Dan Olsen (31:27.470)
to copy all of their components into a library, and now everybody can start out with their actual components. So it closes that gap. I call it the merge, going back to that thing of, wouldn't it be great if we could ship this level of this prototype? I call it the merge, the ⁓ diff merge gap. How ⁓ big is this delta when we try to integrate this code? If we start with our components, then it's going to be a lot smaller, obviously.
David J Bland (31:50.886)
I like that you've taken sort of ⁓ your experience and applied it to VibeCoding for almost like a taxonomy to help people, because I think it's pretty overwhelming. All the new tools, they change every day. Every time I log in, like, Lovable does something completely different. ⁓ And I agree with the just personal experience. ⁓
Dan Olsen (31:59.788)
Yeah.
Mm-hmm. ⁓ I know. I know.
David J Bland (32:10.821)
getting tied into the backend stuff. Like before you know it, I've spent an hour trying to figure out why SuperBase doesn't send an email and doesn't integrate with Resend. And then my domains all messed up and then firecrawl silently failing. Like ⁓ it's, can easily ⁓ get lost in all those details ⁓ and forget that, wait, I'm not trying to launch a production ready thing. I'm trying to test to learn with this. It's so easy, even us, like it's so easy to fall down that rabbit hole.
Dan Olsen (32:17.967)
Exactly, ⁓ exactly.
Yep.
Dan Olsen (32:26.893)
Yeah.
Dan Olsen (32:32.014)
Right, right, right. I know. Yeah, when it's easy to do, and that's one of my latest insights after doing a lot of these workshops is basically, usually when we talk about, we're gonna create a prototype, it's the audience is prospective customers or customers, right? That's the primary audience that we're talking about. What I realized with Vibes Coding Tools is actually four distinct audiences, each one offers value. The first audience is actually you as the prototype creator.
because no matter how good a job you do on Discovery, and oh, and by the way, I wanna mention, in my consulting, I created a product brief. So many times after so many projects, like the fuzzy front end, nobody knows what's going on, I created a simple, lightweight, I wouldn't call it a PRD, it's like a lightweight thing that helps you identify why are we doing this and goes through the pyramid. I modified that for Vibe Coding, and I have a Vibe Coding template that everyone's, it's called a Vibe Coding product brief template.
It's at bit.ly slash vibe brief. Anybody's welcome to use it. It's just a Google Doc, you can copy it. But basically that is really important to make sure that you're kind of starting off well. The first audience, well let me do it again. Like I was saying, there's four audiences. The first audience is actually you. You do the best job you can on the initial prompt that you do. ⁓ Everybody does the first prompt, hey, build an Airbnb clone, and it does it, like yay, but you know that's not gonna be at Airbnb, right? So everyone who realizes all these tools are now more prompt, more context, more context, more context.
The tools themselves is funny, back to these the tools are changing every week. I used to run my initial workshops, you'd put in the query and then you come back in a few minutes and the UI's there. And so I did that, I call it putting the cake in the oven, right? Like kind of on the cooking shows. And I come back and it's blank, I'm like, no, there was a bug. It's like, no, there wasn't a bug. Lovable's like, hey, before I do this, let me just ask you a few clarifying questions. So the tools themselves are now getting in your way to be like, have you thought about this?
So they're realizing that they're gonna get better output if they clarify some questions, right? But anyway, when you get to the first shot prototype, you're gonna be like, you're gonna find five things that you didn't even think about, you forgot to specify in your requirements document in your brief, like, you know, maybe a table gets rendered. You're like, why did it sort the table that way? That's not how I I wanted it sort this way. But did you say that? No, you didn't. So that's the thing is you find these unknown unknowns that you didn't know about by.
But you yourself playing with the solution, so basically the way I tie it is by experimenting in the solution space, it's gonna help you shine a light on parts of the problem space you didn't think about, and you're gonna improve your brief and brief and then you're gonna, so anyway, then you iterate to the point you're like, okay, now I'm happy with it. That's audience one. Audience two is, let me show it to my triad, my cross-functional product team members. Let's show it to the designer, the dev, anybody else. See what feedback they have. Maybe they have some feasibility feedback. Actually, we can't do that, or that doesn't mean our style guide, if we just tweak it this way, right?
and you get them happy with it. Now you've got more buy-in and you've got more shared vision, by the way. The next audience is actually stakeholders, right? To your point, you gotta be little careful so I don't say ship this thing. But you know, let's be honest, your stakeholders are not gonna read your long PRD, right? ⁓ And so what you end up doing as a PM is, let me create a Google Slides deck to summarize my PRD for consumption of these special stakeholders. They need this special baby formula a certain way. They can't eat the PRD food, right?
Dan Olsen (36:34.530)
So you end up with all this busy work. Guess what they love even more? An actual product that everybody can relate. Because if you think about it, ⁓ this PRD is trying to represent in words what we're trying to convey. This PowerPoint or ⁓ slides are trying to just show the darn thing. Show, don't tell. And so that's very powerful because then people can engage with it. People that aren't back to this, they're not UX savvy. They're not product savvy. ⁓ But they can actually engage with it say, I like this. I don't like this. And you can get people excited.
And then the final audience, obviously, of course, great, prospective customers or customers, let's go show it to them, right? So I found that there's four valuable audiences and ⁓ you being the first audience is actually quite helpful because ⁓ inevitably nobody gets their first Vibe prototype. has all the, no matter how much you've thought through. It's funny, I ran one workshop for a chief product and technology officer, CPTO, that's more common these days, you see a lot more of this. So in my workshop,
A lot of times it's just PM or PM in design, but in this workshop it was PM design and engineering. And they, because engineering was there, they like blew out the spec part of the product brief, like is exactly how it's supposed to work and the data model and things like that. So they put their query in and this was last summer before the tools had gotten better and they got ⁓ a prototype back that was pretty darn good, but they noticed it was missing some key thing. So this is another thing, this is a learned thing is when do you try to finagle your prototype and kind of course correct a little bit?
and when you say, you know what, we're in the wrong part of the woods, we need to, I call it nuke from orbit and start over. They're so easy, these are like Kleenex, it's like, okay, that wasn't good, great, let's start. So you go back to your product brief, you add the stuff you missed, and they did that, and on their second shot with the updated brief, it produced this amazing, what I call four level deep prototype. It had like an overview dashboard, it was for doctors. You clicked on a doctor, it went to a doctor page, it listed their patients. You clicked on a patient, it went to the patient page and listed all of their appointments. I mean, it was like.
from ⁓ a product brief that took them maybe 25 minutes to write or 20 minutes to write. It was pretty impressive.
David J Bland (38:31.417)
I like that framing and we'll link ⁓ all this in the detail page and in the description of the podcast for those of listening so you can get to this stuff. What I've noticed is something like you're doing here with the brief. So I guess a real example. So I built this little ⁓ roaster for lovable apps because everyone's building all these lovable apps ⁓ and it's just called Tough and it just applies like my...
Dan Olsen (38:51.477)
I saw, yeah, yeah, yeah.
David J Bland (38:55.781)
kind of desirable viable feasible prompts and it has my experiment library and all that powering it. But it's really just as a one pager of like, hey, stress test this, here's some things to fix before you're going to that fourth type of customer. ⁓ And ⁓ it was interesting, some of the feedback was like, yeah, but could we do that before even ⁓ the app we're building? And I feel like maybe your brief...
Dan Olsen (39:5.568)
Right. Right.
Dan Olsen (39:20.478)
Mm. Mm, yeah.
David J Bland (39:22.307)
is part of this of can it's like, can I even just test the prompts before I put the prompts in? know, it's almost like we're taking this and we're trying to bring it further upstream because I'm saying, well, you already built something. It's probably just you're just looking at yourself. But can you pull that even further up so you don't even get to the point where you built something for yourself that you shouldn't have shouldn't have coded?
Dan Olsen (39:28.290)
Yes.
Dan Olsen (39:32.375)
Yeah.
Totally.
Dan Olsen (39:40.876)
Right, no, that's what people are realizing. That's the thing is, it's like, that's the thing is, ⁓ it's that rigor of thinking ⁓ of like, what are the key questions that one needs to answer? And the problem is, once you've got the prototype, you're already in the solution space. And now it's about you're manipulating and ⁓ considering option, optionality in the solution space. well that feature didn't work, what about that? But usually the core problem is, you're not solving the right problem.
your mental model is wrong, you're not talking to the right car customer, you know what mean? That's really the thing. And so it's really hard for someone to go, wait, I know why this isn't working, is because it's three layers deeper than where we're acting and thinking right now. It's really, you know, it's not gonna happen that way, right? So that's why in a sense, it's kind of like a checklist. That's why, for example, some of the key differences of my Vibe coding template versus my just PM product brief template, you wanna, all the problem space stuff is identical. Like what's the business objective? Who's a target customer?
What are their problems? Let's prioritize those problems. That's the idea. That's the solid foundation no matter what. What's our value prop, right? Then the thing is for vibe coding, we've always been trained as PMs, don't get in the solution space. Well, you kind of got into the demilitarized zone between the problem space solution space, like this gray area, because you got to give it some clue, right? The other thing I would tell you is, any decision you leave to chance or unspecified or as a degree of freedom, the tool is going to have to
make a choice, it's gonna guess. And there are a thousand or a million different possibilities. The chances that it's gonna guess what you as a smart human would have done is low. So if you leave things unspecified, like for example, I was saying like the table sort order, oh, I didn't think to specify that, you know, it probably won't get it right. So then you can go back and say, let's do the table sort order, right? So there's two other sections that I asked, which is kind of like, you know, kind of like high level, what should the functionality be? If there's any kind of key flows, if you know what's going on.
But the one section that kind of gets at this intersection of mental model and data is I added in data slash object model. And I've done database design. I'm not trying to say you need to figure out the database tables and schema and things like that. What I'm saying is more at a UX level, you need to think about what are the objects and their relationships. We have regions, we have stores in those regions. Those stores have employees, those stores have products, those products have these properties.
Dan Olsen (42:1.752)
Cause if you leave that data model, like that object model to chance, it's not gonna get it right. And then the whole foundation is kind of messed up. You know what I mean? So it's interesting that you need to kind of like peek a little bit into ⁓ the solution-ish world kind of from an architecture or UX design standpoint to kind of have that initial shot come closer to the mark.
David J Bland (42:23.032)
Yeah, I love that framing. think, and maybe we can start wrapping up on this topic, ⁓ is my current soapbox at the moment anyway, and I'm really curious of your take on it. Because not, I mean, okay, every now and then I get on soapboxes, and this is my current one, ⁓ is ⁓ the genius kind of out of the bottle with AI vibe coding and all this. ⁓ It's fundamentally changing how we look at how we work inside companies. ⁓ And what I see is often what you're articulating, and obviously you're trying to push this in the right direction.
which is if you think of our funnel, if you still think of things as funnels, on top of the funnel, we have people just vibe coding ideas now or using AI to come up with more and more ideas. But at some point in your organization, you have to test those ideas. You have to weed out the ones that don't have, ⁓ know, just aren't a good fit, aren't gonna have an ROI for your company ⁓ and get to a point where you're still launching things that customers need and are gonna generate revenue and, you know, help grow the company.
I see this influx ⁓ of AI for ideation, for vibe coding, just, that's because that's all very fun. Like I love doing it. ⁓ mean, late at night on a Saturday, I'm probably, ⁓ I shouldn't be, but I'm like, hey, this is fine. Let me make this look like this. ⁓ But what I see happening or what's shortly going to happen ⁓ is ⁓ these teams are going to be overwhelmed with the influx of stuff coming in. ⁓ And
Dan Olsen (43:29.644)
Right, sure.
Dan Olsen (43:37.358)
Sure, ⁓ sure.
David J Bland (43:47.611)
they're not using AI there, they're still manually trying to look at all of these opportunities and trying to, ⁓ so I'm more focused on AI there in the process, but I'm curious, do you see this coming? Are you worried about this or like, what's your take on this right now?
Dan Olsen (43:49.910)
Yeah, yeah, ⁓ sure.
Dan Olsen (43:57.176)
Yeah.
⁓ Yeah, so the very first AI talk I gave, ⁓ I played around with ChatGPT and it was like, think they had just come out with the new model. So I was like, A, testing the new model and the old model. And I was like, let's see, ⁓ let me go through my lean product process and see where can it help and how good a job does it do helping, right? My conclusion was, Gen.AI, ⁓
is great at divergent thinking. It's great at identifying options that you might not have thought about, right? Divergent thinking is like, what are all the possible problems we could address for this target market segment, right? You suspend judgment. This is what I call exploring the problem space. Before you actually lock it down, you wanna explore it, and then we'll converge and prioritize and discuss which ones are good or not, right?
So that's what I found it being very helpful as I thought of things that I didn't think about. Now some of those ideas are dumb or bad, some of them are good that you didn't think about, right? There's no judgment. Then when I tried to get it and I tried multiple ways and maybe it's slightly better, but at end of the day, I don't think it has great judgment when it comes to prioritizing the ideas. So I think that you need to, it's like how much are you phoning it in? If you just, you
I mean, this is what I like to say, like for this, even this vibe coding template, my workshops, I'm like, it's okay to use AI to augment it or make it better. But if you're just phoning it in from the get-go and saying, create a vibe coding brief for this, it's like you're bootstrapping from nothing. You're not, so I like to do what I call, it's like, you know, obviously it's human in the loop. It's like, I like to get 70, 75 % draft and then say,
Dan Olsen (45:30.902)
What did I miss? How can I make this better? I actually have some structured questions about each layer of the pyramid. Hey, what are some other market segmentation attributes I might have not thought of? What are some other problems I might not have thought of? And so on, right? What are some features I not So you can do that, right? You can ⁓ use it to augment it, but when it comes to prioritization and judgment, ⁓ and that's another failure point for a lot of companies, you know? ⁓ If you go and sample people and say, how do you prioritize ideas? You know what the most popular method is?
Well, it's what the senior stakeholders ⁓ gave us the rank order for. ⁓ Actually, it's whatever they most yelled about is number one, that's number one. And then next week they say number three is number one. So it's just shiny object syndrome and it's it's tops down stakeholder gut ⁓ prioritization. And that is not, so the funny thing is ⁓ ROI has been around for quite a long time. Rice has been around for quite a long time. I prefer ROI.
and everybody knows about it, but the percentage of teams that actually do ROI is again less than 10 % sadly, right? So, and then when I run my workshops, it's one of the most powerful exercises, because like, yeah, we got 12 different ideas, and we just do sticky notes on an ROI thing, and it becomes immediately obvious what's number one and what's number 12, right? And so, but it's like in the absence of one, the framework, and two, the practice.
Like if I had a stakeholder who was giving me a bunch of ideas, I'd be like, great, let's get all your ideas and let's do an ROI so that we can get aligned on it. And they're the ones picking the R values. They're the one. I mean, obviously, engineering picks the I values. But they're the one. You pick the R values. Great. You pick the returns. We'll just do the I's and then we'll tell you how it comes out. So there's that. And then when you get more sophisticated nuances, that's in the solution space. Gosh, wouldn't it be great if we were prioritizing in the problem space?
so that we're only tackling the highest opportunity problems and that is much more nuanced and the only framework I really know, that's like jobs to be done and all this stuff, everybody says brainstorm problems and then go, it's like great, but how do you prioritize the problems, right? So that's why in my career, when I was facing this into it, I tried a lot of different methodologies and that's why I created the importance versus satisfaction framework as a way to prioritize in the problem space.
Dan Olsen (47:45.442)
before we even get there. And I think this is a PM driven thing. Before we even waste anybody else's time, like engineering's time or design's time, and they can be involved in the voting too, obviously, but let's just make sure we're solving the biggest opportunity problem.
David J Bland (47:59.800)
Yeah, I think it's human in the loop. think it's my focus is more on the can we use, you know, an LLM to extract assumptions, but we're also doing it manually. And then we're seeing which ones it came up with that we didn't think of. Or if we do an assumptions map, we're feeding it in saying, critique this is for anything we are missing. ⁓ If you look at experiments, we're pulling from like my experiment library or and we're doing it manually and work. It's kind of augmenting. I like that word you said augmenting and human loop. Whereas I think
Dan Olsen (48:18.370)
Yeah.
David J Bland (48:29.465)
we're going to see this influx and I'm seeing it now of the ideation, the, you know, creating prototypes really quickly, but we do have to have a way that's going to keep up with that, that allows us to narrow down and select down and synthesize. And I'm curious, there's a lot, I mean, there's so much change happening right now. If you had to make a bold prediction of where this is all heading, you know, cause you're down in the weeds in this every day. Like you're one of the few people that I would bring on here to say, like, what is your take on this? Cause I know you're doing it. Where do you...
Dan Olsen (48:33.251)
Yeah.
Dan Olsen (48:52.470)
Yeah, yeah.
Dan Olsen (48:57.378)
Yeah.
David J Bland (48:58.905)
Where do you see this heading this year? I mean, what is your prediction on what's going to change, what we're going to see?
Dan Olsen (49:5.036)
Well, so a couple things, the pace of innovation from the leaders in Vibe Coding is insane. It's just like, it's great to see. I mean, as a product person, I'm like just marveling at the velocity that these not large teams are launching things with, ⁓ And I get all the email updates of what they're launching and some are slower than others and but.
The fastest ones is just like oh my gosh and back to your thing. It's funny I was doing I was teaching a workshop and I teach them like every week or two So it's not as very common for the UI to change from one week to the other. I'm like, oh
You know, it's funny like, you know, all these tools have a build mode versus a plan mode, like, so it doesn't actually build and they had different names for them. It used to be called chat. called it chat. One called it discuss. One called it plan. Well, now one, they all kind of be kind of standardized more on plan. I'm like, that's cool. But I was in the middle of doing a workshop in the middle of a workshop in lovable and the label on the button change. I'm like, well, did you guys see that? I'm like, like reloaded the pages. So, you know, they're those guys are really innovating at a fast speed. So one is I think that the ⁓
⁓ And it's like, you know, they said this is the worst model you're ever gonna use. They're getting really good. Opus 4.6 just came out. The cool thing is, you know, everyone's always like, well, balance this budget versus performance. Now, these vibe, the top vibe and cool is like, we have Opus 4.6. We just launched it, go use it. Like they want you to use the best tools. They want you to have the best experience. They don't want you to run into those debug death loops and other things like that. So it's, I think the pace is...
continuing to break neck is really fast. I think that what you'll see, I think that ⁓ one, they'll continue to go. I think their capabilities will continue to grow. I think what you'll see is people will try to tackle this. Yeah, gosh, how can we minimize this merge diff? How can we minimize it so that we can just take this and use it, right? And so for example, magic patterns, which.
Dan Olsen (50:55.104)
Will only do front end like they they they're kind of they remind me of balsamic because balsamic intentionally said we're doing lo-fi We're never gonna go hi-fi and they were a small startup and they were level product that everybody loved I still love it still around they own lo-fi wireframing, right? Magic patterns kind of like they're kind of like that. They're a small team They don't want to go too quickly and they're like we only do front end and by the way They're one of the only tools that support divergent thinking but you know every other tool you give it a product brief It gives you one UI you can go into magic pattern say slash inspiration and it'll do for
You know, so a little bit diverse. So I think that hopefully you'll see some more divergent thinking as well. By the way, I like to use Google Stitch. There's a whole other topic we didn't get into, which is at the end of the day, all these models are trained on text. And so you're giving it a text product brief. It's creating HTML, CSS, and JavaScript, but it's also rendering a UI that is pixels on a screen, but it's also semantically a mental model, right? And so the funny thing is, and I think Lovable does a good job,
but they have not been trained on actual layouts. ⁓ If you wanted to build the ultimate UX gen AI, it would be trained on good and bad UIs and it would know, ⁓ right? So there's some interpretation layer going on that's pretty darn good, that's decent and lovable, but its fundamental native language is not UI, its fundamental native language is text, right? So I think that you'll probably see some improvements there. So that's why Google Stitch is a great way to play around with just the design before. Another thing I'll just say, another tip is,
Yes, you should do a product brief, but these tools can also take text plus an image as an input. And that is the better way to go. You can, for example, text plus your color palette. That's good. Text plus your style guide. Great. Text plus your style guide plus ⁓ a black and white. ⁓ you went on a notepad and drew a really lo-fi wireframe and took a picture of it. Great. It's going to do three. you want three columns and like this? Great. You know, or
take or play around and stitch to create something and put it in right. So text plus a layout gives you better output than just text only basically, right? So I think you're gonna see the tools get better at the UX, the layout, things like that. ⁓ And I do think that they will tunnel through. What I was getting set to say is Magic Patterns has stayed on the front end, but they know that people are like, okay, now that I've got this, I wanna ship this thing, right? So they actually built an MCP server.
Dan Olsen (53:14.924)
that can work with your ⁓ cursor or clod or whatever to say, OK, grab the designs from Magic Patterns. Now go figure out how to implement this in the best way in our code. So that's what I mean by tunneling through. Another example is when I talk to the top teams that are further along in design systems and components, ⁓ most of them are using Storybook. So Storybook ⁓ is a tool where if you want to have your UI library while your components so that you have a big team, people aren't reinventing new components. You're reusing your components.
So you're kind of doing dry, don't repeat yourself. They're in Storybook. Well, so they would make a lot of sense to build a Storybook importer for those teams so that they already have their components there in HTML and CSS React. Let's just read them. So I think you're going to see more more there. The interesting thing, David, is so the lovable and the magic patterns are trying to tunnel to the right. But they can only go so far because the second they flip the code view, they're going to lose all the non-technical people. So they can only go so far. And you've got the cursors and the codes.
They're trying to go down and be like, yeah, like Cursor just recently launched a browser mode, so it's easier to see the UI than having to go spin up a local host or whatever. But they can only go so far before they lose the technical people, right? So think at the end of the day, you're going to have these two distinct markets. There's going to be some overlap. But that's what I see. And the biggest prediction is, back to what you said, is as it becomes easier and easier to create these awesome product experiences that are real code, that is not the differentiator anymore.
Right? You, me, the average person on the street can create a really great UI. So it begs the question where, who's going to win, what products are going to win, how, what's going to determine how they're going to win. Guess what? It's the product management fundamentals of how well do you really know your customer and what their problems are? You know, how good is your value prop, your product strategy? How are you differentiated? Right? And finally, and I do think this UX design for a while. I think it's going to be a while before, you know, if you think about also, I think about like,
There's a bell curve for every skill like marketing, copywriting. There's a bell curve. Well, the gen AIs are doing pretty darn good on that, right? They're probably, if you're like a bottom 10, bottom decile copywriter, you probably ought to work cause of gen AI, right? Front end coding, right? ⁓ They're probably producing what like a 20th percentile junior dev would be producing, right? UX design is I think UX design and PM are going to be, ⁓ I don't think UX design is going to take a while for UX design. So I think where can you differentiate? You can differentiate in all the PM thinking stuff.
Dan Olsen (55:37.038)
And in the UX, the true UX design stuff, you can differentiate. So it's an interesting time. We'll see how it plays out.
David J Bland (55:44.004)
Thank you. I learned a lot and I like, I love how you're thinking like tunneling different ways and not losing your customer. I just want to thank you so much for hanging out with me. We could have easily made this a two hour episode ⁓ because there's so much to explore here. There's such excitement. If people want to reach out to you about five coding workshops or ⁓ anything, where would they find you? What's the best way to reach out?
Dan Olsen (55:54.028)
Yeah
Dan Olsen (56:5.558)
Yeah, my main place is my website. It's just my name, dan-olsen.com, O-L-S-E-N, and then I'm on LinkedIn. ⁓ One other thing I'll mention is that I'm a big believer. When I was coming up in product management, there were no communities. And so 12 years ago, I started a monthly meetup called Lean Product Meetup. You've spoken there several times. We've most recently hosted you in person. It's in person at Intuit and Mountain View, but we also, during COVID, we went 100 % virtual. So we have an amazing audience.
⁓ Our Meetup group has over 13,000 people. It's one of the largest Meetup groups in the world. ⁓ And because I'm an author speaker, I'm able to get really talented speakers, not like your typical Meetup. So anyway, that's at meetup.com slash leanhyphenproduct. There are links to it from my website, but I would encourage you, if you wanna learn more about this, obviously there's a lot of overlap with PM and AI. A lot of my recent speakers have been about AI.
⁓ There's actually videos of the vibe coding hackathon that we did as far as the content if you want to check it out So and then those videos all live on my youtube channel, which is just youtube.com Dan Olson So those are the main places to find me online
David J Bland (57:6.755)
Thank you so much for hanging out today. I'm sure our listeners learned a bunch. I learned a bunch. You're always on the cutting edge of this stuff, so I just appreciate you sharing it with us. ⁓ And thanks so much for hanging out with us today.
Dan Olsen (57:16.322)
Yeah, David, was great chatting with you about all this stuff.
