How to Validate Problems Before Solutions

Teams often implement solutions that do not fix the problem they were trying to address. That's because the issue wasn’t framed correctly in the first place. This is especially true in complex or unfamiliar situations, where quick conclusions feel comforting but are often wrong. When I work with teams on decision-making, I turn to a framework developed by Julia Binder and Michael Watkins. Their E5 approach helps leaders define the right problem before trying to solve it. Phase 1: EXPAND Suspend early judgments and deliberately broaden how the challenge is understood. By exploring multiple interpretations of the issue, teams uncover hidden assumptions, surface blind spots, and create the conditions for more original thinking before jumping to answers. Phase 2: EXAMINE Shift from scope to depth. Teams analyze the problem rigorously, moving beyond visible symptoms to identify behavioral patterns, structural drivers, and underlying beliefs that reveal what is truly at play. Phase 3: EMPATHIZE Center on the perspectives of those most affected by the issue. Through (real) listening and reflection, teams gain insight into stakeholders’ motivations, emotions, concerns, and behaviors, often uncovering needs that data alone cannot reveal. Phase 4: ELEVATE Step back to see how it fits within the broader organization. Viewing the challenge through lenses such as structure, people, power, and culture exposes interdependencies and systemic tensions that shape outcomes. Phase 5: ENVISION Articulate a clear future state and map a path to reach it. Working backward from a shared definition of success, teams prioritize initiatives, sequence efforts, and align resources to move from understanding to execution. I've found that when leaders take the time to frame problems well, they increase the likelihood that those solutions will actually matter. #decisionMaking #leadership #perspective #learning #problems Source: The model is described in more details in this Harvard Business Review article: https://lnkd.in/gAeBb5uT

Problemeering: Engineering the Problem Before the Solution What is it? Problemeering (problem + engineering) is the art and science of identifying, defining, and framing problems so they can be solved more creatively and efficiently. Why it matters Many product launches, business strategies, and even personal projects flop because they target the wrong problem or never define one at all. Problemeering helps you: • Understand the real issue • Avoid premature “band‑aid” fixes • Uncover root causes and hidden opportunities • Frame challenges in a way that sparks breakthrough ideas Key steps Observe & Empathize – Listen to users and spot pain points. Define – State the core problem in one crisp sentence. Reframe – Challenge every assumption: “Is this really the problem?” Explore Context – Map the ecosystem, constraints, and stakeholders. Ask “How might we…?” – Turn the problem frame into innovation prompts. Quick example Late‑delivery complaints in a food‑delivery app. Instead of jumping straight to route optimization, a problemeering mindset asks: • Are customer expectations realistic? • Does the UI overpromise delivery times? • Are restaurants accepting orders they can’t fulfill? Addressing these upstream issues often fixes “late deliveries” more effectively than tweaking maps alone. Origin Not yet in the dictionary it just reminds us: engineer the problem first, then engineer the solution.

Most startups don’t fail because founders lack effort. They fail because they start with unvalidated assumptions. Research consistently shows that lack of market need is one of the top reasons startups collapse. The real advantage at the idea stage is not speed of building. It is precision of validation. Bootstrapping Playbook for Idea-stage Founders - At the center of this framework is a simple but disciplined approach: 1) Find Your Edge: What's your domain expertise? Your unfair advantage? Pinpoint a pain point only you can solve. 2) Validate Mercilessly: No code. No outsourced MVP. If the idea doesn't validate? Discard. Start over. 3) Learn from Success: Study structured Case Studies, not anecdotes. Absorb lessons. 4) Refine Your Thesis: Iterate with real customer feedback loops. Is this idea strong enough for a decade of your life? 5) Immerse in Customers: Talk to at least 50 Ideal Customers. Understand their world. 6) Nail Positioning: Refine your precise positioning based on customer feedback. 7) De-risk Your Market: Master Market Sizing and Competitive Analysis. Avoid walking into a noisy market blind, hoping for funding. This is not about inspiration. It is about eliminating false positives early. The Core Principle: Validate Before You Build - Idea-stage founders often confuse motion with progress. But the real sequence follows a clear order. First, you define your edge by clarifying why you are the right person to pursue this idea. Next, you talk to real customers rather than relying on friends or assumptions. You then run structured validation before building anything, without writing code or creating an MVP. After that, you eliminate weak ideas quickly based on what you learn. Finally, you strengthen only the ideas that survive evidence. If your idea cannot survive structured scrutiny, it should not survive into development. Come talk to me at a free mentoring roundtable and ask questions of the 1Mby1M AI Mentor: https://lnkd.in/g3VwPX_S

9 out of 10 student projects die because they solve problems nobody has. Your project might be one of them because you’re building something nobody needs. So before you waste weeks building the wrong thing… here’s how to validate your idea in 48 hours: 1. Use the "Explain it to Your Mom" Test If you can't explain your idea in one sentence to someone outside your field, it isn't clear yet. Try it with your mom, sibling, or a random friend. If they're confused, refine it. 2. Talk to 10 people who actually have this problem Not your friends. Real people with the actual pain point. Find them on Discord, Reddit, campus clubs. Ask how they solve this now and if they'd pay for something better. If they don't care so much, move on. 3. Fake a landing page for a product that doesn't exist Build a simple page explaining what your product does. Add a waitlist button. Post it in relevant communities. If 50+ people sign up in 48 hours without you begging them, that's your signal. 4. Offer to solve it manually This is the step most people skip. Before building anything, offer to do it by hand for free or cheap. If people won't let you solve it manually, they won't use your product either. When I built QuizBee, 500+ students had the same issue. That's why it worked. Most student builders jump straight into building something because it is fun. Validation isn’t fun - but it saves months of wasted work. If you're working on an idea right now, have you validated it - or are you just excited about building it? #builders #startups #founders #students

“The customer is always right.” Right? Well… yes. But not in the way you might think. In Customer Success, we hear this phrase all the time. And while I do believe the customer is always right, it’s not because we should say yes to every request or scramble to build every feature they mention. It’s because they’re right about the pain. They’re right about the friction, the gaps, the confusion. But they might not be right about the solution 😬 That’s where we come in. The magic happens when you go beyond the request and uncover the real problem. Because here’s the truth: Most feature requests are symptoms. Our job as CSMs is to diagnose the cause. Let’s say a customer says: “We need a new page on our dashboard” Now here’s the classic trap: CSM: “Sure! Let me request this for you. I’ll add it to the roadmap!” WRONG APPROACH! 🙅♀️ Here’s why: jumping straight to a solution without understanding the why behind the request leads to misaligned expectations and, most likely, frustration down the road. Instead, here’s a better approach - a simple 3-step process I use often: 1️⃣ Step 1: Validate the request... but don’t commit yet + hypothesize the underlying need The customer is raising something important. Acknowledge it, but leave room for discovery… after all, you suspect what they want isn’t a new page - they want easier access to a specific piece of data. So you need test that theory. CSM: “Thanks for surfacing this - if I sent you that data weekly, or gave you a shortcut to it, would that help for now? This serves three purposes: 1. Keeps the conversation open and shows you’re here to understand, not just execute 2. It gives them an immediate sense of support and momentum 3. Helps you figure out whether this is about UI structure or data accessibility 2️⃣ Step 2: Dig into the “why” Now that you’ve tested a quick fix, it’s time to zoom out. CSM: “What’s driving the need for that data? What decision or action depends on it?” This is where you uncover gold 🌟 The real issue might not be visibility - it could be workflow-related, team reporting pressure, or something else entirely. And that’s what you really need to solve. 3️⃣ Step 3: Collaborate on the right path forward Once you understand the root of the request, you’re in a much stronger position to propose a better solution or bring a well-informed case to your product team, if needed. —— Our job as CSMs is not just to collect feedback. It’s to interpret it. To ask follow-up questions. To uncover the why behind the what. One of my favorite lines from a recent post by Sagan Schultz, MD, MBA at Linear says it perfectly (link in comments): “The most valuable skill in product development lies in understanding what remains unsaid, beyond the explicit feedback.” The same applies to CS. Great relationships are built not by reacting to what’s said - but by listening closely enough to hear what isn’t.

I love how much enthusiasm and interest came from my last post on Jobs-to-Be-Done. But before diving into frameworks, I want to rewind and talk about some key fundamentals when it comes to customer discovery interviews. Because here’s what I’ve seen over and over again: Teams and founders get excited about an idea. They talk to people and show their prototype. People are kind and encouraging. And suddenly…it feels like validation. But polite nods and positive reactions aren’t actual validation. If you’re working on something new, your first job is to validate the problem, not the solution. And when you’re looking to validate the problem, here are some things to keep in mind: 1. Ask about the past Don’t ask people to imagine the future. Start with: “Tell me about the last time you …” That’s where the truth lives. When people are asked to predict the future, they’re often wrong. It’s Friday — did your week go exactly as you had predicted? 2. Avoid leading questions Skip the yes/no. Skip assumptions. People are often agreeable and may say “yes” — even when it’s not a real pain point. ❌ “Do you struggle with organizing student data?” ✅ “Walk me through how you organize student data today.” As they go through their story and you dig in, that's how you find the real struggle moments. 3. Dig into their story Don’t stick to a script. Get more context around the situation and follow the emotion. Bob Moesta calls it “following the energy” — when you hear a shift in tone or a moment that clearly mattered. Ask follow-ups like: “What happened next?” “Where were you? Who else was involved?” “What else have you tried?” That’s where the real insights live. 4. Look for signs of workarounds Spreadsheets, post-its, manual processes — all signs of friction. It’s in these struggle moments that valuable problems often appear. 5. Don’t pitch. Stay curious. Your mindset should be more like a journalist than a salesperson. You’re trying to understand, not convince. Be surprised. Be open to your assumptions being wrong. The Mom Test by Rob Fitzpatrick is a great getting started resource around this topic with even more tips. I’ll dive into JTBD frameworks soon, but this is the foundation that makes any customer discovery interviews more effective—especially when you’re building something new and innovative. Any others you’d add? #CustomerDiscovery #ProductDiscovery #JTBD #CustomerInterviews

The job of a PhD student is solving a set of difficult problems over several years. But here’s the part we often skip—validating the problem itself. In academia, we tend to validate our solutions, not our problems. Many projects start with: “Here’s what the literature says.” But real impact begins with a different question: “Is this a real problem worth spending years on?” There’s a quote often attributed to Einstein that captures the idea: “If I had an hour to solve a problem, I’d spend 55 minutes understanding the problem and 5 minutes on the solution.” To ensure that a research problem is real, relevant, valuable, and future-aligned before investing time in designing solutions, I ask PhD students to use a Problem Validation Framework comprised of the following stages: 1.      Reality Check – Is this a real problem? 2.      Worthiness Check – Is it worth investigating? 3.      Solvability Gate – Is this problem solvable? 4.      Startup Scan – Are innovators trying to solve it? 5.      Future Alignment – Does this address a future-oriented need? If any Fail, then we must refine, narrow, or redefine the problem before proceeding. Then I encourage the student to combine Stages 1–5 into a one-page Research Value Proposition (Why I should be spending several years working on this problem?). If PhD students validate the problem first, everything that follows—methods, data, solutions—becomes sharper, more relevant, and more impactful. What do you think? How does this framework align with the way you approach research problems?

Most startup founders rush to build a Minimum Viable Product before identifying a real problem. It’s like navigating without a compass. A product without a clearly defined problem is a collection of features waiting to fail. The real MVP is a Minimum Viable Problem Before you build, your mission is to define a tangible, validated, and meaningful problem for your target audience. Here are 3 proven methodologies to identify your Minimum Viable Problem: The Hiccup Method: Find where discomfort lives. Focus on pinpointing the exact moments where users feel frustration or friction. Ask specific, probing questions to uncover these pain points. When lasers revolutionized eye surgery, it wasn’t by chance. Innovators asked surgeons: “At what moment during surgery do you feel the most discomfort?” The answer? Of the entire procedure, one critical hiccup stood out: using a scalpel to remove a small piece of the cornea. By eliminating this step, laser technology transformed the process—and the market. The Hidden Resource Method: Turn what’s overlooked into value. Identify resources—physical, digital, or behavioral—that others ignore or underutilize. Airbnb: The hidden resource was unused living spaces. Uber: Idle drivers, unused cars, and smartphones with GPS. Both transformed “hidden resources” into massive opportunities for users and creators. The Change Lens Method: Leverage recent shifts. Spot opportunities by analyzing changes—cultural, technological, or behavioral—impacting the world around you. The shift to remote work didn’t invent new tools—it created new problems. Solutions like Zoom and Notion boomed by solving pain points triggered by this global change. Stop building products for the sake of it. Start by discovering the right problem to solve. The most impactful products aren’t created—they’re discovered by solving real, meaningful problems. Which methodology resonates most with you?