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.

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.

Metrics that can be used in product management:

• Business Outcomes (measures business value): e.g. number of customers, retention, number of users
• Product Outcomes (measures how the business value is created through product): e.g. time saved performing an action, satisfaction during onboarding
• Traction Metrics (measures usage of specific features): number of clicks on a feature

Other important definitions: 

• Lagging Indicators: usually business outcomes, measuring something after it has happened
• Leading indicators: usually product outcomes, they can predict the direction of the lagging indicator

Ideas to recruit for continuing interviewing

• 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
• recruit in-app in specific user journeys
• form a customer advisory board (recruit few loyal customers that you get to interview every month)

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:

• Is this opportunity framed as a customer need, pain point, or desire and not a solution?
• Is this opportunity unique to this customer, or have we seen it in more than one interview?
• If we address this opportunity, will it drive our desired outcome? 

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

1. Assess your first level opportunities by contrasting them against each other. 
2. Do the same for the children of the opportunities until you reach one you'd like to test

Criteria:

• Number of users and customers affected
• Frequency of the problem
• Market factors
• Company factors
• Customer factors

Different types of assumptions can exist for an idea: 

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

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:

• Desirability: Our user wants to create content.  Our user wants this on our platform.
• Usability: Our user knows to create content on our platform.
• Feasibility: Our platform is available for the user to create content.

This continues for all steps.

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).

A team can run around 15-20 discovery iterations a week. The tools that should be in a team's toolbox are:

• unmoderated user testing: allows you to test a prototype with participants at their own time, for which you get a video of their work
• one-question surveys
• database data. E.g. what people are searching in the search bar

What not do to:

• avoid overly complex simulations
• not defining evaluation criteria
• testing with the wrong audience
• designing for less than the best case scenario