Once the product team decides to pursue an opportunity solutions can be considered:<ul><li>Avoid brainstorming - an illusion of group productivity. Groups generate few similar mediocre ideas. Best ideas are generated alone and discussed as a group.</li><li>Ideally, you should have 10-15 solutions per opportunity.</li><li>Each proposed solution comes with hidden assumptions that need to be understood and tested against. </li></ul>

Discovering the Solution Space

The insights from interviews should allow a product team to evolve a map of opportunities that could be considered for solutions:<ul><li>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.</li><li>Each opportunity can have a count of how many times it came up during interviews.</li><li>Ideally, an opportunity should match a step in the experience map so everyone understands it better.</li></ul>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

Opportunity Mapping

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

Best Practices For Setting Outcomes

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?

The Hidden Assumptions

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

Keystone Discovery Habit: Continuous Interviewing

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

Continuous Discovery Framework

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:<ul><li>The root of the tree is the desired business outcome</li><li>Next are the opportunities, the needs, and desires of the customers we can piggyback on</li><li>Next is the solution space. This is what we are considering building. </li><li>Below are the assumption tests</li></ul>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.

The Opportunity Solution Tree

Managing by outcome is only as good as the defined outcome. There are 3 types, starting from the general to the actionable:<ul><li>Business outcomes start with financial metrics(revenue, costs) or market share. </li><li>Product outcomes. Measure how the product drive value. </li><li>Traction Metrics. Track usage of specific features. </li></ul>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.

Types Of Outcomes

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):<ul><li>Each member of the team shares a doodle of the answer from the user perspective</li><li>Drawings not words</li><li>Compare images and co-create a shared experience map</li><li>Isolate individual moments and connect them with arrows</li></ul>

Visualize what you know: Experience Map

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.

Opportunities (Not Problems)

"Should we build this feature?" is a question product people ask themselves a lot. It's a mistake. <ul><li>Instead, develop a "compare and contrast" mindset. Ask instead "which of these customer needs is more important?". </li><li>Instead of falling in love with your first idea ask "What else can we build?". </li></ul>

"Whether Or Not?" vs "What Else?"

Agile methodologies revolutionized how products are being built. But building is just half of the problem. Deciding what to build is just as (if not more) important. Deciding what to build is discovery. Shipping is delivery. Discovery needs to be treated as an activity on its own. With clear activities, tracking and deliverables, just as we do with delivering working products.

Delivery vs Discovery

Customer Discovery requires a certain mindset. That is more important than a framework:<ol><li>Outcome-oriented: success should be defined by the impact of the code not the quantity of the code.</li><li>Customer-centric: the user is the key shareholder.</li><li>Collaborative: no more of the "PdM decides, the designer designs & the engineer builds" approach.</li><li>Visual: more imagery and mapping and less written ideas.</li><li>Experimental: ship experiments not features.</li><li>Continuous: Customer discovery never ends. </li></ol>

Mindsets For Customer Discovery

We’ve collected a list of our favourites on a range of topics from entry-level to expert.

books

Books

problemsolving

Problem Solving

business

Business

leadershipandmanagement

Leadership & Management

communication

Communication

Top 7 books for Product Managers

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

startup

Startups

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.

"Whether Or Not?" vs "What Else?"

Similar ideas to "Whether Or Not?" vs "What Else?"

Keystone Discovery Habit: Continuous Interviewing