Crafting Effective Problem Statements

ever felt like you're pouring loads of energy into solving something, but then later you realize you were tackling the wrong thing entirely. It happens, right? Oh, absolutely. It's a really common trap. And it just highlights why really getting the problem clear first is so incredibly powerful. That's where this whole idea of a well-crafted problem statement comes in. And well, that's what we're diving deep into today. Exactly. So to really get into it, we've looked at quite a few really useful sources. We're pulling from Antler Academy's How to Craft a Compelling Problem Statement. Okay. There's a great case study, Accelerating Project Alignment with Storyboards and Clear Problem Statements. Also Crafting Effective Problem Statements, and some really good UX thinking from the Nielsen Norman Group's Problem Statements and UX Discovery. Right. So a good mix. So our goal today is pretty straightforward, but honestly, super important, just to give you a really solid handle on how to spot and then articulate problems effectively. Yeah. Whether it's a business thing, a new project, or really any situation needing a fix. Mastering this problem statement thing can be a, well, a genuine game changer. Okay. So to kick things off, what is a problem statement? Like fundamentally? Basically, it's just a short, clear description of the issue you need to solve. The Nielsen Norman Group calls it a brief articulation of the problem. Brief? Yeah. Antler suggests aiming for one or maybe two sentences. But don't let that brevity fool you. Its main job isn't to spell out the answer. Right. It's more about sparking creative thinking around the challenge itself, you know, framing the right question before you jump to answers. I see. So setting the stage for innovation, but without sketching the solution inside those lines too early. And why is nailing this initial definition just so critical? Well, Antler makes a strong point. A business basically exists to solve a problem. So the problem statement, that's its core reason for being in a way. The core. Beyond that, crafting effective problem statements points out a bunch of benefits. It gets teams, stakeholders, everyone aligned. Yeah. On the same page. Exactly. It guides your product strategy, your innovation efforts. And crucially, it helps you avoid that super costly mistake of, you know, building stuff for problems that aren't really there. Or not the right problem. Precisely. And by focusing on user pain points, it builds empathy. And Antler also adds that it sets clear goals for discovery work, and that helps get stakeholders bought in. It really sounds like the foundation, doesn't it? If that's wobbly, whatever you build on top is, well, at risk. Totally. You also mentioned a difference between problem statements and, say, mission or vision statements. How do those differ? Yeah, that's a good distinction. Mission and vision are like the big picture for the whole organization. A problem statement is much more focused. Antler notes a single company might tackle several different problems, each needing its own problem statement, maybe leading to different products or services. The key thing is that problem statement becomes the yardstick. You measure any potential solution against it. Does this actually solve the problem we defined? Which brings us to, well, a really key point. Why define the problem before you even think about solutions? Seems obvious, maybe, but it gets skipped a lot in the rush. Oh, absolutely. Antler puts it brilliantly. The biggest risk is ending up with a product looking for a problem. Huh. Yeah. Seen that happen. You might have this cool idea, but if there's no clear problem it solves, you're just kind of hoping it sticks somewhere. Mm-hmm. Fingers crossed. A good problem statement makes sure all that creative juice flows towards a specific meaningful goal, not just making something new for the sake of it. It focuses your innovation. And the payoff isn't just at the start, right? That case study we looked at really showed how these statements keep delivering value throughout a project. Exactly right. The case study really hammered home how clear problem statements act as these essential guardrails, both for the initial brainstorming and then later for testing. Guardrails. I like that. Yeah. By always going back to the problem statement, teams can check really rigorously, check if their ideas truly hit the core need. It's a constant benchmark for progress, and importantly, it stops that scope creep. Oh, yeah. Scope creep. The killer. By keeping everyone laser focused on the user's actual issue. Now, Antler gave us a really practical framework, didn't they? Yeah. Seven key questions to help dissect a problem. Let's walk through those. They seem super helpful. Yeah. They're great for guiding your thinking, help you really consolidate your understanding from different angles. First one, what is the problem that needs to be solved? Simple but crucial, like people can't get to their usual workplace anymore. Second, why is that a problem? So the consequence, this disruption messes up business operations continuity. Makes sense. Third, where is the problem observed? Not just at work, maybe more like the usual physical office is now off limits to employees. Getting specific. Fourth, who is impacted? Goes beyond just the staff, right? Could be clients, customers who rely on face-to-face stuff. Right. The ripple effect. And those first few really start to build the picture. What about the last three? Yeah. The final three add more context. Fifth, when was the problem first observed? Gives you a timeframe, like right after the stay-at-home orders hit. Sixth, how is the problem observed? The tangible stuff. Hardly anyone in the office. Way less face-to-face collaboration. You can see it. Seventh, how often is the problem observed? This gets at the scale. Is it occasional? Or, like in that example, continuously, daily, for however long the restrictions last? Wow. Yeah. Antler's point is working through these systematically helps you boil it all down to the essence of the problem. Okay, so you've shooed on those seven questions. Antler also mentioned some key things a good problem statement should actually contain. What were those ingredients? A strong one should, first off, clearly identify a gap or a pain point that exists. Okay. The hurt. Second, it needs to explain the context, the when, where, what of that gap. Ideally, third, it'll try to quantify it if possible, you know, cost, size, quality, impact. Put some numbers on it. If you can, yeah. And finally, it has to spell out why it's important to fix this gap. What happens if you don't? If your statement hits those points, you're probably in pretty good shape. Okay. So you've shooed, answered the questions, got the ingredients. Now how do you actually write the thing? Make it clear, effective. Antler had some tips here too. They did. First tip, identify the single biggest problem from your brainstorming. There might be lots of related issues, but focusing on the main one, that usually leads to the best solution. Focus, right? Second, be really explicit about where the pain is coming from. Instead of just remote work is hard, be specific. The sudden switch to remote work left teams struggling with collaboration. That avoids fuzziness. Yeah. Precision matters. What else for the writing part? Third, make it human. Connect it to people's actual experiences. Employees are finding remote collaboration challenging lands better than just talking about communication system failure. Heal the pain. Exactly. Fourth, while you're highlighting the problem, you should also sort of imply a solution is possible without actually describing it. Creates a bit of hope maybe. Okay. Not just doom and gloom. Right. And finally, keep it brief. Really brief. One or two sentences. Tops. Makes it easy to grab and remember. Concise is key. Now, just as vital as what goes in is knowing what to leave out. Antler flagged four common distractions that can really mess up a problem statement. Let's cover those so we know what traps to avoid. Yeah. These can really send you off course, solving something superficial instead of the real deal. First one is focusing on symptoms, not the root cause. Ah, the symptom trap. Antler used that example of remote work comms issues where someone jumps to better webcams as the fix. Right. But maybe the real problem is like unclear processes or the wrong collaboration tools entirely. This is where that first principles thinking comes in really breaking it down. So patching the symptom might feel good short term, but doesn't solve the underlying thing. What's distraction number two? Number two is jamming solutions in too early. The statement defines the challenge, right? Not your untested guess at how to fix it. Keep solutions out for now. Got it. Third, be careful not to focus just on causes. Understanding the cause helps find solutions later. Sure. But the problem statement itself needs to describe the current bad situation. Hmm. Subtle difference. Yeah. Like COVID might have caused the remote shift, but the problem statement should focus on the resulting collaboration challenges, not just the pandemic itself. Okay. That makes sense. What's the last distraction Antler warned about? The last one is blame. A problem statement needs to be neutral, objective. Pointing fingers about why the problem exists doesn't help define it or find good solutions. Focus on the issue, not whose fault it might be. Keep it blame free. Good advice. Okay. Shifting gears slightly, crafting effective problem statements offered some core traits of strong statements. Another good lens to look through. Absolutely. They really emphasize that good ones are human centered. They focus on people's experiences, their emotions. Right. The human side. They're contextually rich, give you enough background to actually understand the situation. They're rooted in research based on real insights, not just guesses. Evidence, not assumptions. Exactly. They should be open-ended, meaning they encourage lots of different creative solutions, not just one narrow path. They need to be clear and precise, easy for anyone to understand. And finally, strategically aligned, linked to the bigger business goals. That's a really solid checklist of qualities. And that same source, crafting effective problem statements, also gave several detailed structures or templates. Those seem like really handy starting points. Yeah. They can be super helpful. One good one is the human centered design HCD template. It goes, user or persona needs a way to do something specific because of this reason or pain point. Simple structure. Yeah. Their example was, a rural nurse needs a quick way to check patient histories remotely because current record systems aren't accessible outside hospital walls. See? Clearly defines the user, their need, and why. Really focuses on empathy. I like that. Puts the person right at the center. What's another structure they suggested? Another useful one is the jobs to be done JTBD approach. That one structured like, when I'm in this situation, I want to achieve this motivation so that I get this desired outcome. Okay. Situation, motivation, outcome. Right. Their example was, when I'm managing patient appointments, I want an easy method to notify families of schedule changes so that I reduce confusion and missed visits. This framework is great for digging into the user's underlying job and what success looks like for them. Different angle. Also very useful. And there were a couple of other formats too, right? Yeah. They mentioned the expanded 5Ws plus how format. Basically encourages you to explicitly spell out the who, what, where, when, why, and how of the problem. Good for complex stuff. Make sure you cover all the bases. Like a structured brainstorm? Kind of. The example there was about care coordinators struggling to get patient info during emergencies at clinics far from the hospital causing delays and anxiety, which then naturally leads to the next technique. Which is? Framing problems as, how might we? HMW questions. Ah, yes. HMWs. Very popular. Super useful. You take the problem insights and rephrase them as open questions, starting with, how might we? So for that community health worker example about tracking visits, the HMW becomes, how might we give CHWs a simple digital way to track visit notes and share key findings? Opens things up. Exactly. It's deliberately broad. It shifts the focus from just staring at the problem to exploring all the possibilities for solving it. Great for kicking off brainstorming. Okay. Now let's pivot to that UX perspective from Nielsen Norman Group. They really stressed how vital problem statements are in the discovery phase of UX work. Yeah. And he really hammers this home. A good problem statement during discovery is your main tool for framing the specific problem you're trying to understand and eventually solve with design. Sets the scope. Precisely. It tells the whole team, stakeholders included, exactly what you're focusing on. They warn that discovery without a clear problem statement can just wander aimlessly. Or worse, teams start exploring solutions before they even understand the real issue. The problem statement is like your compass, keeping everyone pointed at what needs investigation and just as importantly, what's out of scope for now. And it's not just for the internal team's benefit, is it? Not at all. Enang points out that well-written problem statements are fantastic communication tools for getting stakeholder buy-in. Ah, the buy-in. Crucial. Totally. By clearly laying out the problem and why it matters, you build a strong case for actually investing the time and resources needed for proper discovery. It helps everyone get the why behind the research effort. They had some good examples in a UX context, too. Can we look at one of those, see how it plays out? Sure. One was about a newspaper app. It went something like, users of our newspaper app often export content instead of using the built-in sharing features. This is a problem because exported content is less likely to be attributed back to us, hurting brand visibility and maybe user growth. Plus, for users, exporting can be clunky and might make them use the app less over time. Okay, that's pretty detailed. Yeah. Notice how it includes the background behavior, who is affected, users and the newspaper, and spells out the negative impacts, lower visibility potential churn. Very clear. It covers the issue and the consequences but still feels concise. And NN also brought back the five Ws, who, what, where, when, why, as a good way to gather the facts needed for a strong statement. Yep. And they make a really important point. It's okay if you don't have all the answers to those Ws right at the start. Oh, that's reassuring. Definitely. The whole point of discovery is often to find those details and root causes. So as you learn more from research, you absolutely should go back and tweak, refine your problem statement. Make it a living document. Exactly. Importantly, NN echoes Antler. A problem statement should not be just a laundry list of gripes, and it definitely shouldn't sneak in solutions. Brevity, clarity is still key. Now this was a really interesting twist from NNN. Problem statements don't always have to be negative. They can be framed as opportunities. How does that work? Right. Opportunity statements. Instead of focusing on what's wrong now, they highlight the gap between now and a better future state. Okay, focus on the potential upside. Exactly. One example was the traditional home buying process, often long, mostly offline. That presents an opportunity to streamline it, digitize parts, make customers happier, maybe boost sales. The guiding question shifts from what's broken to what could we achieve? So aiming for positive change, not just fixing a negative, that's a nice framing. Antler also gave us those punchy real world examples from big companies. Can you remind us of one or two? Yeah, those really show how a clear problem focus can lead to massive things. Think about early Facebook. Finding music, news, info online is easy, but connecting with family and friends, inefficient, cumbersome. Hmm, yeah, clear problem. Or Stripe. E-commerce is booming, but actually taking payments online, still a big headache, especially for small businesses. And? In both cases, super clear problem definition, zero hint of the specific solution they eventually built. It's amazing to see how those fundamental statements set the stage for such huge innovations. Okay, so you've got your solid problem statement. How do you actually use it day to day? NN had thoughts on this too. They really see it as the launch pad for structuring all your discovery work and setting clear research goals. Using that home buying example again, the opportunity statement leads to the discovery goal. Understand how to make the process faster and more user friendly. Okay, so it guides the research questions. Directly. It tells you what unknowns you need to investigate. Like what parts of buying a house are hardest now? Where are the biggest delays or frustrations? What does the whole journey actually look like for a buyer today? And you mentioned it's not set in stone, right? Absolutely not. NN stresses revisiting and refining it. As you learn more during discovery, or maybe if the project direction shifts slightly, you update the statement. It keeps it relevant. A dynamic tool. Right. And then, at the end of discovery, when you're presenting findings and recommendations, the problem statement circles back to provide that crucial context reminding everyone what challenge you were tackling in the first place. Crafting effective problem statements also touched on digging deeper. Really understanding the problem with different research methods. What were some they mentioned? Yeah, they listed quite a few valuable ones. Things like actually talking to users, user interviews, contextual inquiry to get their first hand perspective. Get out of the building. Totally. Buyers observing behavior through diary studies or usability testing, plus using surveys and analytics for broader quantitative data. So a mix of qualitative and quantitative. Ideally, yes. And they also mentioned more advanced techniques for framing the problem once you have data like the five whys to find root causes, affinity diagrams to cluster insights, journey maps and empathy maps to really visualize the user's world. Lots of tools in the toolbox. And even service blueprints to map out the underlying systems involved. It's all about getting past surface level stuff to a really deep understanding. Really emphasizes that thoroughness. And finally, that same source offered a helpful quality checklist for your problem statement. What are some key things to check for? Yeah. Quick sanity check. Does it clearly name the user or context? Is it based on actual evidence, not just your gut feeling? Is it specific enough to guide you, but still broad enough for creative solutions? It's a sweet spot. Does it avoid sneaking in solutions? Does it genuinely encourage brainstorming? And crucially, does it show the business value or how solving it connects to strategy? A good final check. So wrapping this up, it feels really clear that spending the time to get problem statements right isn't just, you know, busy work. It pays off big time. Oh, absolutely. A sharp problem statement gives you focus, leads to better solutions, gets your team aligned, stops you wasting time on the wrong things, and ultimately just seriously ups your chances of success. So here's a final thought for you, the listener, to take away. Think about a challenge that keeps nagging you, maybe at work, maybe personally. What would happen if you tried to reframe it? Write it down as a concise, human-centered problem statement. Try using one of those templates we talked about, or just the five W's. You might honestly be surprised at the clarity and, maybe, the new ideas it sparks.