Developing Case Study Hypotheses

Stop diving into data blindly. Use this framework first. You open the dataset. Start querying. Build some charts. Two hours later: "Wait, what was I trying to answer?" Sound familiar? Most analysts work backwards. They start with data. Then try to find something interesting. That's not analysis. That's wandering. Professional analysts use a framework BEFORE touching data. Here's the 6-step approach: Step 1: Define the Question Not: "Analyze this sales data" Yes: "Why did Q4 sales drop 15% vs Q3?" The test: - Can you write it in one sentence? - Can someone outside your team understand it? If no, your question isn't clear enough. Step 2: Identify Success Metrics What does a good answer look like? Example: Question: "Why did sales drop?" Success: "Identify top 3 factors, quantify each one's impact" Not: "Find some insights" Yes: "Quantify exact drivers" Know what "done" looks like before you start. Step 3: Hypothesize What do you THINK is happening? Write it down before looking at data. Example: Sales dropped because: - Top customer reduced orders - Competitor launched promotion - Seasonal slowdown You're allowed to be wrong. You're not allowed to be aimless. Step 4: Map the Data What data do you ACTUALLY need? List it: ✓ Sales transactions (last 6 months) ✓ Customer purchase history ✓ Competitor pricing ✓ Seasonal trends (3 years) Don't pull everything. Pull what answers your question. Most analysts waste hours on irrelevant data. This step prevents that. Step 5: Analyze (Finally) Now you touch the data. But you're not exploring randomly. You're testing your hypothesis systematically. For each hypothesis: - Pull relevant data - Run specific analysis - Document findings - Confirm or reject Example: - Hypothesis: "Top customer reduced orders" - Analysis: Customer X went from $50K to $10K monthly - Finding: CONFIRMED - explains 60% of drop You're building evidence, not guessing. This is literally a smarter way to work. Step 6: Communicate Answer the original question. In plain language. Bad answer: "I analyzed the data and found patterns..." Good answer: "Q4 sales dropped 15% due to: - Customer X reduced orders 80% ($40K impact) - Competitor promotion stole 15% share ($15K) - Seasonal dip ($12K) Recommendation: Contact Customer X urgently." Let the response always follow: Answer → Evidence → Action. Without framework: - Start with data - Explore randomly - Find vague insights - Unclear recommendations - Hours wasted With framework: - Start with question - Analyze purposefully - Find specific answers - Clear actions - Hours saved This works for ANY analysis Every time. Most analysts skip straight to Step 5. Then wonder why their analysis goes nowhere. Once again: Stop diving into data blindly. Start with the framework. Question for you: Which step do you usually skip? 📌 Save for your next analysis ♻️ Repost for analysts diving in blindly

At emdash, we recently shipped 3 major features in 3 months using a simple, 3-step planning process. Planning isn’t just about setting goals. It’s about assessing, learning, and adjusting based on what’s working – and what’s not. It’s about staying agile and primed to tackle whatever comes your way. Our 3-step process, inspired by Richard Rumelt's strategy work, keeps us aligned and focused. Here’s how it works: 1️/ Start with the Facts We begin by grounding ourselves in reality. Before jumping into new ideas, we take a step back and look at the current state. What’s going well? What’s falling short? This phase is all about clarity and alignment. We gather data – such as user engagement stats, customer feedback, and "dogfood" metrics – to paint an objective picture of our product and business. The goal is simple: ensure everyone on the team is on the same page about the challenges and opportunities. Example: If our usage data shows high churn in a specific customer segment, we focus on understanding the underlying causes. Are there key pain points? What insights can our customer success activities provide? 2️/ Develop Hypotheses Next, we craft hypotheses to explain these realities, striving to uncover root causes without jumping straight to solutions. This high-level thinking keeps us flexible and open to different possible solutions. Example: Based on the churn issue, we might hypothesize: "Customers in segment X are facing onboarding friction due to expectations set by using solution Z." This sets up the next step where we develop a plan to test the hypothesis. 3️/ Define Specific Actions Finally, we translate our hypotheses into concrete actions. This phase is where the roadmap takes shape, framed as a series of tasks to validate (or disprove) our ideas. Sometimes, this requires cutting an active workstream that no longer fits our evolving plan – a tough decision, but necessary to keep us disciplined and moving forward in the right direction. Example: If onboarding friction is the issue, actions could include redesigning the flow, conducting user interviews, or creating more educational resources for that segment with a specific nod to existing solution Z. Why This Works This 3-step process is collaborative, clear, and adaptable to any challenge the team is facing. It doesn't just tell the team what to do – it empowers them with a deep understanding of *why* each action matters. This leads to faster execution, better results, and a more cohesive team dynamic. Crucially, this approach also frees the team to develop even better solutions once on the ground during execution. How do you approach planning? Please share your strategies!

To: ✓ Grow your design career ✓ Build killer case studies ✓ Do meaningful work You need to solve real problems for real people. A process occurs when you have a problem statement or opportunity and want to turn it into a solution. I call it the discovery process. It's about gathering data before jumping to solutions. This is a critical process for product designers and PMs to understand. It starts with gathering context. Context gathering ------ Before you think about solutions, you should be able to: • Identify assumptions about why the problem occurs¹ • Frame it as a problem for the user and the business • Gather data that demonstrate it's a real problem • Understand who it affects (and who it doesn't) ¹ Highlights gaps in knowledge and research opportunities. Solving the problem ------ When thinking about solutions, you should be able to articulate: • Your desired change in business metrics • Your desired change in user behaviour • Your riskiest assumptions • Solutions as hypotheses Weighing Solutions ------ When you've articulated your solutions as hypotheses, weigh them against each other. Think about how each one factors for: • alignment with business objectives • feasibility • impact Reducing risk ------ You won't have all the data you need available all the time. If there are important gaps that you think the success of your design relies on, you need to gather more data, either in the form of user research or experiments designed to validate assumptions with minimum disruption. Benefits of the discovery process ------ • Prevents you from rushing to create solutions to problems nobody has. • Focuses on outcomes (business impact/user behaviour) over outputs. • Frames design as measurable experiments: release, analyse, iterate • Ensure you understand the problem before jumping into solutions • Gather available research/knowledge/context all in one place • Identify knowledge gaps Format ------ I like to kick this off using a whiteboard (template in the comments) that everyone can collaborate on. Prioritised hypotheses then get added to the project pipeline. If you liked this post, you should join the waitlist for my design career guide. It's packed with actionable advice on becoming a better product designer. Link in the comments 👇 #productdesign #designcareer

𝐇𝐨𝐰 𝐭𝐨 𝐃𝐞𝐯𝐞𝐥𝐨𝐩 𝐘𝐨𝐮𝐫 𝐓𝐡𝐞𝐨𝐫𝐞𝐭𝐢𝐜𝐚𝐥 𝐅𝐫𝐚𝐦𝐞𝐰𝐨𝐫𝐤 1.    Identify Your Research Problem and Questions: Start by clearly defining the central issue or problem you want to investigate and the specific questions you aim to answer through your research. 2.    Conduct a Thorough Literature: Read extensively within your field to identify existing theories and concepts relevant to your research topic. Create a literature map to visualize connections between different studies. 3.    Select Appropriate Theories: Analyze the theories you've identified and choose the one that best fits your research question and provides a strong framework for understanding your variables. 4.    Identify Key Concepts and Variables: Break down your research topic into key concepts and variables directly related to the chosen theory. Draw boxes for concepts and arrows to show relationships. 5.    Explain Relationships Between Concepts: Articulate how the key concepts and variables within your chosen theory are expected to correlate or interact and influence each other with your research question. 6.    Develop a Conceptual Model (Optional): Visualize your theoretical framework by creating a diagram that shows the relationships between key concepts and variables. 7.    State Your Assumptions & Hypotheses: Based on your chosen theory, clearly state the assumptions you are making about the correlations between variables, and formulate testable hypotheses to guide your research. 8.    Justify Your Choice of Theory: Explain why the selected theory is the most appropriate for your research, highlighting the strengths and limitations in addressing your research question.  Important considerations: Relevance to your research: Ensure your chosen theory is directly applicable to the specific context and issues of your study. Clarity and consistency: Present your theoretical framework in a clear and organized manner, making sure your concepts and relationships are logically connected. Seek feedback: Share your theoretical framework with peers or advisors to receive feedback and ensure its soundness and appropriateness.     

How great hypothesis help you learn fast, and pick the right path. At Moonpig, I’ve been thinking a lot about how we can make testing more purposeful — not just to move metrics and see what happened, but to deeply understand customer behaviour, and why customers do what they do. So I recently introduced a 💡 Hypothesis Framework 💡 to help our product teams write better, bolder hypotheses, that help us understand the most important things about our customers. The goal? 1️⃣ Learn faster (through various means, both quant and qual) 2️⃣ Take bigger (but smarter) risks where it matters most 3️⃣ Focus on testing to learn, not just to prove 4️⃣ And shift from vague test ideas to more opinionated bets that help us pick a direction We want teams to ask themselves: “What would we learn about our customers if this fails?” and “what will I do differently based on the outcome of this test?” Because every test should move us forward — regardless of outcome… meaning we never ‘fail’, we always learn. The hypothesis canvas I created guides teams to define... 🧠 What they believe to be true about why our customers do what they do 🧪 How they will validate their assumption quickly (either through research, or testing) 📈 What they will measure (thinking about leading UX metrics such as engagement or clicks) 🤩 How they’ll know they are right (what % users need to agree or exhibit the desired behaviour) 🗺️ What they’ll do next based on what they have learned Finally, it’s important to remember that hypothesis aren’t created after you come up with the idea, they are created before. Hypothesis are tools to help you generate ideas to prove your assumptions true or false, ways to learn about your customers, not just to prove that your idea worked. #ProductDesign #ProductManagement #Experimentation #HypothesisDrivenDesign #Moonpig #innovation #uxdesign

This week, BITS Design School Mumbai students participating in Design Methods 101 created hypothesis statements from their interviews to test their emerging recommendations for specific actors in specific situations. Using David Bland test cards provides a straightforward way to develop both a hypothesis statement and a test card to stress-test a particular unit of value and confirm or refute the hypothesis. This exercise is not to force design into purely quantitative outcomes, but to link qualitative and quantitative together in a dynamic relationship of value and accountability. With companies desiring more value in competitive marketplaces, this approach provides rigor, focus, and accountability in delivering human-centered solutions. Here are some student quotes about their experience in defining hypothesis statements to test on chosen actors : • A key learning this week was how hypotheses don’t just get confirmed or rejected, they open up unexpected angles. • The cards enabled us to systemically test and measure outcomes and challenge our preconceived beliefs and confront unexpected realities . . . It shifted our thinking from "what should work in theory" to "what actually works in practice." • Mapping satisficing and affordances, supported by test cards, didn’t just confirm our hypotheses but also reminded us that behaviour, environment, and emotion is inseparable, and what looks like inefficiency is often a creative response to complex challenge. • By mapping out these satisficing decisions—where the actor was not necessarily choosing the “best” option but the most sufficient or workable one—we began to see the underlying trade-offs that shaped their actions.  • Using test cards helped us understand the actor better by encouraging us to make guesses about their motivations and then verify them through real interaction.  • Rather than leaving things vague, we had to define exactly how we would test them, what signals to watch for, and what the success of a hypothesis would look like.  • The test cards helped us separate what we assumed from what was real. They gave us a way to fact-check ourselves instead of relying on assumptions. Without them, we probably would’ve stuck to vague guesses instead of clear insights. An example of how a student team presented their approach to forming hypothesis statements : https://lnkd.in/g7yuT-NM Thanks to Harroop Kaur, Mansi Wadekar, and Gautham Arumugam for their collaboration and abilities to manage 180 freshmen over nine weeks. #bitsdesign #designmethods