Fire the Hypothesis, Not the Executive!

What really is needed during Product Discovery with Lean/ Agile Thinking? The article has been inspired by the recent workshop I conducted with a group of Product Leaders & Agilists at Lean Agile Glasgow .

The Problem: Many companies struggle to launch successful products (90% is often cited as a failure rate for first-time product teams). The wait to get to "quality" market feedback is often at least over a year (the launch!) and blame often falls on the executive in charge when a product fails to meet market/ customer expectations. I have seen this knee-jerk reaction several times throughout my decade-long career in Product Management (I should say I've even found myself guilty of having made a few poor (and irreversible) decisions myself or realized too late in the game that we did not complete Product Discovery the way we should have as a team, to begin with.

Mindset: To avoid this pitfall, and improve the odds of success, you need a mindset - firing the hypothesis each time till you hit product-market fit. By using customer development and Lean Startup/ Design Thinking methodologies, teams can gather data and feedback directly from customers, leading to more successful product discovery for subsequent launches.

These are my top 5 steps to implement these methodologies:

1. Use customer development to test hypotheses early and often: Customer development emphasizes the importance of testing assumptions with customer feedback. By getting input from potential customers early on, teams can avoid building products in a vacuum and ensure that their products meet the needs of the market.
2. Embrace a rapid, iterative approach to product development: Lean Startup encourages companies to create a minimum viable product (MVP) and then gather feedback from customers to refine and iterate. This approach helps teams avoid investing too much time and resources into a product that may not resonate with the market (avoid the classic solution bias).
3. Gather validated data to inform product decisions: To ensure that feedback is reliable and useful, one needs to gather validated data (we like doing it via Design Sprints), use landing pages for quantitative data collation, and other research methods. This data can then be used to make informed product decisions.
4. Use examples from Steve Blank's "The Four Steps to the Epiphany" and Eric Ries' "The Lean Startup" with your team: Both of these books provide valuable frameworks for implementing customer development and Lean Startup Design Thinking methodologies. By studying these examples, you can gain insights into how to apply these concepts to your own product development processes.
5. Celebrate and learn from failure: Finally, leadership needs to allow teams to embrace failure (though one could argue otherwise about "execution" failures => https://www.forbes.com/sites/elandekel/2012/11/28/why-did-apple-fire-the-maps-product-manager ) as a learning opportunity. By analyzing what went wrong and using that information to inform future product development efforts, teams can continuously improve and iterate until they achieve success (you do Sprint Retrospectives in your agile squads, but how often do you take a step back to look at the bigger picture beyond the specific Agile Sprint cycle?).

What if you are the product lead/ executive in charge (of not just hitting certain metrics but overall product success)? Here's what to consider. Very few formulate and embed a hypothesis-driven product strategy effectively within their Product Discovery:

a. Start with a hypothesis,

b. Pick the right problem,

c. Test your solution - pivot, and re-discover as needed.

A meaningful hypothesis has at least these components:

your target market,

a measurement,

an experiment.

• Target market: The hypothesis should clearly identify the specific population or group it is addressing.
• Measurement: A good hypothesis should propose a measurable outcome or set of metrics that can be used to evaluate the effectiveness of the proposed solution.
• Experiment: The hypothesis should be testable through an experiment or other means of data collection to determine whether the proposed solution achieves the desired outcome.

The credence is your faith or acceptance of a key assumption in your target market to be true (unless proven false). It should be developed as a written assumption to formulate the hypothesis (that via lean experimentations could be turned into a thesis). A meaningful hypothesis just like a useful User Story has to be INVEST(able). INVEST acronym: Independent, Negotiable, Valuable, Estimable, Small, and Testable. I like how AgileForAll elaborates on this.?For Hypothesis formulation, however, SMART (Specific, Measurable, Actionable, Repeatable, & Testable) is a better acronym choice here. Yes, I just came up with this, bear with me, I'll elucidate with a more relatable example. I have a Guide for Landing Pages (it is how we run several of these measurements using analytics data with the team at InnovateFromZero).

The testable part is often what I found from my coaching sessions, which many PO/PMs miss. Test, test test! Always test yourself on the data you collect (empirical evidence without confirmation bias is the goal)!

Sample Hypothesis: By adding a chatbot feature to our site's Landing Page for customer support, we will reduce customer service response time by 50% and increase customer satisfaction by 20% within 3 months.

Key Elements (SMART):

The hypothesis proposes a specific action that can be taken to achieve a measurable outcome.

• Specific: The hypothesis identifies a specific feature/ benefit to be added (chatbot) to the customer support page.
• Measurable: The hypothesis sets clear metrics for success (a 50% reduction in response time and a 20% increase in customer satisfaction).
• Actionable Timeline: The hypothesis sets a specific timeline for achieving the desired outcomes (within 3 months).
• Repeatable: The hypothesis has specified and identified action steps for experimentation with a standalone variable parameter to repeat data collection or the entire experiment.
• Testable: The hypothesis can be tested through an experiment to gather data on response time and customer satisfaction before and after the addition of the chatbot feature.

Overall, this hypothesis follows the principles of lean methodology by focusing on a specific problem, proposing a specific solution, setting measurable goals, and defining a clear timeline for testing and learning.

Remember all of this (the market hypothesis testing part) is going on outside your "agile development" box - either at the discovery stage (or as a workshop attendee rightly asked me - what if some key insights were missed during discovery? - allow for a re-discovery process). Hypothesis testing is a key (and often ignored) part of the customer development process tied to sound Product Discovery success. The process involves stating a hypothesis, testing the problem and the solution, verifying the pivot, and then moving on to customer validation. The pivot is a way to make changes to the business model when the hypotheses don't meet reality. The key to successful hypothesis testing is to constantly test and iterate to ensure that the product meets customer needs and achieves product-market fit. Only by testing and pivoting can product leaders and entrepreneurs find a business model that will be successful in the long run.

To sum up, Hypothesise (turn "unknown" unknowns into "known" unknowns), Test (problem & solution fit), and Repeat (pivot as needed, re-discover). This helps to adopt the mindset - "keep firing the hypothesis, not the executive", and using validated customer feedback loops to inform product development decisions, we product executives can improve the odds of developing more successful products and avoiding unnecessary turnover and morale issues in our teams. Wanna discuss Product Discovery? I will welcome you to share your own experience here/ give me a shout.