More on this book
Community
Kindle Notes & Highlights
remember to track the long-term connection between your product outcome and your business outcome.
By far the most common mistake teams make when instrumenting their product is that they turn it into a massive waterfall project, in which they think they can define all of their needs upfront. Instead, start small.
Desirability isn’t enough. Viability is the key to long-term success.
Unfortunately, it’s not enough to drive product outcomes. The connection between our product outcome and our business outcome is a theory that needs to be tested.
The fruit of discovery work is often the time we save when we decide not to build something.
“The more leaders can understand where teams are, the more they will step back and let teams execute.” — Melissa Perri, Escaping the Build Trap
It’s not enough to do good discovery if you aren’t bringing your stakeholders along with you.
Even in companies that espouse a focus on outcomes, we still tend to spend most of our time talking about outputs.
When meeting with stakeholders, don’t start with your conclusions. Instead, slow down and show your work.
a good product trio knows to continuously manage stakeholders. Share your work along the way, rather than all at the end.
Even in the most challenging situations, the teams I’ve worked with have chipped away at getting more access to their customers. They’ve taken a continuous-improvement approach to the challenge. If they have never talked to a customer, they start small and try to find a single customer to talk to. If they can’t do even that, they start by talking with someone who is similar to their customers.
Many product teams aren’t allowed to do discovery. They still work in a feature-team or delivery-team model, where business stakeholders tell them what to build. If this is you, don’t worry—there is hope. Remember, I worked this way for years. You can still work on developing continuous discovery habits yourself. When you are asked to deliver a specific solution, work backward. Take the time to consider, “If our customers had this solution, what would it do for them?”
“If we shipped this feature, what value would it create for our business?” Refine your answer until you get to a clear metric—that’s your outcome.
As you work on requirements for the solutions you were asked to build, remember to story map your ideas. Use your story maps to identify hidden assumptions. Even if you don’t have the infrastructure to quickly prototype or test your assumptions, being aware of your assumptions will help you notice the evidence around you that either supports or refutes them. When you uncover a faulty assumption, work with your stakeholders to evolve the idea. Better yet, when a stakeholder brings a solution to you, story map and identify assumptions with them. The idea will improve right then and there. Work
...more
If you already do Scrum retrospectives, it’s easy to add a couple of reflective questions to this meeting to also reflect on your discovery process. I encourage my teams to ask, “What did we learn during this sprint that surprised us?” This could be anything from a feature release didn’t have the expected impact, we learned a new insight in a customer interview, or we ran into a feasibility hurdle that required us to redesign a solution. Make a list. Then, for each item on the list, ask, “How could we have learned that sooner?” The answers to these questions will help you improve your
...more
Surprises help us improve. Take the time to learn from them.
I encourage you to consider what you can do and let go of the “That would never work here” mentality that is so easy to fall into.
I’ve met dozens of teams who have never talked to customers because they believe they aren’t allowed to. However, they regularly engage with customers outside of work.
Don’t let perfect be the enemy of good. Get started by talking to anyone who is like your customers.
