More on this book
Community
Kindle Notes & Highlights
Use a map you create for your product today to find opportunities, or to consider the opportunities you already have in the context of your product today.
journey maps. To make one for your current product’s experience, just map the flow users take through the major activities they engage in. Use this map to give context to your opportunities.
10 different products, we have to
As part of a project to discover how the products could work together in a better way, we formed a multidisciplinary team to map the entire end-to-end customer experience in finding, evaluating, purchasing, and using them, as well as getting help and adding more products and services.
We gained a lot of insight by being able to trace an end-to-end story rather than just a feature-based experience.
Various other stakeholders and teams were brought in to flesh out more detailed journeys that were all pegged to various points along the high-level skeleton journey, so that we captured and validated as much existing knowledge as we could.
Getting a good actionable product backlog out of an opportunity is going to take a lot of hard work; it won’t simply materialize for you.
It’s a deliberate process of discovery that initially focuses on learning a lot more about who, what, and why.
What problems are we really solving? What solutions could be valuable to our organization and to customers buying or adopting the product? What does a usable solution look like? What’s feasible to build given the time and tools that we have?
You can go one step deeper and map the way your users work today without your product, or with your current product. If you were playing along in Chapter 5, you built a story map about the way you do things today. Doing this for the way your users work today will help your discovery team really understand the problems they’re solving.
Visualize your user interface to build shared understanding of the solution.
A Design Studio is a fast, simple, and collaborative way to involve a large group in deliberate ideation, which is a flashy word for coming up with lots of possible ideas.
don’t worry if it’s the right person. Be ready to learn from exploring, and avoid worrying whether or not your selection is right — it probably is not.
Start with a simple or obvious example; the more concrete, the better.
Walk the map, selecting journeys that you think will teach you the most about your audience and their needs.
The difference between what you think people need and what they really need is the realm of product arrogance.
you can more quickly get to learning in context by building and validating one journey at a time.
The problem usually comes in when we focus on making everyone happy, and at the same time fail to focus on small, specific target outcomes. The result is a solution that’s much bigger than it needs to be.
our goal is to minimize the amount we build (our output) and maximize the benefit we get from doing it (the outcomes and impact).
cut away all the stories that weren’t necessary for it to reach that outcome.
That intersection of valuable, usable, and feasible for a specific target set of customers, users, and uses is a viable solution.
Viable means successful for a specific business strategy, target customers, and users.
once that first release goes live, the world will have changed, and that’s good. But it’ll also mean we’ll need to rethink the future releases in light of the new world we’ve created.
Specific business outcomes drive focus on specific users, their goals, and the activities they’ll engage in with your product. Focus on those activities drives focus on the specific features and functionality users will need to be successful.
Prioritize specific business goals, customers, and users, and then their goals, before prioritizing features.
all this stuff is a guess until we actually ship and observe what the market — our customer and users — actually does.
This leads me to one of the biggest mistakes people make, and that’s actually believing their minimal viable solution will be successful.
“the faster you deliver crap, the more crap you get.”
It’s called empathize because a critical outcome of doing the work is to understand how it really feels to be a user of your product.
do your best to understand what it’s like to walk in their shoes.
learn whether your solution really does solve someone’s problem.
You might be surprised that it could do that even with bugs.
part of design thinking is a way of working that emphasizes small, multidisciplinary collaborative teams working together quickly using simple models, sketching, and low-fidelity ways of documenting and communicating.
The Four Steps to Epiphany
the first thing you need to develop isn’t a product, it’s customers.
build-measure-learn.
One of the biggest flaws in traditional design processes is spending a very long time learning and designing
take my assumptions and guesses about who my users are, usually by sketching simple prototypes. I’ll describe how I think they work today by building simple “now” story maps. I’ll do this collaboratively with other people who have firsthand experience with users and customers.
in some situations I’ll do this involving customers and users directly.
We don’t wring our hands about this too much, because we know we’re probably wrong anyway.
we’ll work together to write a bulleted list of the things we believe are true, but if we find they aren’t, then we’ll need to rethink everything.
smallest prototype possible. In lots of cases, it’ll be hard to call it a prototype at all.
when your goal is learning, it is the smallest product you could build to learn.
It’s excellent because they found they were wrong after a couple of days of thinking and working, as opposed to finding out after weeks of a team building software.
your biggest challenge will be to learn to celebrate what you’re learning as opposed to worrying about being wrong.
In a Lean Startup approach, build means build the smallest possible experiment you can.
We hope to build simple prototypes in hours, not days.
We’re building to learn, and we expect most of our ideas to fail, or at minimum, need some adjustment to be successful.
you segmented your release backlog into stories to take on early to learn, in the middle to build up, and later to refine.
small, productive conversations where the right people work together to tell the stories one last time, and in the process make all the tough decisions about exactly what they’ll choose to build.
