I find that many teams, especially those new to modern product techniques, are looking for a structured introduction to modern product discovery. In this chapter, I describe the concept of a discovery sprint.
A discovery sprint is a one‐week time box of product discovery work, designed to tackle a substantial problem or risk your product team is facing.
A discovery sprint is definitely useful for more than just transformation. It could just as easily be considered a discovery planning technique or a discovery prototyping technique. But I find it's most helpful in bringing all these things together, so I choose to include it here.
Some people use the term design sprint rather than discovery sprint, but as the purpose of the work—when done well—goes significantly beyond design, I prefer the more general term.
Further, if your company has been struggling with the concept of MVP, this is a very good way to start getting the value from this key technique.
A discovery sprint is a one‐week time box of product discovery work, designed to tackle a substantial problem or risk your product team is facing.
I first met the Google Ventures (GV) team many years ago when they were just getting started. They are part of Google's investment arm, but even more valuable to the startup than their money, GV created a small team to go in and help the companies they invest in get their product efforts off to a good start. Their model is to typically spend a week with the startup—rolling up their sleeves and showing them how to do product discovery by doing it with them side by side.
I also know several other proven product people, known as discovery coaches, who do essentially the same thing for the teams they are helping.
In any case, during this week of intense discovery work, you and your team will likely explore dozens of different product ideas and approaches, with the goal of solving some significant business problem. You'll always end your week by validating your potential solution with real users and customers. And, in my experience, the result is consistently big learning and insights—the kind of learning that can change the course of your product or your company.
Within this general framework, discovery coaches advocate a variety of different methods to help the team though the process and get big learning in just five days.
After working with more than 100 product teams, and refining their methods as they learned what worked well and what didn't, the GV team decided to share their learnings in a book. The book is titled, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, by Jake Knapp, John Zeratsky, and Braden Kowitz.
The authors lay out a five‐day week that starts with framing the problem by mapping the problem space, picking the problem to be solved and the target customer, and then progresses into pursuing several different approaches to the solution. The team next narrows down and fleshes out the different potential solutions, then creates a high‐fidelity user prototype—finally, putting that prototype in front of actual target users and observing their reactions.
And, yes, you can absolutely do this all in a week.
Sprint spells out the authors' favorite techniques to accomplish each of these steps, and if you've read this far, you'll recognize all of them. But what I like so much about the GV book is that, when teams are getting started, they often crave the structure of a proven, step‐by‐step recipe. The book spells out exactly this over nearly 300 pages, with dozens of examples from great products and teams you'll recognize.
There are several situations where I recommend a discovery sprint, starting with when the team has something big and critically important and/or difficult to tackle. Another situation where a discovery sprint helps is when the team is just learning how to do product discovery. And yet another is when things are just moving too slow and the team needs to recalibrate on just how fast they can and should be moving.
Sprint is another must read book for product managers, and I highly recommend it.
As teams moved to Agile methods (they usually start with Scrum), many companies decided to contract with or hire an Agile coach. These coaches help the broader team—especially engineers, QA, product managers, and product designers—learn the methods and mindset involved in moving to Agile.
Discovery coaches are typically former product managers or product designers and they have usually worked for, or with, leading product companies.
This sounds straightforward enough, but many problems arise because the vast majority of these Agile coaches don't have experience with tech‐product companies, so their experience is limited to delivery. Therefore, they would more accurately be considered Agile delivery coaches. They understand the engineering and release side of things, but not the discovery side of things.
So many product companies have experienced this issue that it created the need for coaches that do have deep experience with product companies and the key product roles, especially product management and product design. These individuals are often called discovery coaches.
Discovery coaches are typically former product managers or product designers (or former leaders of these areas) and they have usually worked for, or with, leading product companies. So, they are able to work side by side with actual product managers and designers—not just reciting Agile platitudes, but showing the team how to work effectively.
Every discovery coach has his or her preferred way of engaging with a team, but they are usually engaged with one or a small number of product teams for a week or so. During this time, they help you through one or more discovery cycles of ideation; creating prototypes; and validating the prototypes with customers to gauge their reactions, with engineers to evaluate feasibility, and with business stakeholders to assess whether this solution would work for your business.
It's hard for me to imagine an effective discovery coach who doesn't have first‐hand experience as a product manager or product designer at a modern product company. That's likely one of the main reasons there's a shortage of discovery coaches today. It's also important that the discovery coach understand how to include engineering in the mix—being sensitive to their time, but understanding the essential role they play in innovation.
Discovery coaches are not unlike Lean Startup coaches. The main difference is that Lean Startup coaches often focus on helping a team discover not only their product, but also their business model, and their sales and marketing strategy. Once the new business has some traction, the discovery is usually more about continuously improving an existing product in substantial ways rather than creating an all‐new business. Because of this difference, many Lean Startup coaches don't have the necessary product experience. My view is that product discovery is the most important competency of a new startup, so I believe an effective Lean Startup coach must also be very strong at product.