Problem Statement Definition

Most reps don’t give problem statements the time and attention they need. It should feel like you spent *way* too much time on the problem. Especially in a complex deal, where you need lots of people to agree on: [1] The Problem’s Framing. e.g. “Are MQL’s dropping because return on ad spend is down? Search ranking is dropping? Not capturing organic traffic?” [2] The Problem’s Cost. e.g. “Is this really something we want to spend * that * amount of money on right now?” [3] The Problem’s Priority Level. e.g. “Yes, that’s frustrating, but it’s not really a ‘problem’ because it’s not blocking any type of strategic project.” Here's an example. Say we're thinking about capturing leads on a website. [1 + 2] Start with costs + framing: "Every month, at least 50,000 visitors hit our site, but only 1% convert on our site forms, vs. our target of 2%, costing us 500 conversations per month. (Roughly $2.5 million in ACV based on the current sales funnel.) ^ Not every problem is that "measurable." But the overall framework is: "Every [ frequency ], at least [ reach ] are affected by [ frame the problem ], costing us [ cost ]." [3] Next, layer in consequences to a strategic priority: "Which means we’re spending more on paid ads to hit our targets, driving up our CAC. If this isn’t addressed by the start of Q1, we’ll miss both our revenue and our CAC targets — forcing us to raise at a lower valuation in an already tough capital market." ^ Notice the key phrases here: "Which means... [ negative outcomes]. If that’s not addressed by [ timing ], then, [ it gets worse ]." If you can’t frame a high-cost, high-priority problem, your deal will stall. It’s just a matter of time. If you can write a clear problem statement everyone agrees on, you’ll win. It’s just a matter of time.

Most project briefs fail before development starts. Because the problem statement is actually a solution in disguise. I have reviewed hundreds of programme briefs. The pattern is consistent. What gets called a problem statement is usually a stakeholder demanding their preferred solution. We need an app for potholes is not a problem statement. It is a solution masquerading as a requirement. The real issue is that citizens need to report road damage so it gets fixed faster. The solution might be an app. Or it might be better integration with existing systems.  Or trained call handlers.  Or all three. When you start with disguised solutions you build the wrong things for the right reasons. This carousel breaks down how to write problem statements that enable good solutions instead of mandating bad ones. Swipe to see the difference between real problems and solutions in disguise. #ProductManagement #ProblemSolving #GovTech

🎯 Why Most Business Problems Remain Unsolved (And How to Fix That) Last week, I had the privilege of facilitating a Problem Solving & Business Acumen workshop for our teams at L'Oréal Indonesia. 💡 The Problem We All Face (But Rarely Talk About) Here's an uncomfortable truth: we're wired to jump to solutions. In business, this looks like: ✔️ Launching promotions without understanding why sales declined ✔️ Hiring more people without diagnosing process inefficiencies ✔️ Copying competitor tactics without validating if they fit our context The cost? Wasted resources, frustrated teams, and recurring problems that never truly go away. According to the World Economic Forum's Future of Jobs Report 2023, analytical and critical thinking are the #1 and #2 most important skills for workers. Yet, most of us were never formally taught how to think critically or solve problems systematically. 🛠️ The Problem-Solving Process: A Step-by-Step Guide Step 1: Define the Problem (Don't Jump to Judgment!) 📝 Craft a Problem Statement with 6 components: "How can [responsible party] improve/reduce [reality] to meet [expectation] within [timeline] without [anti-goals], in order to fulfill [reason]?" Example: "How can the product team launch a new product on time in Q4 2024 without sacrificing key processes, in order to meet the sales target?" Step 2: Find Alternatives (Issue Tree + MECE) Once the problem is clear, break it down using an Issue Tree. For instance, if mascara sales dropped -14% YoY: 📦 Placement → Gondola compliance, visibility, signage 🎁 Promotion → BOGO mechanics, POS materials 💰 Price → Elasticity, perceived value 🎨 Product Claims → Content freshness, reviews 🔥 Competition → Share of voice, endcap presence ✅ Ensure hypotheses are MECE (Mutually Exclusive, Collectively Exhaustive)—no overlaps, no gaps. Step 3: Test Your Hypotheses Don't fall in love with your first idea. Run quick tests: 📊 For a skincare serum declining in pharmacies, we tested: ✔️ Hypothesis A: Reduced pharmacist advocacy is the issue → Micro-detailing pilot in 10 stores ✔️ Hypothesis B: Cold chain OOS drives lost sales → Warehouse SOP audit + temperature logs ✔️ Hypothesis C: Execution gaps suppress promo ROI → Endcap compliance audit Each hypothesis had clear KPIs and timelines—no guessing, just data. Step 4: Make the Decision (Impact vs. Effort Matrix) Not all solutions are equal. Prioritize: 🟩 Quick wins—do this! 🟦 Strategic bets 🟨 Fill-ins 🟥 Avoid Focus on low effort, high impact moves first. Build momentum, then tackle the big bets. 🚨 What Happens When We Skip These Steps? A mascara brand saw sales drop -14% YoY. The reaction? "Let's run a BOGO promo!" The result? Sales stayed flat. Why? Because the real issues were: ❌ Poor gondola compliance (only 68% correct facings) ❌ Weak influencer share of voice ❌ Competitor secured prime endcap space The lesson: Solutions applied to the wrong problem = wasted budget and missed targets.

𝗦𝘁𝗼𝗽 𝗮𝘀𝗸𝗶𝗻𝗴 𝗔𝗜 "𝗛𝗼𝘄 𝗰𝗮𝗻 𝘆𝗼𝘂 𝗵𝗲𝗹𝗽 𝗺𝗲?" 𝗦𝘁𝗮𝗿𝘁 𝗮𝘀𝗸𝗶𝗻𝗴 "𝗪𝗵𝗮𝘁 𝘀𝗽𝗲𝗰𝗶𝗳𝗶𝗰 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗮𝗺 𝗜 𝘀𝗼𝗹𝘃𝗶𝗻𝗴?" Most people open ChatGPT and type vague requests like "help me with marketing" or "give me business ideas."  Then they wonder why the responses feel generic. The issue isn't the AI. It's your question. Problem definition beats prompt engineering every time. Instead of: "Help me grow my business" Try this: "My sales team is missing 30% of quarterly targets. Deals slowed from 60 to 90 days. Each missed quarter costs $2M in projected revenue." Now AI can actually help you. With a clear problem, you can ask targeted questions:  • Analyze patterns in top-performing deals  • Research what drives faster sales cycles in your industry • Generate hypotheses about pipeline bottlenecks 𝗧𝗵𝗲 𝗳𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸 𝗶𝘀 𝘀𝗶𝗺𝗽𝗹𝗲: 1. Define the specific problem and its business impact 2. Quantify what success looks like 3. Use AI to research and validate solutions Six months of applying this approach will transform how you work.  Not because you become an AI expert, but because you master problem definition. The best AI users aren't prompt engineers. They're problem definers. 𝗥𝗲𝗮𝗱 𝘁𝗵𝗲 𝗳𝘂𝗹𝗹 𝗻𝗲𝘄𝘀𝗹𝗲𝘁𝘁𝗲𝗿 𝗵𝗲𝗿𝗲: https://lnkd.in/eHDpy-fn Found this helpful?  𝗟𝗶𝗸𝗲 𝗮𝗻𝗱 𝗿𝗲𝗽𝗼𝘀𝘁 to share with your network. 𝗙𝗼𝗹𝗹𝗼𝘄 𝗺𝗲 for more insights on using AI strategically in business. Got a specific problem you're trying to solve? 𝗗𝗠 𝗺𝗲 - I'd love to hear about it.

We solve the wrong problems – and That is the Real Problem at Work   Many executives spend a large amount of their time firefighting. Often, they are trying to solve the right problem. The classic case is that of Kodak, which once dominated the photographic industry worldwide. It had pioneered digital technologies well before their competitors, yet the leadership wanted to stick to the legacy of inexpensive camera with expensive consumables (film and paper) for high margins. Kodak’s initial reluctance to embrace and commercialize its own digital inventions caused a rapid erosion of its market share. It launched competitive digital cameras late - in the 2000s. They tried to perfect their digital technology while losing money on the cameras sold. The real problem wasn't that they needed better digital cameras—it was that the business model had shifted from selling cameras to selling services and software. What is the lesson we can take? Before diving into any solution, invest some time asking "What problem am I really solving?" It is useful to have separate discussions on defining the problem first, and having identified it, then working on finding solutions. Ensure you are looking at the root cause and not the symptoms of the problem. Write down multiple versions of the problem statement. Brainstorm and iterate. Version one might be "Our team misses deadlines." Version two becomes "Our team receives unclear project requirements." Version three reveals "Our team lacks a standardized way to prioritize competing requests." This simple exercise stops you from building elaborate solutions for surface-level symptoms. It prevents you from becoming the person who automates a broken process instead of fixing it; or optimizes something that shouldn't exist. Pick your biggest work challenge. Check whether you have defined problem statement correctly. You'll find yourself solving the root cause instead of chasing endless symptoms.   Picking the right problem leads to simpler solutions. Would love to hear your experience where you had to redefine your problem statement. 

So you want to define “the problem”... Most teams rush this step. They jump straight from “customer says X” → “let’s build Y.” But great problem definition is multi-layered. Here’s a stack I’ve been using lately: 1️⃣ Customer’s Mental Model / Stated Problem Start with their words. How do they describe what’s wrong? 2️⃣ Ecosystem View (Other Actors’ Perspectives) Zoom out. Who else is affected, and how do they interpret it? 3️⃣ Human Factors & Behavioral Dynamics What habits, incentives, or power dynamics keep the status quo in place? 4️⃣ Restated Problem (with Status Quo Attempts) Once you’ve seen all that, how would you re-frame the problem—and why have previous “fixes” failed? 5️⃣ Enabling Overlap with Product / Technology Where can your product, expertise, or tech actually change the conditions that sustain the problem? 6️⃣ Feasible Influence & Needed Capabilities And finally—what’s realistic to influence now, and what capabilities would expand that influence over time? Most “problem statements” stop at layer 1. Real insight lives in layers 3–5. That’s where strategy starts to emerge.

My favorite question to gauge a designer’s skill level is : “what problem is this feature or case study solving?” More experienced designers understand the true underlying problems faced by the user and business, while less experienced ones see the problem as a lack of a feature or functionality. For example, “the user is not able to customize the dashboard easily” is not a true problem statement. Instead, the stakeholder is inadvertently disguising their ask (a customizable dashboard) as a problem statement to further legitimize it as a good idea. In reality, the true problem (and solution) might have absolutely nothing to do with a dashboard. A false problem statement is: ❌ Solution-oriented, self-referencing and meta (The problem is we don’t have X so we must build X) ❌ Often surface level and identical to feedback from a user or internal stakeholder (”user: I wish there was a tool to do X”) On the other hand, a true problem statement does not suggest the solution. It’s often multi-layered and connected to a deeper issue. A true problem statement is: ✅ Disconnected from the solution. The solution may not be clear or even exist. Lacking a clear solution does not delegitimize the problem. ✅ Often not opinion based (not about what one thinks) and is instead behavioral and action based (what one does). I.e. Someone saying they have a problem is not the problem, but someone doing/not doing something could be a problem. If a designer’s closest collaborators can’t differentiate a feature from a problem statement, designers then have to ask: “What is the real problem this is solving?” “How do we know this is a real problem?” “How do we know if we’re solving it?”

I have seen 40 page BRDs that said absolutely nothing. And one page BRDs that got signed off in 24 hours. The difference was not the length. A BRD captures why a change is needed, what the business requires, and what success looks like. It is not a technical specification. It is not a list of features. Here is how to write one that actually gets read: 1. Problem Statement → One paragraph. Business perspective. No solution language. → Not "the system needs a new login module" ↳ "Customers are abandoning the portal because password resets take over 10 minutes, resulting in a 23% drop in self-service completion" 2.Scope Statement → Two lists. Nothing else. → In Scope: what this project will address → Out of Scope: what it will not address ↳ Naming what is out of scope is what prevents scope creep 3.Stakeholder Register → Name every stakeholder involved → Define their role: decision maker, approver, consulted, informed → Include their interest in the outcome 4.Business Requirements → Goals and objectives only. Not system features. → Each requirement must trace back to the problem statement → Not "the system shall send an email notification" ↳ "The business requires customers to be notified within 2 minutes of a failed transaction in order to reduce inbound call volume" 5. Assumptions, Constraints and Dependencies → Assumptions: what must be true for the solution to work → Constraints: budget, time, technology, regulatory limits → Dependencies: what this solution relies on from other teams or systems 6. Sign-Off Page → Named approvers only → Date of approval and version number → Space for signature or digital confirmation ♻️ Save this and Repost P.S. What is the biggest mistake you have seen in a BRD?

𝗥𝗲𝘀𝗲𝗮𝗿𝗰𝗵 𝗚𝗮𝗽 𝘃𝘀 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝗦𝘁𝗮𝘁𝗲𝗺𝗲𝗻𝘁 These two concepts are related but serve distinct purposes in research writing. 𝗥𝗲𝘀𝗲𝗮𝗿𝗰𝗵 𝗚𝗮𝗽 A 𝚛̲𝚎̲𝚜̲𝚎̲𝚊̲𝚛̲𝚌̲𝚑̲ ̲𝚐̲𝚊̲𝚙̲ is what doesn't exist yet in the literature — an unanswered question, an understudied population, a methodological limitation in prior work, or a contradiction between studies. It's descriptive and backward-looking: you're mapping the terrain of existing knowledge and identifying its edges or holes. 𝙴̲𝚡̲𝚊̲𝚖̲𝚙̲𝚕̲𝚎̲:̲ ̲"𝘔𝘰𝘴𝘵 𝘴𝘵𝘶𝘥𝘪𝘦𝘴 𝘰𝘯 𝘮𝘪𝘯𝘥𝘧𝘶𝘭𝘯𝘦𝘴𝘴 𝘢𝘯𝘥 𝘴𝘵𝘳𝘦𝘴𝘴 𝘩𝘢𝘷𝘦 𝘧𝘰𝘤𝘶𝘴𝘦𝘥 𝘰𝘯 𝘤𝘭𝘪𝘯𝘪𝘤𝘢𝘭 𝘱𝘰𝘱𝘶𝘭𝘢𝘵𝘪𝘰𝘯𝘴; 𝘭𝘪𝘵𝘵𝘭𝘦 𝘪𝘴 𝘬𝘯𝘰𝘸𝘯 𝘢𝘣𝘰𝘶𝘵 𝘪𝘵𝘴 𝘦𝘧𝘧𝘦𝘤𝘵𝘴 𝘪𝘯 𝘩𝘪𝘨𝘩-𝘴𝘵𝘳𝘦𝘴𝘴 𝘱𝘳𝘰𝘧𝘦𝘴𝘴𝘪𝘰𝘯𝘢𝘭 𝘦𝘯𝘷𝘪𝘳𝘰𝘯𝘮𝘦𝘯𝘵𝘴." 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 𝗦𝘁𝗮𝘁𝗲𝗺𝗲𝗻𝘁 A 𝚙̲𝚛̲𝚘̲𝚋̲𝚕̲𝚎̲𝚖̲ ̲𝚜̲𝚝̲𝚊̲𝚝̲𝚎̲𝚖̲𝚎̲𝚗̲𝚝̲ is forward-looking and action-oriented. It explains why the gap matters — the real-world consequence of not filling it. It connects the intellectual gap to a practical or social problem worth solving. 𝙴̲𝚡̲𝚊̲𝚖̲𝚙̲𝚕̲𝚎̲:̲ ̲"𝘞𝘰𝘳𝘬𝘱𝘭𝘢𝘤𝘦 𝘣𝘶𝘳𝘯𝘰𝘶𝘵 𝘤𝘰𝘴𝘵𝘴 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯𝘴 𝘣𝘪𝘭𝘭𝘪𝘰𝘯𝘴 𝘢𝘯𝘯𝘶𝘢𝘭𝘭𝘺, 𝘺𝘦𝘵 𝘦𝘷𝘪𝘥𝘦𝘯𝘤𝘦-𝘣𝘢𝘴𝘦𝘥 𝘪𝘯𝘵𝘦𝘳𝘷𝘦𝘯𝘵𝘪𝘰𝘯𝘴 𝘧𝘰𝘳 𝘱𝘳𝘰𝘧𝘦𝘴𝘴𝘪𝘰𝘯𝘢𝘭 𝘤𝘰𝘯𝘵𝘦𝘹𝘵𝘴 𝘳𝘦𝘮𝘢𝘪𝘯 𝘴𝘤𝘢𝘳𝘤𝘦 — 𝘭𝘦𝘢𝘷𝘪𝘯𝘨 𝘱𝘳𝘢𝘤𝘵𝘪𝘵𝘪𝘰𝘯𝘦𝘳𝘴 𝘸𝘪𝘵𝘩𝘰𝘶𝘵 𝘨𝘶𝘪𝘥𝘢𝘯𝘤𝘦." 𝗧𝗵𝗲 𝗞𝗲𝘆 𝗗𝗶𝘀𝘁𝗶𝗻𝗰𝘁𝗶𝗼𝗻 The gap says: 𝘸𝘦 𝘥𝘰𝘯'𝘵 𝘬𝘯𝘰𝘸 𝘟. The problem statement says: 𝘣𝘦𝘤𝘢𝘶𝘴𝘦 𝘸𝘦 𝘥𝘰𝘯'𝘵 𝘬𝘯𝘰𝘸 𝘟, 𝘠 𝘪𝘴 𝘴𝘶𝘧𝘧𝘦𝘳𝘪𝘯𝘨. A gap without a problem statement can feel academic and unmotivated. A problem statement without a gap can feel like a solution already exists. Together, they form the justification for your study. 𝗛𝗼𝘄 𝗧𝗵𝗲𝘆 𝗪𝗼𝗿𝗸 𝗧𝗼𝗴𝗲𝘁𝗵𝗲𝗿 In a well-structured introduction, you typically:  • Establish the broader topic and its importance  • Review what's known (literature)  • Identify the gap  • Articulate the problem statement — why filling the gap matters  • State the purpose/research question

Most problem-solving failures come from 𝘮𝘪𝘴𝘶𝘯𝘥𝘦𝘳𝘴𝘵𝘢𝘯𝘥𝘪𝘯𝘨 𝘸𝘩𝘢𝘵 𝘵𝘩𝘦 𝘢𝘤𝘵𝘶𝘢𝘭 𝘱𝘳𝘰𝘣𝘭𝘦𝘮 𝘪𝘴. A problem is the difference between things as desired and things as perceived. But what seems like a problem to one person might be irrelevant to another. So, before solving anything, ask: “𝘞𝘩𝘰 𝘩𝘢𝘴 𝘵𝘩𝘦 𝘱𝘳𝘰𝘣𝘭𝘦𝘮?” Different stakeholders (e.g. directors, workers, engineers) may all define the same situation in totally different ways. Also, not all problems are real in the objective sense. Some stem from perception alone. But even phantom problems have real consequences and need to be addressed.   People often leap into solving a perceived issue without first confirming that it's the right issue. This book by Don Gause and Jerry Weinberg tells stories, e.g., about a skyscraper’s elevator where people tried dozens of fixes for slow service before realizing that mirrors or actual repairs could shift perception or address the real issue. Solving one issue often introduces new ones. It’s important to be ready for this cycle. The trick is to replace worse problems with better, more manageable ones.   A client's request for a specific type of solution doesn’t mean that’s what they need. So, always question whether their approach addresses the real issue. Gause and Weinberg suggest to ask outsiders, naïve users or children to expose blind spots in your thinking or design. Their fresh perspective often reveals hidden misfits.   The way a problem is worded can shape how people think about it. Simple wordplay can shift interpretations and solutions. Furthermore, if someone doesn’t have a sense of humor, you’ll struggle to help them with their problems. Humor reveals flexibility of thought and openness to new viewpoints.   Some lessons from the book: - Always start with: “What is the problem?” and “Whose problem is it?” - Look for at least 3 possible misunderstandings in any problem statement. - Think of solutions that reframe or redefine the problem instead of just fixing symptoms. - Accept that no solution is final. Every fix brings new challenges. - Revisit your assumptions regularly, especially after a solution is implemented.   This is one of my favorite books. It was published when I was still in high school. The wisdom in this book is in teaching readers to ask better questions. It celebrates ambiguity, humor, and humility in the face of messy human problems. A refreshing take in a world that too often rewards quick fixes!   𝐒𝐨𝐮𝐫𝐜𝐞: Gause, D.C., Weinberg, G.M. (1990), 𝘈𝘳𝘦 𝘠𝘰𝘶𝘳 𝘓𝘪𝘨𝘩𝘵𝘴 𝘖𝘯? 𝘏𝘰𝘸 𝘵𝘰 𝘒𝘯𝘰𝘸 𝘞𝘩𝘢𝘵 𝘵𝘩𝘦 𝘗𝘳𝘰𝘣𝘭𝘦𝘮 𝘙𝘦𝘢𝘭𝘭𝘺 𝘐𝘴, New York: Dorset House Publishing.