<ol><li>Assess your first level opportunities by contrasting them against each other. </li><li>Do the same for the children of the opportunities until you reach one you'd like to test</li></ol>Criteria:<ul><li>Number of users and customers affected</li><li>Frequency of the problem</li><li>Market factors</li><li>Company factors</li><li>Customer factors</li></ul>

Prioritizing Opportunities

A team can run around 15-20 discovery iterations a week. The tools that should be in a team's toolbox are:<ul><li>unmoderated user testing: allows you to test a prototype with participants at their own time, for which you get a video of their work</li><li>one-question surveys</li><li>database data. E.g. what people are searching in the search bar</li></ul>What not do to:<ul><li>avoid overly complex simulations</li><li>not defining evaluation criteria</li><li>testing with the wrong audience</li><li>designing for less than the best case scenario</li></ul>

Running Assumption Tests

The most important thing to clarify is the outcome, which should be narrow enough to be managed by the team realistically, but large enough open new opportunities.When exploring a new discovery space, the Product Trio (Developer, Designer, PO, but not limited to these roles) should start individually drawing out what they think the current experience of the customer is. It is important that everyone does it individually, at first, as to not bias each other when presenting. After exposing their opinions and discussing, it's time to merge all the experiences into one.

How to start

Ideas to recruit for continuing interviewing<ul><li>ask support from customer success teams: If a customer calls to cancel their subscription, schedule an interview; If a customer has a question about feature x, schedule an interview; If a customer requests a customization, schedule an interview</li><li>recruit in-app in specific user journeys</li><li>form a customer advisory board (recruit few loyal customers that you get to interview every month)</li></ul>

Recruiting for interviews

First, we imagine an existing solution for the opportunity. We map users and write the steps they need to do in the solution sequentially over time (e.g. User comes to create content -> Users opens the editing mode -> User edits content -> User publishes content)For each step we start writing its assumptions. E.g.User comes to create content:<ul><li>Desirability: Our user wants to create content.  Our user wants this on our platform.</li><li>Usability: Our user knows to create content on our platform.</li><li>Feasibility: Our platform is available for the user to create content.</li></ul>This continues for all steps.

Story-map solutions to find assumptions

Not all assumptions need to be tested. To identify what is more critical at this moment, we can prioritise them on a quadrant, in which horizontally we have scale of evidence (how much evidence we have for it to be true) and vertically importance of the assumption (how critical it is to happen so that the idea is possible). We then place each assumptions on the quadrant relative to each other. This is not a precise exercise, but rather one that helps us select what we know now. We then start with few of them from top-right corner (most important with the weakest evidence).

Prioritising Assumptions

When interviewing users, do not ask them direct questions, but try to elicit stories and past experiences. Once they start remembering events, dig deeper and excavate these stories in more detail to capture the full experience. Set this expectation from the beginning with the user.During an interview, imagine each user event is a story, so set the scene right (location, event that triggered it, other people involved in the scene, steps taken, failures, end state). After you collect your insights quickly in an interview snapshot, go back and update your experience map based on what you learned.

Continuous Interviewing

Different types of assumptions can exist for an idea: <ul><li>Desirability: Is the product wanted by users or has it been only mentioned once in a discussion? </li><li>Viability: Is the idea realistic for the business? Even the most desirable idea is not worth investing in if it is not profitable.</li><li>Feasibility: Do the law and regulations or technology allow it? </li><li>Usability: Is it usable enough for the user? Can customer actually do their tasks in good time? </li><li>Ethical: Should it be built, or is it against moral principles? Does it collect potentially dangerous data, that can be used for unintended purposes? </li></ul>

Identifying Hidden Assumptions

Imagine the problems users have as trees. The root of a tree is a big problem, that causes multiple other problems/branches to arise. Every branch needs to be different from the others, otherwise, it needs to be rethought. To decide whether an opportunity belongs to a tree, we need to ask:<ul><li>Is this opportunity framed as a customer need, pain point, or desire and not a solution? </li><li>Is this opportunity unique to this customer, or have we seen it in more than one interview? </li><li>If we address this opportunity, will it drive our desired outcome? </li></ul>

Opportunity-Solution Tree (OST)

<ul><li>Vertical Opportunities - not recommended, either add multiple branches into one root or do more research on sibling opportunities</li><li>Multiple parents -no opportunity should have two parents</li><li>Opportunities not specific - wishes and feelings do not constitute opportunities (eg I wish this had a good user experience)</li><li>Solutions in disguise - opportunities should not mean or use features, but needs</li><li>Capturing feelings as opportunities - Capture the cause of the feeling and not the feeling itself (e.g.  I feel frustrated when using the product)</li></ul>

Anti-Patterns of OST 

What is Continuous Discovery? It is a product management framework for embedding customer input on every product decision.  You know when a company does Continuous Discovery when members building the product have weekly discovery calls with customers to reach a desired outcome.

The definition of Continuous Discovery

To make this a reality, a team needs to live by: a) Being outcome-oriented: to think about the value they provide rather than the outputb) Being visual: expressing  ideas not only through written/spoken words, but also by drawing c) Thinking in continuous terms: to regard research not as a project, but as a continuous action done at any step they needd) Being experimental: to be bold to consider experiments and not fully-built features to validate assumptionse) Being collaborative: anyone can bring any input when brainstormingf) Being customer-centric: to think from the customer perspective

The mindset of Continuous Discovery

Metrics that can be used in product management:<ul><li>Business Outcomes (measures business value): e.g. number of customers, retention, number of users</li><li>Product Outcomes (measures how the business value is created through product): e.g. time saved performing an action, satisfaction during onboarding</li><li>Traction Metrics (measures usage of specific features): number of clicks on a feature</li></ul>Other important definitions: <ul><li>Lagging Indicators: usually business outcomes, measuring something after it has happened</li><li>Leading indicators: usually product outcomes, they can predict the direction of the lagging indicator</li></ul>

Outcomes

Having the right framework and process in place makes 80% of the work in product management.

"If you haven't had the good fortune to be coached by a strong leader or product coach, this book can help fill that gap and set you on the path to success." - Marty Cagan How do you know that you are making a product or service that your customers want? How do you ensure that you are improving it over time? How do you guarantee that your team is creating value for your customers in a way that creates value for your business? In this book, you'll learn a structured and sustainable approach to continuous discovery that will help you answer each of these questions, giving you the confidence to act while also preparing you to be wrong. You'll learn to balance action with doubt so that you can get started without being blindsided by what you don't get right. If you want to discover products that customers love-that also deliver business results-this book is for you.

books

Books

product

Product & Design

"If you haven't had the good fortune to be coached by a strong leader or product coach, this book can help fill that gap and set you on the path to success." - Marty Cagan How do you know that you are making a product or service that your customers want? How do you ensure that you are improving it over time? How do you guarantee that your team is creating value for your customers in a way that creates value for your business? In this book, you'll learn a structured and sustainable approach to continuous discovery that will help you answer each of these questions, giving you the confidence to act while also preparing you to be wrong. You'll learn to balance action with doubt so that you can get started without being blindsided by what you don't get right. If you want to discover products that customers love-that also deliver business results-this book is for you.

Teresa Torres is an accomplished writer whose work has resonated with readers around the world. Teresa Torres has published several books that explore a range of topics, from fiction to nonfiction, and has received critical acclaim for the ability to weave compelling narratives. Teresa Torres's writing style is known for its depth and authenticity, and has earned quite a loyal following of readers.

The definition of Continuous Discovery

Similar ideas to The definition of Continuous Discovery

Continuous Discovery Framework

Getting Started

The Opportunity Solution Tree