00;00;00;00 - 00;00;23;26 Unknown Welcome to the Deep Dive, where we take a stack of information and extract the most important nuggets to help you get well informed quickly. Today, we're plunging into a scenario that, honestly sounds like a product team's worst nightmare trying to build a new B2B product. When you don't have a clear target customer, your audience feels, well, vague, and there are no active users for testing, just feedback filtering in from sales pitches. 00;00;23;26 - 00;00;43;15 Unknown Yeah, it's a surprisingly common challenge. You see a lot, especially in early stage B2B and source. So many UX teams report struggling, really struggling to get access to real users, you know, client restrictions, recruitment hurdles. But and this is the key thing we'll unpack today ignoring or rushing the discovery phase here. That's one of the riskiest moves you can possibly make. 00;00;43;18 - 00;01;12;11 Unknown Absolutely. So for this deep dive, our mission is, pretty clear. We want to equip you with a roadmap to navigate this. This profound uncertainty. We'll explore expert strategies for doing discovery that's rapid, cost effective, how to innovate even when feedback is really limited, and, crucially, how to mitigate those inherent risks when direct user input is scarce. Think of it as like a guide, turning that foggy start into a crystal clear, focused strategy. 00;01;12;18 - 00;01;32;01 Unknown Okay, let's unpack one of the most painful patterns we see. It just repeats itself in product development team spending months easily tens of thousands of dollars building the wrong thing. And it's rarely about poor execution, right? It's about building on assumptions instead of building on actual traction. It's true. And what's so incredibly seductive about assumptions is, well, they feel efficient, don't they? 00;01;32;02 - 00;01;54;26 Unknown You can make educated guesses, skip the messy part of finding real users. Maybe jump straight to high fidelity mock ups. Feels fast, but our sources are really emphatic on this. Betting on those internal theories about user behavior. It is the most expensive foundation you can pour. It almost always fails. And here's a critical nuance, especially for anyone. And, you know, sales driven organizations, that feedback you get from executives during sales pitches. 00;01;54;26 - 00;02;21;18 Unknown Yes, it's absolutely vital for closing deals, we get that. But it's often wildly inappropriate for informing the actual design decisions. The person signing the contract, they're typically not the daily user. Are they their priorities filtered through budgets, competition, maybe internal politics, not the nitty gritty of user experience needs. That's such a crucial distinction. Yeah, and it really begs the question if assumption driven development is basically a gamble, what's the alternative? 00;02;21;20 - 00;02;45;04 Unknown Well, it's insisting on gaining real traction, like tangible evidence with specific users before you commit to those major development cycles. And traction doesn't mean you need a finished product. Not at all. It can just be conversations. Early prototypes, even simple landing pages can work. The key is gaining what some call ground truth. You know, those undeniable real world insights from the people actually living with the problem you're trying to solve. 00;02;45;07 - 00;03;11;06 Unknown Because real users, they reveal pain points, use cases, requirements you just couldn't have conjured up on a whiteboard. Okay, so if sidestepping assumptions is our North star, why is discovery so paramount? Especially when it feels like you're just building in the dark? Why can't we just guess and go? Well, our sources show pretty clearly that having a dedicated discovery phase, even a lean one, can slash the risk of project failure by up to 75%. 00;03;11;08 - 00;03;39;12 Unknown Think of it like an insurance policy for your entire product launch. Seriously, it frames the problem correctly. It ensures the team against building the wrong thing, skipping it. That often means you're just, timidly exploring already for your corners of the design spaces. One source put it you completely miss those critical unmet user needs. And the striking insight here, I think, is that teams who genuinely invest in discovery, they gain something really powerful, what some sources actually call a secret weapon for sustained competitive advantage. 00;03;39;19 - 00;04;04;00 Unknown It's not just about avoiding that costly mistake of building something nobody wants. No, it's about uncovering unique insights that others completely overlook. That's your competitive edge. All right. So you're convinced discovery is crucial. You get the immense value, but you don't have those direct active users. Now what what do you actually do? The good news is our sources offer concrete, lean and, remark cost effective methods. 00;04;04;00 - 00;04;25;17 Unknown Yeah. The core principle here really boils down to scaling discovery down way down to its absolute essentials. Focus narrowly like laser focus on the most specific and valuable activities. You're not trying to answer every single question at once. You're targeting key questions and, verifying your most probable assumptions. The riskiest ones first. Okay, so this means things like design sprints. 00;04;25;17 - 00;04;52;11 Unknown You've probably heard of these. Think of it as a hyper focused five day pressure cooker comes from Google Ventures small cross-functional team goes from mapping a problem all the way to testing a prototype in five days. It forces rapid decisions, validates or invalidates assumptions. Lightning fast, keeps costs incredibly low, and you can even use proxy audiences, right? Like friendly clients or even internal staff who kind of mirror your target users. 00;04;52;13 - 00;05;15;08 Unknown Exactly. Or consider rapid prototyping and testing. Create low fidelity prototypes. Doesn't have to be fancy mockups, clickable demos, even paper sketches, and then put them in front of any available eyes. Seriously, anyone? If real user testing is just impossible, have team members or maybe industry colleagues do qualitative walkthroughs, ask them to think aloud. And importantly, like you said, analyze as much user data as you can from existing sources. 00;05;15;14 - 00;05;35;11 Unknown Sales hall support tickets, maybe prior usage analytics if you have any. These tell you what is happening, even if they don't tell you why. The mantra is really simple build small, test early, learn fast. We also heard about something called time boxed research spikes. In agile terms, this basically means allocating short dedicated discovery sprints, maybe just one week. 00;05;35;13 - 00;05;56;17 Unknown Use that week to interview a few potential customers or survey the market landscape. It forces prioritization. It helps you answer maybe the top 2 or 3 unknowns in that week, rather than leaving all your assumptions untested until it's too late and too costly, and to keep it truly lean. Absolutely leverage existing knowledge. Become a UX detective, as one source called it. 00;05;56;17 - 00;06;17;09 Unknown Dig around. Review prior studies, market research reports, customer support logs, anything you can get your hands on now. Crucially, talk to your own frontline employees, your salespeople, your support reps, your trainers. They are an absolute gold line of anecdotal evidence on customer pain points and those clever workarounds people invent. They live and breathe this stuff daily. And finally, this is a big one. 00;06;17;15 - 00;06;39;27 Unknown Avoid over analysis your aim here is actionable findings, right? Not some perfect academic report, a simple one page summary, maybe a few key metrics. That's often more than enough to make the next decision. The goal is always to gather the critical information needed to deliver value and lower risk as soon as possible. That's the quote every discovery activity has to earn its keep. 00;06;39;29 - 00;06;58;06 Unknown If it's not tied directly to a burning question, maybe save it for later. As one principle goes, we're building to learn and learning as we build. I like that, okay, so let's say your initial target customer. They fall through, or maybe they just feel like it goes totally undefined. A top priority then has to be refining who your product is actually for. 00;06;58;06 - 00;07;19;29 Unknown Yeah. How do you do that systematically, especially when direct user input is so hard to come by? Right. Steve Blank, who's, you know, GI in the startup world, he constantly emphasizes this. The goal isn't to please everyone. It can't be. It's to figure out what specific customer segment truly makes sense for your product. You need to identify a niche where your product can genuinely shine, not just be kind of okay for a broad audience. 00;07;20;02 - 00;07;46;23 Unknown And that's where proto personas can be really useful. Imagine you're drawing a quick sketch like a profile of your ideal customer, but it's not based on extensive surveys yet. It's based on your team's existing knowledge and importantly, your collective assumptions. That's a proto persona. They force those implicit, maybe unspoken assumptions out into the open, gets the entire team aligned on a concrete hypothesis for your target audience. 00;07;46;25 - 00;08;07;07 Unknown Think of it as a straw man target user, someone to design for now, who you'll then validate and refine later on. Exactly. And another powerful tool here is focusing on jobs to be done in problem statements. So instead of asking what features do they want, you ask different questions. Ask what core job is our product hired to do or maybe who desperately needs that job done? 00;08;07;07 - 00;08;27;26 Unknown And why can't they do it effectively right now? A really crisp problem statement helps something like we help this specific type of person accomplish this specific goal. Despite this specific obstacle that can powerfully reveal your true target audience. Customer development interviews are also key, aren't they? Even if you can't do usability tests on a prototype, you can absolutely do problem interviews. 00;08;27;26 - 00;08;50;20 Unknown Identify potential target companies, maybe in different segments you're considering. You might even have to cold call them or use LinkedIn. Conduct short conversations. And the key the absolute key is to listen, not pitch. Listen about their pain points, their current solutions, even if they're just spreadsheets or sticky notes, and maybe get a sense of their budget. You can even try rating the problem pain level they express. 00;08;50;20 - 00;09;16;14 Unknown Look for patterns, find where the fire is hottest. Definitely. And if you have any existing data, even scraps, leveraged data driven segmentation. Analyze who's signing up for waitlists if you have one. Which types of companies are responding positively to sales pitches? Even just looking at your website, traffic profiles can offer clues. Any analytics really can provide hints about surprising segments that might be interested, or they might confirm the hypotheses you already have. 00;09;16;17 - 00;09;40;17 Unknown Ultimately, finding the right target audience is always a balance, isn't it, between genuine user need and real market viability? Can you actually build a business around it? Okay, moving beyond is building a functional product. Early design as you mentioned, is fundamentally about creating unique intellectual property IP. How does this kind of focus discovery process, even with limited users, how does it contribute to building that valuable IP? 00;09;40;17 - 00;10;13;03 Unknown Well, a robust discovery process, even a lean one. It often uncovers those latent user needs. You know, the problems people have that they maybe can't even articulate yet. The things no one else is really addressing properly. By finding and solving those, you create something truly innovative, something protectable. Skipping discovery is our sources warn again and again. It leads to me to products just copying competitors or timidly exploring familiar corners, missing those crucial whitespace opportunities, opportunities that could become truly proprietary solutions. 00;10;13;03 - 00;10;33;22 Unknown Right? The source literally says teams that invest in discovery possess a secret weapon for sustained competitive advantage. And that advantage is your valuable IP. Whether it's a novel feature, maybe a specialized algorithm you develop, or a truly unique user experience flow. It's not just what you build, but how you uniquely solve that specific problem. For that specific audience. 00;10;33;25 - 00;10;59;14 Unknown Exactly. And to maximize this IP, you have to document insights and ideas rigorously. Treat them like intellectual assets from day one, because even if a particular product idea fails, the underlying research may be user work flow data you gathered or technical prototypes that didn't quite pan out. That can still be incredibly valuable IP for future projects. You should also be actively trying to intersect user needs with tech possibilities. 00;10;59;16 - 00;11;23;14 Unknown Think of ideas. Famous triad what people need, desirability, what technology makes possible feasibility, and what the business requires to be viable viability. That intersection. That's where novel IP truly emerges. This raises a really interesting point about failure. You need to embrace smart failure, a culture that views experiments not as pass fail, but as learning opportunities is just far more likely to produce innovative outcomes. 00;11;23;14 - 00;11;47;15 Unknown It makes sense. So run bold experiments. Try maybe outlandish concepts in low fidelity prototypes. Test unconventional value propositions. Each failure teaches you something unique and that unique learning is proprietary. It's about failing fast, but extracting the IP from every single attempt, learning from it. Couldn't agree more. And as you identify these novel solutions, make sure you think about how to protect and differentiate them. 00;11;47;17 - 00;12;11;19 Unknown This could mean filing a patent, of course, or copyrighting unique content or code, or maybe simply keeping a breakthrough method or process as a trade secret. Always be asking yourself, is this something only we could have come up with? Why? What makes this distinct? That's key to building defensible IP. Okay, this deep dive has made it really clear that human centered design HCD isn't just a checklist of activities. 00;12;11;19 - 00;12;30;24 Unknown It's a fundamental mindset shift. But what happens when you try to integrate this user first approach into existing agile programs? You know, programs that are already humming along, focus on delivery. Yeah, that's a common friction point. Our sources actually share a really compelling real world experience. It was from a large government agency. They were delivering features rapidly, lots of output. 00;12;31;01 - 00;12;54;18 Unknown But they noticed this growing gap, this chasm between what users actually wanted and needed and what they were actually getting. Their solution eventually was to deeply integrate HCD, which, you know, is essentially that combination of user research and thoughtful design, keeping the user's needs in sharp focus throughout the entire product lifecycle, not just upfront. What's fascinating, though, is that the initial integration was apparently incredibly difficult. 00;12;54;25 - 00;13;16;13 Unknown Agile teams already hyper focused on delivery velocity. They often misunderstood design. They thought it was just about the look and feel, the visual layer. So when the experts came in asking questions like, okay, but how do you know that's what the end user actually wants? It's sometimes felt like, well, like an invasion or just unnecessary friction slowing things down. 00;13;16;16 - 00;13;41;29 Unknown And there was also a huge challenge in planning the HCD work wasn't there because it needs to happen ahead of development, which felt very anti agile to some of those delivery focused teams. That's the real conundrum, right? How do you fit research which is inherently uncertain into predictable sprints. The breakthrough they found came with a structural shift just placing individual HCD practitioners in silos on individual agile teams that simply wasn't effective. 00;13;42;02 - 00;14;08;06 Unknown They were isolated, often overwhelmed. The solution that worked was creating a shared services HCD team. This central team supported the HCD practitioners who were embedded within the agile teams. This live for more strategic planning across multiple projects. Things like collective user recruitment efforts became easier and crucially, it allowed for vital outreach through workshops in HCD one on one sessions that helped align everyone on common language, common goals, common expectations, and built bridges. 00;14;08;10 - 00;14;34;09 Unknown They also developed something called a research roadmap. I thought this was clever. Basically a visual representation of their HCD backlog planned research activities. This was a game changer because it helped teams plan those research activities just ahead of the related development work, a sort of rolling wave planning. It made priorities crystal clear, and it also allowed teams to see what other teams were learning, which fostered shared insights and collaboration. 00;14;34;09 - 00;14;56;23 Unknown Instead of everyone reinventing the wheel. Absolutely. But what truly stands out from this case study? The core lesson is that success ultimately hinged on a fundamental mindset change, a shift to what they called human centered agile. And this means having several key things in place. First, an engaged product owner who genuinely cares about user based outcomes, not just shipping features, that's critical. 00;14;57;00 - 00;15;29;09 Unknown Second, securing access to real users. This is just non-negotiable. No humans, no human centered design. Simple as that. Third, getting permission to fail fast, fostering that culture where experiments, even the ones that don't pan out, are seen as valuable. Learning, not mistakes. Fourth, using clear metrics tied directly to design success things like task completion rates, user satisfaction not just do we build the feature back finally, consistently allowing dedicated time for research before major feature delivery kicks off without protecting that time, it just won't happen reliably. 00;15;29;13 - 00;15;49;20 Unknown Okay, so building a new product with minimal direct user input is definitely a high wire act. We've established that, but we've discussed so many practical strategies to not just survive it, but actually thrive. So what does this all mean for you, the listener trying to make informed product decisions in this kind of challenging environment? How do you mitigate that risk? 00;15;49;28 - 00;16;08;13 Unknown Well, the first and honestly the most critical risk mitigation strategy is the simplest one. Do not skip discovery. Just don't. Our sources show time and again projects with even a modest discovery phase have dramatically higher success rates. Every single insight you gather, no matter how small, it's like taking out an insurance policy against building the completely wrong thing. 00;16;08;16 - 00;16;31;21 Unknown You should also absolutely build iteratively, use MVP's minimum viable products and incremental releases. Get something small out there. Measure the reaction even if it's just internal or with a few friendly customers, and then iterate based on that. Learning. This generates real, albeit maybe limited, feedback early on. It helps you catch those big red flags quickly and continuously de-risk your product as you go. 00;16;31;27 - 00;16;56;17 Unknown It's like test driving a car prototype before you commit to mass production, isn't it? Exactly. And another really shrewd strategy is feature throttling. So when sales comes asking for a new feature and they will look, you might build it just enough to demo well, make it look good for the pitch, but don't over invest in building a full polished, robust version until it's actually proven that users engage with it and find real value once it's in their hands. 00;16;56;19 - 00;17;30;01 Unknown This prevents that dreaded product bloat and keeps your focus tightly on delivering core, validated value. And you simply must, internally, at least constantly question and test assumptions. Map out your riskiest assumptions. Explicitly write them down which ones would kill the product if they were wrong, and then wherever possible, test them even via secondary means. If you can't get direct users, that could be running a small targeted ad campaign to gauge interest in a value proposition, or maybe having sales casually float a hypothetical scenario during a prospect call just to see their reaction get creative. 00;17;30;02 - 00;17;50;13 Unknown And when direct user feedback is truly absent, don't just throw your hands up. Use heuristics and best practices. Lean heavily on established usability principles. Things like Jacob Nielsen's ten heuristics for Usable interfaces. Their famous for a reason. These are battle tested guidelines. They can help you prevent obvious usability issues that real users would have caught in like five minutes. 00;17;50;20 - 00;18;19;14 Unknown Right? And finally, monitor proxy metrics. Even without active users clicking around, you can look at trends, trends and sales presentation, conversion rates, website traffic to specific feature pages or landing pages. Prospect engagement with early demos or prototypes. These can all hint at whether you're generally on the right track or heading for a cliff. Set up a simple dashboard of these surrogate measures, use them as early warning signals and most importantly, through all of this, stay incredibly agile and willing to pivot without ego. 00;18;19;19 - 00;18;57;24 Unknown When new evidence comes in, you have to be ready to change course. Okay, so this deep dive has really shown us that early stage product discovery in B2B, especially without those clear users, it is indeed a high wire act. It's tough, but it's emphatically not an excuse to just build blind and hope for the best. Absolutely not. By staying lean, by being rigorously user centered, even if users are proxies initially and by being relentlessly hypothesis driven, combining those creative research methods we talk about like design sprints, proto personas, problem interviews with a mindset of continuous learning and sharp risk awareness, you can make rapid progress. 00;18;57;26 - 00;19;20;13 Unknown You can find that elusive product market fit even in the fog. You absolutely can turn that foggy start into a focused, impactful strategy. And in doing so, you're generating valuable intellectual property and protecting your venture from those incredibly costly, sometimes fatal wrong turns. Remember every sales conversation, every observed workaround you hear about every assumption you explicitly chart and test. 00;19;20;15 - 00;19;38;11 Unknown It's all a crucial piece of the puzzle you're solving. So what does this all mean for you navigating these challenges in your own work? Maybe right now, consider this question what is one small, inexpensive experiment you could realistically run this week? Just one experiment to test your single riskiest assumption about a user need, or maybe a market opportunity you're pursuing. 00;19;38;14 - 00;19;54;21 Unknown Remember, it's all about illuminating what you don't know, making the implicit, explicit, and validating your critical assumptions before precious time and effort are wasted. Building the wrong things for the wrong people. Until next time. Keep learning, keep discovering, and keep building with confidence.