Building the right thing

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 cheaper to build software. Think about it. Cloud platforms, open source libraries, these no-code tools, even AI coding assistants, the barriers have just sort of melted away. Yeah, they really have. You can go from just a glimmer of an idea to working software in what feels like 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. The real challenge, the thing we need to focus on, is ensuring your product genuinely solves a problem and deeply resonates with users. That, 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 seek out. 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. 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, 50%, 90%. There's even a projection that 80% of technology products will be built by non-developers by 2024. Wow, 80%. That's huge. 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. 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. 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. 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 pay for? That reframes everything, doesn't it? The focus has completely shifted. Completely. 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. Not 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. OK, 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. 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. 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. 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. When a customer ordered a pair, he'd literally go buy it from the store at full price and then ship it directly himself. Wow, that's scrappy. Totally scrappy. But this sell-first, supply-on-demand MVP validated the core assumption. People were actually willing to buy shoes online before he scaled up and eventually sold to Amazon for over a billion dollars. 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? 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 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, and that video just went viral. Their beta wait list jumped from 5,000 to 75,000 users practically overnight. Incredible. 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, 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 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. 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. That's a great illustration of what Jim Collins calls firing bullets, then cannonballs. Right. I love that metaphor. You start with these low-cost, low-risk experiments, 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. 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. 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. OK, but what if you're 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 breaking the bank? Ah, that's where these cost-effective techniques really shine. You'd be surprised. Even just, say, 5 to 10 focused 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. 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 cope 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 guerrilla user testing. What's that about? 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 a box of cookies. 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 read 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. 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. 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? A red flag. If lots of people sign up, you've got some early validation. OK, and what about even before you write a single line of code? Can you actually test a product concept then? Absolutely. That's where prototype testing is gold. You can create rapid, low-fidelity prototypes using tools like Figma, Balsamiq, or honestly, even just paper sketches. Pen and paper. Pen and paper. 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. 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. 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, as 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 19, 2025, the one titled Human-Centered Design. A Startup's Guide to Product Design, Chris Mullins and the team really emphasized that startups must prioritize UX design right from the beginning. From day one. From day one. They highlighted how approaches like 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. Right, cut through the fog. Help them stop guessing and actually start discovering. It perfectly aligns with this idea 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? 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. 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. 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. 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 six, 12 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. 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 A-B testing for fine-tuning specific features or flows later on, and even techniques like Wizard of Oz prototyping. Wizard of Oz, 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. Ah, clever. Like the Zappos example, almost. Kind of, yeah. And think back to Instagram again. 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. 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. 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, 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. 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 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 multitracking, 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 multitrack systematically. You end up comparing solutions that all ladder up to the same opportunity. This avoids those frustrating debates where you're comparing apples and oranges because the proposed solutions are aimed at totally different problems. Ah, keeps the comparison fair. Right. And finally, maybe most importantly, it prevents what Torres calls orphaned solutions, building things that don't genuinely connect back to any real user problem or desired business outcome. Juicero's infamous over-engineered juicer, which we should probably talk about later as a cautionary tale. Okay, yeah, let's circle back to Juicero. 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. 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. 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. Makes 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 A-B test. 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. 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. 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 good product development practice. 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 in 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. Yeah, it's spread like wildfire. 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. 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, or 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, they often become advocates, they refer others. It's a powerful cycle. And the big one, maybe the most obvious one, 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. 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, well, we see some pretty spectacular failures, don't we? We certainly do. And they serve as important cautionary tales. Take Quibi, for example. Oh, Quibi. 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. 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 turnstile tech for switching between portrait and landscape that users simply didn't value enough to pay for or stick around for. 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, Juicero. Ah, Juicero. 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, ishally. And it only worked with their proprietary juice packs, which cost $5 to $8 each. Expansive juice. 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 packs by hand and get basically the same result, rendering the $700 machine utterly pointless. Ouch. Big 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. 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 love the prototype, or we got 1,000 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. It de-risks the venture in the eyes 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. 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 where building software is faster and easier than ever, the real differentiator between success and failure isn't just speed anymore, it's direction. Precisely. Are you building something meaningful, something that users genuinely want and need? The ease of building has actually, paradoxically, raised the stakes. 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 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 Gorilla-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. 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 than after sinking a year of development into the wrong product. 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. 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? Hmm, 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? 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.