Embedding Continuous Product Discovery Mindset
Because sharing the responsibility of product discovery unlocks more satisfying outcomes
In the late 1950’s, the world experienced one of the largest economic decisions that was credited to country-wide famine and ecological imbalance.
This mistake was credited to a single decision by a HIPPO (highest paid person’s opinion), who heeded the advice of trusted advisors close to him, rather than take careful steps based on analysis, evidence and experiments.
What was this mistake, you ask?
It was the ‘Smash Sparrows Campaign’, a part of the ‘Four Pests Campaign’, which was the centre stone of Mao Zedong's Great Leap Forward mandate in China between 1958 and 1962.
The… ‘Smashing Sparrows Campaign’?
The Smashing Sparrows Campaign sought to eliminate sparrows from China, thought to be one of the four most harmful pests to crops and public health. The other three pests were specifically rats, flies, and mosquitos.
By removing all four pests, Mao Zedong thought we could rebuild the country from an agrarian (rural) economy into a powerful, productive, industrialised society.
While there were broadly positive yet mixed success with the elimination of the first 3 pests, the Smash Sparrows Campaign was by far the worst for many reasons. While Sparrows were believed to be pests that consumed grain seeds and hence crop yield and productivity, the campaign had several unintended consequences:
Mass killing of sparrows led to lower an excess number of crop eating insects that could not be removed without the sparrows.
Crop-eating insects began to rise significantly (given that they reproduce far faster than what birds can via laying eggs)
Agricultural productivity significantly fell, not helped by concurrent droughts and floods, contributing to the devastating Chinese famine.
What Can We Learn From This Tale?
The Four Pests Campaign serves as a cautionary tale about the importance of considering the broader consequences of actions.
Experimentation and testing can help identify potential pitfalls and unintended outcomes before implementing large-scale policies or campaigns.
It emphasizes the need for careful planning, consideration of ecological systems, and a willingness to adapt based on real-world results.
If only this decision could have been prevented with a more considered, ongoing discovery and experimentation mindset, with frequent review points based on evidence and results.
A Solution to Preventing One-Off Assumption-led Failure: Continuous Discovery
Continuous Product Discovery, popularized by Teresa Torres, leading coach and author of 'Continuous Discovery Habits', is an approach in product development where the process of discovering, defining, and refining a product's features and capabilities is ongoing and iterative.
In this approach, teams consistently engage in customer activities such as user research, testing, and feedback collection throughout every phase of the product development lifecycle. This ongoing discovery helps teams stay responsive to user needs, market changes, and emerging opportunities.
The main benefit of continuous discovery is the organisational capability for respecting the value of research and learning, while resulting in greater customer-focussed outcomes and value compounded over time.
As Teresa Torres states in her book Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value:
“The beauty of a continuous discovery process is that we can always course-correct as we learn. So, as you assess and prioritize the opportunity space, relax. Make the best decision you can, given what you know today, and know that, if you got it wrong, we’ll simply revisit the decision when we need to.”
— Teresa Torres
Why Many Organisations Feel Prevented from Adopting A 'Discovery' Mindset
If continuous discovery could give us so many benefits in motivation and organisational value creation, why wouldn’t all companies adopt it from the get-go?
The reason lies in some more internal, structural issues that prevent organisations from implementing it at scale, such as:
Organisational Inertia: referring to an organization’s unwillingness or inability to adapt to changing circumstances. The larger the inertia, the more force it takes to effect change. There are tree types, according to Richard Rummelt, writer of Good Strategy / Bad Strategy:
Inertia of routine: when organisations are too reliant on its pre-existing routines that previously generated success. This is often coupled with organisational responsibilities that do not change to adapt to market circumstance;
Cultural inertia: when there is a resistance to change, unless change is already occurring within an organisation. This is almost always exacerbated by management perception that learning is a cost-centre, not a value enabler.
Inertia by proxy: when an organization chooses not to respond to changes in the market, because their existing revenue streams are still profitable.
Organisational Entropy: Organisational entropy is when poorly managed companies become less organized and less focused over time, leading to even more poor management. An endless loop. Derived from the second law of thermodynamics, stating that closed systems tend to get more disorderly over time.
Over ambitious strategy: when business strategy aims to achieve too many outcomes across many departments, teams lose their ability to focus on the few areas that do drive significant value. This spreads resources thin, where no initiative is performed to the quality that is needed.
Pre-existing commitments: especially in environments that have project-based revenues, where features are built according to contracts stipulating solution requirements, the habit of learning and discovery can easily be put in the back seat.
Restricted budget and costs: when there is no budget allocated, product managers, designers or engineers may never have the funds to conduct the research they need to gain insights. Need $10k to run a quantitative survey for 2,000 consumers? You’re out of luck: find another (free) method that is equally as representable.
To prevent you perilously experiencing these pitfalls, I vouch for a carefully executed approach to showing the value of discovery, making it a fun experience for all the stakeholders and senior management along the way.
My 5 Steps for Inculcating Scaled Continuous Discovery
Below, we dive into the key steps I see to inculcate a culture for continuous discovery, namely:
Form Trio & Run Discovery Weekly Reviews
Facilitate Outcome Opportunity Mapping (w/ Stakeholders)
Prioritise Opportunities & Map To (Experiments / Research) Topics
Conduct Discovery (Ideally With Stakeholders)
Summarise Experiments or Discovery Results (With Clear Action Plans)
Step 1. Form the core ‘Product Trio’ and schedule weeklies for discovery and learning
Teresa Torres suggests to source a core Product Trio (e.g., Product Manager, Researcher / Designer, Engineering Manager) to interview customers or other research activities to learn from customers, weekly.
I vouch for extending this weekly cadence towards a frequent review meeting as well, with the objective of aggregating insights, and potentially reviewing which discovery topics and methods to use and prioritise for the upcoming month.
The Trio has three shared responsibilities, answering questions related to:
Feasibility: whether something is possible;
Usability: whether customers understand how to use (it);
Desirability: whether customers / users want (it); and
Viability: considers if (it's) sustainable or profitable.
Note that the Trio doesn’t simply take a question each to work on and reports back later. The three questions are shared across the entire trio: it is a shared responsibility where each member inputs and agrees to come to a group decision together.
Note that there is no defined activities required by these three roles, however, the usual tasks done per role are:
Product Manager = The captain of the ship, defining product vision and strategy and ensuring a solid understanding of customer needs, market trends, and the competitive landscape. They roll-up their sleeves to unblock the trio and their team in shipping whatever deliverable they decide best with (ideally with their stakeholders).
Engineering Manager = The builder. An ideator of technical solutions and dependencies, implementation specifics and risks. Engineers bring the product to life, working on technical aspects, turning design concepts into a functional product.
Designer = The artist. Designers focus on the user experience and how the product looks and feels. They translate the product manager's vision into tangible designs, considering user interface, interaction, and visual aesthetics. Designers also collaborate closely with the product manager to understand user needs and feedback.
Bonus: Using Substitutions When Trios Aren’t Always Available
How your Trio and stakeholders get organised depend greatly on the enablement and operational teams you have in your company. The bigger the company, the more of these teams and more stakeholders to bring into your discovery weeklies. Conversely the smaller your company, the fewer people to fill in your trio, especially if you don’t yet have a designer.
I like to picture discovery as an endless game of basketball. I see the Trio as your starting line-up, while all your stakeholders are on the Bench, still part of the team, but willing to take on any of the roles necessary to ensure discovery can still continue.
Different individuals from the bench can act in various roles in the Trio, rotating as needed, to ensure that the group is continuously learning and discovering. This is so you don’t waste time waiting until all three members are present before continuing. For example:
Missing your PM? Perhaps someone close to the customer pain points (e.g., customer success, operations, customer services teams) can fill in the gaps, to ensure that the designer and engineer can continue discovery.
Unable to source a designer? (or don’t yet have one as you’re too young a start-up?) Your PM can take the designer role, while ceding their project management and customer problem statement tasks to customer success (as above), or simply ask Sales or Partnerships to attend given their daily involvement with customers to.
Missing your engineer? There might be a substitute technical resource within your Integration Management team, whether a pre-sales engineer who knows code, or someone who used to be an engineer manager in the team. Likewise, someone from Legal and Risk could provide inputs on viability through listing out legal risks per opportunity.
While you can’t always substitute the roles completely (e.g., engineering manager substitutes should know technical elements, such as code) you can always encourage learning and development through your bench, increasing trust and conviction with your stakeholders along the way.
Whatever your Trio composition, the outcome still remains fixed: gain new insights, give value to lessons learned, define and align discovery topics while also analysing completed research and analysis for next steps.
Customer Interviews vs. Testing Assumptions
Instead of performing opportunity mapping one-off, Teresa Torres advocates for product trios and stakeholders to find time in their calendars to continually conduct explicitly two types of activities:
Customer interviewing: to helps us uncover new opportunities, and
Assumption testing: helping us discover solutions and small experiments to clear out (validate or invalidate) assumptions.
When interviewing customers, our goal is to discover customer needs, pain points, and desires (aka “opportunities”) that, if we were to address them, would help us drive our outcome. Opportunities emerge from customer stories. Review opportunities alongside your existing prioritisation review meetings or roadmap reviews.
You can review the results and action plans with your stakeholders on the weekly meeting, to gain data on the magnitude of the problems we want to solve, allowing you to prioritise opportunities in Step 3.
Agenda of Discovery Meetings
Your weekly meetings can be as short as 30 minutes to conduct quick research itself, or extended to 60 minutes to involve stakeholders in prioritisation and summaries.
Weekly meeting agendas may contain:
Customer interviews themselves
Discussion of which discovery topics to dive into the upcoming weeks, including topic prioritisation;
Discussion of assumptions that need to be validated, perhaps with quick experiments to quickly test, measure and learn; and
Quick summary of insights and lessons learned from experiments and research conducted in the previous week (e.g., fortnightly, if summaries need time to be consolidated)
Step 2. Run Recurring Opportunity Mapping Sessions With Stakeholders
I previously wrote about the Outcome Opportunity Map exercise you can conduct with your stakeholders in this blog post on instilling outcome-drive mindset with stakeholders.
This post still holds true and is the basis for your discussions with stakeholders on which opportunities to pursue, which discovery methods to use, and why.
I argue that these mapping sessions be continued, but organised and facilitated by the trio in a cadence (e.g., monthly) that makes sense based on the iteration cycles you have in your organisation, when you need to review, refresh or revisit your strategic priorities (aka roadmaps).
Step 3. Prioritise Opportunities, Then Map Out Experiments or Discovery Exercises Needed
A good discovery mindset is to prioritise user problems, rather than just focussing on prioritising outputs and deliverables.
Prioritising problems can be in the form of many prioritisation techniques I wrote about previously. It doesn’t really matter which one you choose, so long as you have a constructive alignment with stakeholders based on their strategic priorities.
Once problems and opportunities have been prioritised for the upcoming month (in alignment with your normal prioritisation cadence when reviewing strategic priorities or roadmaps), then your Product Manager as well as your Trio, teams and stakeholders can ideate experiments that should be completed in order to gain data.
Step 4. Conduct Discovery and Experiments Involving Stakeholders
From your list of prioritised opportunities, it’s time to come up with Experiments or Discovery Topics that may be needed per each.
Your trio could also utilise different research methods that may compliment customer interviews, or use them as the basis for testing assumptions:
Analysis of existing product analytics tools and data (e.g., Amplitude)
Competitor benchmarking or analysis
Ishikawa problem solving / the five ‘whys’ technique
Rapid prototyping or design thinking
Usability testing sessions directly with customers
Simply running experiments that may involve configuration or short-cut development per your engineering leader feedback, among many more
Whatever method is chosen, find ways to include your stakeholders within the research methods as an optional ‘view only’ participant, or even as an interviewer if you have substituted a Bench member (stakeholder) for your designer or product manager!
Step 5. Summarise Experiments or Discovery Results with Clear Action Plans. Repeat.
After you have conducted your Discovery and Research activities, distilling findings is crucial. Your Trio should have analysed user interviews and tests, to uncover a clear set of insights, patterns or trends.
These insights form the basis for actionable plans, helping teams prioritize future Discovery efforts as well as any new features aligned with both the roadmap, product strategy and general user needs.
In the case of experiments, where statistical analysis is being conducted, make sure you have a defined set of measurable metrics and pass/fail thresholds over defined periods of time.
Remember that you want to have a Clear Action Plan for the three scenarios:
Surpassed ‘pass’ criteria: when an experiment validated hypothesis successfully with statistically significant results
In-conculsive: when findings and data don’t show any statistically significant results during the experiment (neither positive nor negative is still a lesson learned)
Performed well below ‘pass’ criteria: the opposite of scenario 1
In each case, have clear recommendations, whether to conduct more discovery, ‘call it quits’ and move onto another topic, or simply to add a new feature to the roadmap or backlog as required.
Final Thoughts
Embarking on the journey of embedding continuous product discovery within your organization, regardless of its size, is a powerful initiative. The cautionary tale of the Smash Sparrows Campaign reminds us of the repercussions of decisions driven solely by assumptions and lack of ongoing experimentation.
Continuous Product Discovery, as advocated by Teresa Torres, provides a solution—a mindset and approach that involves ongoing learning, adaptation, and responsiveness to user needs. However, the path to adopting this mindset may face hurdles like organizational inertia, cultural resistance, and budget constraints.
I’ve outlined a practical 5-step guide to inculcating discovery mindset across your organisation, but feel free to chop and change as you need. I recommended forming a Product Trio, conducting recurring opportunity mapping sessions with stakeholders, prioritizing problems over deliverables, involving stakeholders in experiments, and summarizing results with clear action plans create a structured approach to continuous discovery.
Now, it's over to you. Reflect on what resonated with you. What challenges do you foresee in adopting continuous discovery, and how do you plan to overcome them?
Hope you can share your thoughts in the comments below, connect with me on social media, or consider sharing this valuable insight with your network!