Vladimir Oane's Key Ideas from Continuous Discovery Habits
by Teresa Torres

1. Begin with the end in mind. Decide the main business outcomes that require discovery.
2. Assemble the team, a trio (ideally) made of a product manager, a designer & an engineer.
3. To reach the desired outcome(s), a product trio must discover & explore the opportunity space. This is done using continuous interviewing and experience maps.
4. Opportunities are constantly evolved and ranked.
5. Finally, discover the solutions that will address those opportunities and thus drive our desired outcome.

Only then delivery can begin. 

We are thought that products have to solve problems to be valuable (vitamin vs aspirin analogy). But the best products started without a clear problem to solve. Facebook, Disney etc....

Opportunities encompass customer needs, pain points & desires. Think opportunities, not problems.

Be aware: the opportunity space is ♾ infinite. So the core job of the product team is not only discovering the opportunities but framing them in a way that makes them actionable. 

Is a simple way to visually represent the path one may take to reach a milestone. It is the main system of record for tracking the discovery process:

• The root of the tree is the desired business outcome
• Next are the opportunities, the needs, and desires of the customers we can piggyback on
• Next is the solution space. This is what we are considering building. 
• Below are the assumption tests

Using this visualization creates a shared understanding for the whole team which makes decision-making transparent. It keeps everyone on the same page & eliminates fighting over which feature to build next.

"Should we build this feature?" is a question product people ask themselves a lot. It's a mistake. 

• Instead, develop a "compare and contrast" mindset. Ask instead "which of these customer needs is more important?". 
• Instead of falling in love with your first idea ask "What else can we build?". 

Managing by outcome is only as good as the defined outcome. There are 3 types, starting from the general to the actionable:

• Business outcomes start with financial metrics(revenue, costs) or market share. 
• Product outcomes. Measure how the product drive value. 
• Traction Metrics. Track usage of specific features. 

Business metrics are usually lagging indicators. They are hard to impact in an agile environment. Product outcomes are better. To get more specific KPIs could be used. 

• They are negotiated between the team of designers, product & engineering people on one hand, and the leadership.
• Ambitious outcomes work better than SMART goals. 
• Some learning missions should proceed with performance outcomes. "Improving retention is a useless goal if you don't understand what causes the churn". 
• No individual outcomes. They have to be felt by a multidisciplinary product team. 
• Don't chase too many outcomes. One or two per quarter should be enough. 

It represents an artifact that helps a team uncover opportunities. It starts with a question related to the outcome (for example "how do people entrain themselves with videos?" if the goal is to increase time spent with a streaming app):

• Each member of the team shares a doodle of the answer from the user perspective
• Drawings not words
• Compare images and co-create a shared experience map
• Isolate individual moments and connect them with arrows

Customers don't know what they want but talking to them is still useful. "What needs, pain points or desires matter the most?" is the fundamental question:

• Instead of direct questions ask users to share stories about their experience. We lie to ourselves all the time so direct questions are unreliable
• Have interviews every week. Even 5 min ones. Productize scheduling by asking people who are using your product
• It should not be the responsibility of one team member. Everyone should participate
• Build a simple database with interviews: name, picture, a memorable quote, insights & opportunities

The insights from interviews should allow a product team to evolve a map of opportunities that could be considered for solutions:

• The map is presented as a tree. Some parent opportunities can have multiple nodes. The product team needs to combine similar ones or maintain a hierarchy.
• Each opportunity can have a count of how many times it came up during interviews.
• Ideally, an opportunity should match a step in the experience map so everyone understands it better.

No matter how disciplined the team, the map will be messy. Embrace the messiness. Don't try to make it more scientific than it needs

Once the product team decides to pursue an opportunity solutions can be considered:

• Avoid brainstorming - an illusion of group productivity. Groups generate few similar mediocre ideas. Best ideas are generated alone and discussed as a group.
• Ideally, you should have 10-15 solutions per opportunity.
• Each proposed solution comes with hidden assumptions that need to be understood and tested against. 

Every proposed solution is based on assumptions, which are hard to spot. One way to spot them is to imagine the solution is already functional and then draw a story map with all the steps. Assumptions will become clear:

- The user will engage with our product: Desirability Assumption. Are we sure he will?

- The user will follow the steps in our imagines solution: Usability Assumption: Are we sure the flow makes sense?

- The whole system will work: Feasibility Assumption: Are we sure we can build it?