How do you test product hypotheses using Hypothesis-Driven Development?

The first two steps of Hypothesis Development are : - Assumptions and Condition - Build Hypothesis Statement Product managers or Business Analysts make assumptions on the conditions that are the reason why we made certain assumptions. For instance, a Product Manager may notice declining playstore rating of an application and most of them states reason being bad User Experience(UX). The PM or BA make innumerable assumptions - enhance User Interface, conduct Survey to get better understanding behind rating declination or use existing user to market our product better. Not all of these could be considered as hypothesis statement. Hence, it is imperative to segregate Good hypothesis from a bad hypothesis.

To develop a product that meets user needs and business objectives while minimizing risk, start by formulating specific, testable hypotheses using frameworks like BRIDGeS for ideation and the MoSCoW framework for prioritization. Conduct experiments to test these hypotheses, using methods such as A/B testing, prototyping, or user interviews and establish clear validation criteria. Utilize tracking tools like Coda or Google Sheets for organized data collection during testing. Finally, analyze results against your established criteria, and either implement validated changes or learn from failed hypotheses to iterate the process.

It's also useful to have a defined time horizon for your goals oriented around the customer. For instance, setting goals that have time parameters based on customer expectations. Your customer's time to value goal should be realistic and aligned with their needs.

One trap teams often fall into during HDD's hypothesis generation is succumbing to confirmation bias. When we form a team, there's a tendency to gravitate towards folks with similar beliefs and goals. This can inadvertently narrow our vision, causing us to overlook diverse perspectives crucial for generating varied hypotheses. Instead of an environment where everyone's ideas sound the same, what we truly need is a melting pot of thoughts. Dissent isn't just beneficial; it's pivotal. Embrace those occasional disagreements – they're essential for truly innovative hypotheses.

Generating hypothesis is a team effort. All the stakeholder must mutually close down on hypothesis statement. We first make a hypothesis dump based on assumptions but then narrow them down to fewer and more impactful hypothesis based on facts, customer insights and research. Further we prioritise the hypothesis to ensure. We must bear in mind while segregating and prioritising hypothesis: - Assumptions are not facts - We must not be 100% confident that our assumptions will always be correct that would lead to confirmation bias - Test the hypothesis at least once in different scenarios - Target group must be involved in the formulation of the hypothesis - Hypothesis must be clear and measurable

Finding deeper insights in HDD experiments often means looking past the first set of numbers. Take an e-commerce platform that adds a 'Quick View' popup for products. There's a small increase in products added to carts, but final purchases don’t match up. Instead of just calling the feature somewhat successful, dig deeper: Is the 'Quick View' doing its job, or is important info missing, causing people to leave their carts? This small change in behavior could point to a bigger user experience issue than just the initial numbers show.

As a B2B product lead in anomaly detection, here are my top 4 tips for product development: (1) Define the problem and objective. For example, for anomaly detection product, The objective is to detect anomalies in real-time because businesses are not able to identify and respond to anomalies quickly. (2) Generate and prioritize hypotheses. For example, one hypothesis might be that businesses are not using existing anomaly detection because they are expensive & complex. Another could be data literacy gaps. (3) Design & run experiments. Test hypotheses with potential customers (surveys or design partners.) (4) Analyze and learn. Make data-driven decisions. Validate new product ideas with qualitative measures. Read the Mom Test book.