00;00;00;00 - 00;00;24;15 Unknown Welcome to the deep dive. We're cutting through the noise today to explore, well, a fascinating paradox of our modern digital world. It's truly never been easier, faster or, you know, cheaper to build software. Think about it. Cloud platforms, open source libraries. These know code tools. Even AI coding assistance. The barriers have just sort of melted away. Yeah, they really have. 00;00;24;16 - 00;00;45;25 Unknown You can go from just a glimmer of an idea to working software in what feels like, you know, a weekend sometimes. And yet, for all that incredible speed and accessibility, a pretty sharp problem has emerged, hasn't it? It's easier than ever to build something that, well, ultimately misses the mark. Right. Something no one actually wants. Exactly. A functional app alone just doesn't guarantee success. 00;00;45;28 - 00;01;10;05 Unknown The real challenge, the thing we need to focus on is ensuring your product genuinely solves a problem and deeply resonates with users that you know at its heart is product market fit. And that's our mission for this deep dive. We're giving you a shortcut, basically a distilled guide to understanding how to avoid that trap. We're going to unpack the strategies that lead to building products people genuinely need and will actually, you know, seek out. 00;01;10;07 - 00;01;34;03 Unknown We've synthesized insights for you from a whole stack of incredible sources. Yeah, we've looked at everything from comprehensive industry reports on building the right thing and practical product discovery and design toolkits, some really sharp insights from product strategy. The new software battleground. We've even pulled in wisdom from recent discussions with leading product design experts like, Chris Mullins on the Feedback Loop podcast. 00;01;34;06 - 00;01;54;25 Unknown You'll get the key nuggets from all of them right here. So let's dig into this paradox then. The technical barriers to creating software have, I mean fundamentally collapsed totally. We're seeing development time for many tasks cut by what, 5,090%? There's even a projection that 80% of technology products will be built by non developers by 2024. Wow 80%. That's huge. 00;01;54;26 - 00;02;16;17 Unknown It's a massive leap from less than 25% back in 2020. And look at the no code and low code platforms. They're valued at over $21 billion this year. Plus, AI coding assistants like GitHub Copilot. They can make task completion like 55% faster, right? These aren't just small changes. They've essentially commoditized the technical execution part. It's a total game changer. 00;02;16;17 - 00;02;40;29 Unknown But here's where that double edged sword comes in. You mentioned this very speed can lead to a fatal misstep. If you build something no one actually wants. We've all seen it, right? Passionate founders pouring months, maybe years into perfecting a product they believe people want. Yeah, they're convinced only to launch it to, like, complete silence. An utterly indifferent market. 00;02;40;29 - 00;03;02;17 Unknown It's honestly heartbreaking. It truly is. And the data? Well, the data backs this up dramatically. There's a striking statistic reveals that a staggering 42% of failed startups attribute their demise to no market need for what they built. 42%? Yeah, just no market need. Exactly. So for anyone listening who's developing or investing in products, the core question fundamentally shifts. 00;03;02;17 - 00;03;23;12 Unknown It's no longer just can this product be built? Because with today's tech, the answer is almost certainly yes. Right. You can build it. The real question the crucial one becomes, should this product be built and does it genuinely solve a problem someone cares about enough to, you know, pay for? That reframes everything, doesn't it? The focus has completely shifted completely. 00;03;23;15 - 00;03;49;08 Unknown Modern product development now heavily emphasizes continuous vision testing, rather than that old kind of hopeful. Build it and they will come mentality. Yeah, that doesn't work so well anymore. Now really success now depends on combining that fast execution with incredibly smart validation. It's about building what customers truly need and will pay for using every tool. You've got to validate those assumptions as early as humanly possible. 00;03;49;11 - 00;04;12;25 Unknown Okay. So this brings us straight into product strategy and specifically early validation. Spot on. And the Lean Startup methodology provides an excellent framework for navigating this. It basically encourages teams to form hypotheses about their business model like who is our customer? What problem do they really have? What solution might actually work? And then test those hypotheses through rapid experimentation. 00;04;12;27 - 00;04;38;23 Unknown It's all about steering your product, you know, continuously asking whether to pivot or persevere based on real customer feedback. Every experiment is trying to answer one simple question. Should we build this? And probably the most famous tool in that lean startup toolbox is the minimum viable product, the MVP. Absolutely. The MVP. And it's often misunderstood, right? It's not about delivering a perfect feature, complete product on day one. 00;04;38;24 - 00;05;04;02 Unknown Not at all. Instead, it's about creating the fastest, leanest experiment possible to test a fundamental business hypothesis and just start learning. The whole goal is to avoid any extra work beyond what's strictly necessary to get that crucial insight. Can you give us a classic example? Oh, definitely a classic one is the story of Zappos. Back in 1999, the founder, Nick Swinburne, had this idea for selling shoes online, which sounded crazy back then. 00;05;04;02 - 00;05;25;20 Unknown Yeah. Shoes online. People wanted to try them on. Exactly. So instead of investing heavily in warehouses and inventory up front, he ran this brilliantly simple experiment. He went to local shoe stores, took photos of their shoes and listed them on a really basic website. Okay. When a customer ordered a pair, he'd literally go buy it from the store at full price and then ship it directly himself. 00;05;25;21 - 00;05;49;20 Unknown Well, that's crappy. Totally scrappy. But this sell for supply on demand MVP validated the core assumption people were actually willing to buy shoes online before he scaled up. And, you know, eventually sold to Amazon for over $1 billion. That's how you de-risk. That's really clever. And speaking of de-risking, another fantastic example, maybe saving even more potential engineering effort is Dropbox, right? 00;05;49;21 - 00;06;12;08 Unknown Oh, the Dropbox video. Yes. They were faced with building incredibly complex file sync technology. Huge technical challenge, right? Years of work? Potentially. Exactly. So instead of coding for a year, they spent, like a trivial amount of time making a simple three minute demo video, just showing how Dropbox would work. Just a video. Just a video. They seeded it to tech communities, places like Hacker News. 00;06;12;08 - 00;06;39;05 Unknown And that video just went viral. Their beta wait list jumped from 5000 to 75,000 users practically overnight. That validated massive interest and basically told them unequivocally, yes, build this thing, go full steam ahead, save them potentially building something nobody care about. And this kind of early validation, it doesn't just confirm ideas, it often leads to major changes in direction. 00;06;39;05 - 00;07;00;29 Unknown Right? Pivots. Yes, exactly. Pivots are crucial. Think about Instagram. It actually started life as an app called Bourbon. Bourbon. I remember that vaguely. Yeah. It was this feature heavy check in app, sort of like Foursquare, but with like points and planning features, all sorts of stuff. But the founders noticed something important in the data. What was that? Users were mainly excited about one specific feature sharing photos. 00;07;01;00 - 00;07;24;10 Unknown They loved that part. So Kevin Systrom and Mike Krieger, they wisely paid attention to that user behavior. Smart move. Very smart. They stripped the product down to just photo sharing. Renamed it Instagram and even added filters to enhance that core experience. People clearly valued that pivot directly. Responding to what users were actually doing led to massive, massive growth. 00;07;24;12 - 00;07;47;23 Unknown That's a great illustration of what Jim Collins calls firing bullets than cannonballs, right? I love that metaphor. You start with these low cost, low risk experiments in your bullets to sort of calibrate your aim and understand the target. See if you're even pointed in the right direction. Exactly. And then only once you've locked onto a viable direction, then you double down with the bigger investments, the cannonballs. 00;07;47;26 - 00;08;07;28 Unknown This incremental approach stops you from wasting massive resources, firing an expensive cannonball in totally the wrong direction from the get go. And those bullets you're firing? Often they come in the form of user research. Validating an idea isn't just about the tech you build. It's about deeply understanding who you're building for and why they might actually want it right. 00;08;08;01 - 00;08;29;26 Unknown Spending even a little bit upfront on user research can save just enormous costs later by preventing you from building features nobody needs or uses. The common refrain in product development is get out of the building. Get out of the building, meaning go talk to real people. Go talk to real users. As early and often as possible. Don't just sit in your office assuming you know what they want. 00;08;29;27 - 00;08;56;22 Unknown Okay, but what if you're like a super lean startup? Almost no budget for a fancy research team or anything like that. How do you get out of the building effectively without, you know, breaking the bank? That's where these cost effective techniques really shine. You'd be surprised even to say 5 to 10 focus conversations with people you think are in your target audience can reveal whether the problem you think exists is actually real and painful for them. 00;08;56;23 - 00;09;18;03 Unknown Only 5 to 10 sometimes, yeah, to get initial signal. The critical part, though, is to focus on the problem first. Don't go in pitching your solution right away. Ask about their current challenges, how they coach. Now, understand their world, then maybe gauge their reaction to a potential solution. You learn so much more that way. I've heard about something called guerilla user testing. 00;09;18;05 - 00;09;39;06 Unknown What's that about? It sounds kind of fun. It is kind of fun. It's exactly what it sounds like. You literally go to places where your potential users might naturally hang out. You know, cafes, parks, maybe college campuses. And you simply ask people for a few minutes of their time. You might offer a small incentive, like a $5 coffee gift card, or even just like a box of cookies. 00;09;39;06 - 00;10;01;11 Unknown Keep it cheap. Keep it cheap. Offer it for five minutes of their candid feedback on maybe a concept, or a sketch, or a simple prototype. One UX researcher I write about shared that they conducted dozens and dozens of user interviews and spent less than $100 in total. Using these kinds of scrappy tactics. Wow, that's incredibly resourceful. So it's not always about these big, formal, expensive studies then? 00;10;01;15 - 00;10;21;24 Unknown Not at all. Especially early on. You can also leverage your personal networks carefully. You have to watch for bias, but maybe starting with friends of friends or posting in relevant online communities. There's also the snowball recruiting method, where after you interview someone, you ask them, hey, do you know anyone else who faces similar challenges? That can be super effective. 00;10;21;27 - 00;10;44;14 Unknown Build momentum. Exactly. And even simpler things like remote surveys or basic landing pages can gauge interest. Set up a simple page describing the value prop. Collect emails for a beta. Sign up or run tiny social media ad campaigns testing different messages for just a few dollars a day. See what resonates. See what resonates. If nobody clicks, that's a pretty strong signal, right? 00;10;44;15 - 00;11;06;20 Unknown A red flag. If lots of people sign up, you've got some early validation. Okay. And what about even before you write a single line of code, can you actually test a product concept though? Absolutely. That's where prototype testing is gold. You can create rapid, low fidelity prototypes using tools like Figma, balsamic, or honestly, even just paper sketches, then paper, pen and paper. 00;11;06;22 - 00;11;31;02 Unknown Research by Jacob Nielsen, a usability guru, famously found that testing with just five users can uncover around 85% of the core usability problems in a design. Only five users for 85%. That's efficient. Incredibly efficient. It's dramatically cheaper to iterate on a paper mock up based on feedback from five people, than it is to refactor a fully built product after months of coding. 00;11;31;06 - 00;12;04;07 Unknown This sounds incredibly aligned with, what Chris Mullins, the principal product designer, was talking about recently on that feedback loop podcast. Oh yeah. Definitely. He was explicitly mentioning these very approaches. Wasn't he a sort of a roadmap for teams navigating that early stage when they don't even have a defined audience yet? He was. Yeah, absolutely. Spot on. In their deep dive from April 19th, 2025, the one titled Human Centered Design A Startup's Guide to Product Design, Chris Mullins and the team really emphasize that startups must prioritize UX design right from the beginning, from day one, from day one. 00;12;04;09 - 00;12;26;18 Unknown They highlighted how approaches like, you know, design sprints, creating proto personas, doing those crucial problem interviews. These are absolutely essential tools. Mullins specifically noted that these methods deliver a clear roadmap for teams kind of lost in the fog of early stage development. I cut through the fog, helped them stop guessing, and actually start discovering. It perfectly aligns with this idea. 00;12;26;18 - 00;12;46;03 Unknown We're talking about the ability to recruit even a handful of representative users for these kinds of studies. That itself is maybe the first test of whether a startup will be viable. That's a really powerful point. If you can't find people willing to talk about the problem for free, how on earth are you going to find people to pay you to solve it later? 00;12;46;04 - 00;13;07;06 Unknown It's a fundamental check. So user research isn't just about discovery, it's a viability test in its own right. Which leads us nicely into UX design and this whole idea of human centered iteration. It's not enough just to build the right thing. You also have to design it the right way. Precisely. And that's where human centered design, or HCD comes in. 00;13;07;09 - 00;13;33;12 Unknown It's all about involving users continuously throughout the design cycle. You empathize with them, define the problem from their perspective. Ideate potential solutions, prototype those solutions, test them with users, and then you repeat, lather, rinse, repeat. Exactly. This ensures the product's usability and usefulness are validated step by step, rather than just guessing what users want. Or maybe worse, just building what's technically easiest for the engineers. 00;13;33;13 - 00;13;58;07 Unknown And one of the most popular frameworks for doing this, especially for getting quick validation, is the design sprint, right? The one pioneered at Google Ventures. The design sprint. Yeah, it's brilliant. It condenses these key elements of design thinking into a really focused five day process. You map out the problem, sketch potential solutions, decide on the best approach, build a realistic prototype, and then test it with real users all in one week, one week to get answers. 00;13;58;08 - 00;14;22;27 Unknown The benefit is just immense. As Jake Knapp, its creator, puts it, it's far better to receive bad news after five days than after launching a fully built product after 612 months of work. Yeah, that makes total sense. Sail fast, learn fast. Exactly. If the test reveals users don't understand it or don't need the solution, the team just saved potentially months, maybe years of time and a lot of money. 00;14;22;29 - 00;14;47;29 Unknown If it goes well, they can proceed with so much more confidence knowing they're actually on the right track. And this idea of continuous iteration, it isn't just for these dedicated sprints, right. It applies more broadly. Oh, absolutely. It includes things like frequent smaller scale usability testing as you build maybe AB testing for fine tuning specific features or flows later on, and even techniques like Wizard of Oz prototyping, Wizard of Oz. 00;14;48;00 - 00;15;07;20 Unknown What's that? That's where you sort of fake complex features behind the scenes, often with human effort just to test the demand and the user experience before you invest in building out the complex back end technology. You pretend the magic is there to see if people want it. Clever. Like the Zappos example? Almost kind of. Yeah. And think back to Instagram again. 00;15;07;22 - 00;15;39;15 Unknown Its success wasn't just the pivot. It was also partly due to simplifying the UX around those core needs, sharing photos, removing the extraneous stuff, polishing the flow, and adding those filters people clearly desired based on early feedback, right? Focusing the experience. Conversely, think about failures. Consider early Google wave. It was incredibly innovative, technically brilliant, real time collaboration. I remember the hype around wave huge hype, but it failed, partly because users just found it confusing and overwhelming. 00;15;39;15 - 00;16;01;29 Unknown It didn't match their mental models. So even brilliant engineering can flop without a clear understanding of user needs, user behaviors, and just plain usability. Yeah, iterative design with constant user input highlights these UX issues when they're still cheap and easy to fix before they cause mass abandonment. It's about catching those problems early. That's a crucial point. Okay, let's shift gears slightly and unpack this next big concept. 00;16;02;01 - 00;16;25;03 Unknown The Opportunity solution tree sounds a bit academic. Maybe it can sound that way, but it's actually a remarkably practical and systematic way for product teams to approach discovery and make sure they're working on the right things. Okay, tell us more. How does it work? It is. Teresa Torres developed this, and it's essentially a powerful visual aid. It helps teams make their thinking explicit, transparent and systematic. 00;16;25;05 - 00;16;44;17 Unknown And it helps overcome some surprisingly common pitfalls in how teams think about products. What kind of pitfalls are we talking about here? Like what goes wrong usually? Well, first it addresses the issue of not examining ideas deeply enough. The tree structure forces you to ask why an idea is worth building. How does it connect to a real user? 00;16;44;17 - 00;17;13;07 Unknown Need or opportunity? Not just what shiny new feature to build. Okay. Connects ideas to purpose. Exactly. Second, it combats the problem of not considering enough ideas. It naturally encourages multi tracking. Exploring multiple potential solutions for the same underlying user problem or opportunity. Avoids falling in love with the first idea. Precisely. Third, it helps you multi-track systematically. You end up comparing solutions that all ladder up to the same opportunity. 00;17;13;09 - 00;17;41;22 Unknown This avoids those frustrating debates where you're comparing apples and oranges because the proposed solutions are aimed at totally different problem. Keeps the comparison fair. Right. And finally, maybe most importantly, it prevents what Torres calls orphan solutions, building things that don't genuinely connect back to any real user problem or desired business outcome. Like, you infamous overengineered juicer, which we should probably talk about later as a cautionary tale. 00;17;41;23 - 00;18;01;19 Unknown Okay. Yeah. Let's circle back to you, Sara. So how do you actually build this tree? What are the components? It has four core sections, kind of layered. It starts at the top with a clear desired outcome. This is usually a single measurable goal, often pulled directly from your team's OKRs. Objectives and key results. Something like increase user engagement or reduce churn. 00;18;01;21 - 00;18;23;27 Unknown Got it. The main goal. Below that are opportunities. These should emerge directly from your generative user research. Interviews. Observations. They reflect how customers frame their problems or needs in their own words. Not your interpretation, but theirs. Things like I need a faster way to find relevant documents, or I struggle to collaborate effectively with my remote team. Okay. The user's voice. 00;18;23;28 - 00;18;52;05 Unknown Then under each opportunity come the solutions. These are specific ideas or features that could potentially address that specific opportunity. Ideas can come from anywhere. Brainstorming, user suggestions competitive analysis. But they must connect clearly back to an opportunity on the tree. Make sense? Link solution to problem. And finally, at the bottom under each promising solution are the experiments. These are not about testing the whole solution at once, like a big AB test. 00;18;52;07 - 00;19;18;20 Unknown They're designed to test the riskiest assumptions underlying why you think that solution will work. The riskiest assumptions. Yeah. Like do users actually value this benefit enough or can we technically build this part feasibly? These experiments should be fast and cheap. Things like concierge tests where you manually provide the service to gauge demand. Or those fake door tests we mentioned where you put up a button for a feature that doesn't exist yet, just to see how many people click it. 00;19;18;25 - 00;19;42;21 Unknown It sounds like a very dynamic, ongoing process, not something you just like. Build once and you're done. Oh, absolutely. It's all about continuous discovery. Teams should constantly be discovering new opportunities through research, generating new solutions, and running experiments. You're balancing horizontal exploration, looking across different opportunities and solutions with vertical depth, really testing the assumptions behind the most promising paths. 00;19;42;23 - 00;20;09;03 Unknown It ensures discovery genuinely informs effective delivery. It keeps you grounded in reality. Exactly. It's not linear. It's this dynamic, ongoing process that helps product teams stay aligned with customer needs and business goals. Okay, so ultimately all this effort, the upfront validation, the human centered design using frameworks like the opportunity solution tree. It isn't just about, you know, good product development practice. 00;20;09;06 - 00;20;29;01 Unknown It has a direct long term impact on core business outcomes right. Absolutely. There's a clear ripple effect. What does that look like. How does it pay off. Well first you get incredibly efficient growth and marketing products that achieve strong product market fit. They tend to grow organically. Users love them. Tell their friends. Think about slack in its early days. 00;20;29;02 - 00;20;50;27 Unknown Yeah, it's spread like wildfire. Exactly. This leads to much better conversion rates and significantly lower customer acquisition costs. Without that fit, you're constantly pushing a boulder uphill with sales and marketing. Or maybe worse, you're pouring marketing money into a leaky bucket where users sign up but don't stick around. Right. Retention. That's the next one, isn't it? It is improved user retention and loyalty. 00;20;51;00 - 00;21;14;29 Unknown Products that are genuinely shaped by real user needs that solve real problems while they keep users engaged. People stick around longer, leading to a much higher lifetime value for LTV, which investors love to see. Oh, investors absolutely look for strong cohort retention metrics. It's one of the clearest signals that you've actually found product market fit. If you're solving a genuine persistent problem well users stay. 00;21;14;29 - 00;21;41;17 Unknown They often become advocates. They refer others. It's a powerful cycle. And the big one, maybe the most obvious one. Yeah. Just saving time and money. Huge upfront validation. Doing these experiments, it's basically the ultimate insurance policy on your development budget. Good way to put it. It's dramatically cheaper to test an idea with a prototype, or build a quick MVP than it is to hire a full development team for six months or a year, building a product that ultimately flops. 00;21;41;19 - 00;22;03;02 Unknown Remember that Dropbox explainer video MVP? Yeah, the three minute video. That simple video de-risked potentially millions of dollars in engineering effort for basically the cost of a few weeks of video production. That's maximizing your ROI right there. Avoiding blood, sweat, tears, and a lot of cash down the drain, as one source put it. But when that validation doesn't happen. 00;22;03;04 - 00;22;33;28 Unknown Well, we see some pretty spectacular failures, don't we? We certainly do. And they serve as important cautionary tales. Take Quibi, for example. Aguirre, right. They raised an absolutely astounding $1.75 billion, built some really innovative mobile video technology. But they failed spectacularly in just six months. What went wrong there? It wasn't the tech, not primarily the tech. Their demise really stemmed from fundamental strategic errors, a failure to understand the market need. 00;22;34;00 - 00;22;55;25 Unknown They misread the market context, launching this mobile only short form content platform. Right when a global pandemic hit and everyone was suddenly stuck at home with big screens not commuting. Terrible timing. Awful timing. And they also seemed to overbuild features like their turnstyle tech for switching between portrait and landscape. That users simply didn't value enough to pay for or stick around for. 00;22;55;28 - 00;23;23;24 Unknown It's become this classic cautionary tale for overfunded startups that maybe jump into execution without really nailing product market fit first. And then there's the other infamous one you mentioned, dude Usoro, a truly notorious flop. They spent something like $120 million developing this super high end Wi-Fi connected juicer, a Wi-Fi juicer. Yep, costs $699, essentially. And it only worked with their proprietary juice packs, which cost 5 to $8 each in six years. 00;23;23;25 - 00;23;53;14 Unknown Very expensive juice. It failed spectacularly, fundamentally, because it solved no real customer pain point. The killer blow came when users discovered and Bloomberg reported, that you could simply squeeze the juice packets by hand and get basically the same result, rendering the $700 machine utterly pointless. Ouch. Ouch. It perfectly illustrates that without solving a real problem that people care about at a price point that makes sense, your product will fail, no matter how technically sophisticated or well-funded it is. 00;23;53;16 - 00;24;31;27 Unknown A little bit of early user insight or even just a simple price sensitivity test, could have potentially saved them hundreds of millions in wasted investment. So beyond just the money saved or the revenue generated, there's another big benefit here, isn't there? In terms of confidence, you're absolutely right. It significantly impacts both team and investor confidence. Taking a data driven approach, being able to show validated demand, maybe you can say, look, we have 100 trial users who absolutely loved the prototype, or we got a thousand signups from this cheap $50 ad campaign testing our core value proposition that dramatically improves your fundraising prospects shows you've de-risked it somewhat exactly a de-risk the venture in the eyes 00;24;31;27 - 00;24;59;03 Unknown of investors, and internally it helps reduce those endless debates that are just based on opinions, or who shouts loudest. You have actual data pointing the way. So the new success formula in software today, it really isn't just about technical execution anymore. That's table stakes. What is it then? It's this powerful combination you need product strategy, excellence multiplied by deep market understanding, multiplied by great user experience design, with technical execution serving as the crucial enabler. 00;24;59;10 - 00;25;22;28 Unknown Technical capability is obviously necessary, but it acts more like a multiplier for your strategic and user centric capabilities. That's a great way to frame it. So let's try and recap our deep dive today. The core message seems pretty clear in this age. We're building software is faster and easier than ever. The real differentiator between success and failure isn't just speed anymore, it's direction. 00;25;23;04 - 00;25;47;22 Unknown Precisely. Are you building something meaningful, something that users genuinely want and need? The ease of building has actually, paradoxically, raised the stakes now. So because it means teams have to be more disciplined. They have to force themselves to validate early, iterate often based on feedback and stay laser focused on solving the right problems for the right people. Frameworks like Lean Startup give you a clear roadmap for this form. 00;25;47;22 - 00;26;11;03 Unknown Hypotheses build the smallest possible thing to test them. Measure real user responses, and learn from that data. And those practical techniques we talked about things like design sprints, doing those user interviews, even guerrilla style rapid prototyping with simple tools. They integrate these principles right into the daily practice of product teams. Exactly. They allow teams to gather crucial feedback in days or weeks, not months or years. 00;26;11;05 - 00;26;37;24 Unknown And that feedback then guides the product strategy. It informs user centric design choices and ultimately it drives those favorable business outcomes. We discussed growth, retention, revenue, investor confidence. The core lesson really is crystal clear. The sooner you discover the truth about your idea, the better off you are. It's just far, far cheaper to adjust your course after a one week experiment, then after sinking a year of development into the wrong product. 00;26;37;25 - 00;26;59;23 Unknown Couldn't agree more and we highlighted that statistic early on. Lack of market need is still the number one startup killer. But the good news is we now have the tools and the frameworks like design sprints, like problem interviews, like the opportunity solution tree to actively manage and minimize that uncertainty. We don't have to fly blind anymore. Okay, so here's a final provocative thought for you, our listener, to chew on. 00;26;59;25 - 00;27;33;13 Unknown If the most valuable resource in tech today isn't necessarily raw technical capability, but rather that deep understanding of customer problems coupled with effective product strategies to solve them. What single assumption about your current project, or maybe your next big idea are you most afraid to actually test? That's a tough question to ask yourself. It is. And following on from that, what's the smallest, cheapest bullet experiment like those Zappos photos or the Dropbox video that you could realistically fire off next week to start getting a real answer? 00;27;33;16 - 00;27;48;25 Unknown Think about it. The future really belongs to those who consistently ask, not just can we build it, but more importantly, should we build it? And how can we find out fast? Excellent point to end on. Thanks for diving deep with us today. My pleasure. We'll catch you next time on the deep dive.