More on this book
Community
Kindle Notes & Highlights
Started reading
January 22, 2022
many companies put a heavy emphasis on delivery—they focus on whether you shipped what you said you would on time and on budget—while under-investing in discovery, forgetting to assess if you built the right stuff.
Discovery isn’t a one-time activity. A digital product is never done. It can and should continue to evolve. As we learn more about our market, as our customers’ needs change, as new technology becomes available, good products adapt.
Fortunately, in 2001, a group of engineers got fed up, went into the mountains, put their heads together, and came up with the Agile manifesto.
This book was written for product people (product managers, designers, and software engineers) who want to build products that their customers need and love.
The more folks involved in each decision, the longer it will take to reach that decision. You want to balance speed of decision-making with inclusiveness.
There are six mindsets that must be cultivated to successfully adopt the habits outlined in this book.
1. Outcome-oriented:
rather than defining your success by the code that you ship (your output), you define success as the value that code creates for your customers and for your business
Rather than measuring value in features and bells and whistles, we measure success in impact
2. Customer-centric:
We elevate customer needs to be on par with business needs and focus on creating customer value as well as business value.
3. Collaborative:
embrace the cross-functional nature of digital product work and reject the siloed model, where we hand off de...
This highlight has been truncated due to consecutive passage length restrictions.
4. Visual:
5. Experimental:
to do discovery well, we need to learn to think like scientists identifying assumptions and gathering evidence.
6. Continuous:
definition of continuous discovery: At a minimum, weekly touchpoints with customers By the team building the product Where they conduct small research activities In pursuit of a desired outcome
As our product-discovery methods evolve, we are shifting from an output mindset to an outcome mindset. Rather than obsessing about features (outputs), we are shifting our focus to the impact those features have on both our customers and our business (outcomes).
Starting with outcomes, rather than outputs, is what lays the foundation for product success.
We aren’t doing research for research’s sake. We are doing research so that we can serve our customers in a way that creates value for our business.
Much of the work when tackling an ill-structured problem is framing the problem itself.5 How we frame a problem has a big impact on how we might solve it.
If product trios tasked with delivering a desired outcome want to pursue business value by creating customer value, they’ll need to work to frame the problem in a customer-centric way.
To reach their desired outcome, a product trio must discover and explore the opportunity space. The opportunity space, however, is infinite. This is precisely what makes reaching our desired outcome an ill-structured problem.
the right problem framing will help to ensure that we explore and ultimately ship better solutions.
Opportunity solution trees are a simple way of visually representing the paths you might take to reach a desired outcome.
The opportunity solution tree helps teams take large, project-sized opportunities and break them down into a series of smaller opportunities.
most of the decisions that we make in discovery are reversible decisions.
If we do the necessary work to test our decisions, we can quickly correct course when we find that we made the wrong decision. This gives us the luxury of moving quickly, rather than falling prey to analysis paralysis.
some have come to believe that product managers own defining the problem and that designers and software engineers own defining the solution. This sounds nice in theory, but it quickly falls apart in practice.
the best designers evolve the problem space and the solution space together.9 As they explore potential solutions, they learn more about the problem, and, as they learn more about the problem, new solutions become possible.
When we learn through testing that an idea won’t work, it’s not enough to move on to the next idea. We need to take time to reflect. We want to ask: “Based on my current understanding of my customer, I thought this solution would work. It didn’t. What did I misunderstand about my customer?”
We then need to revise our understanding of the opportunity space before moving on to new solutions.10 When we do this, our next set of solutions get better.
While many teams work top-down, starting by defining a clear desired outcome, then mapping out the opportunity space, then considering solutions, and finally running assumption tests to evaluate those solutions, the best teams also work bottom-up.
The tree structure makes it easy to communicate the big picture while also diving into the details when needed. Your tree should visually show what solutions you are considering and what tests you are running to evaluate those solutions.
