A CRASH COURSE
What is “Continuous Discovery”?
One half of dual-track agile.
*August 8, 2019 update: we hosted a webinar on Continuous Discovery in Product-Led Companies with our friends Pendo. Check out the recording here and the full deck here.*
__________
The idea behind “Continuous Discovery” underpins a lot of what we do here at GLIDR. So let’s take a moment to outline why we believe it’s so important.
First, a level-set on definitions:
Product Discovery is an attempt to answer the question: “What should we build?”. It’s a process that helps product teams evolve and refine their ideas based on their customer’s needs so that the product delivers more value.
So, Continuous Discovery is doing that on a regular basis, as part of the team’s weekly work. It’s a sustained practice of experimentation and customer conversations to inform product development decisions. It’s not a new concept. Marty Cagan wrote this Silicon Valley Product Group blog post entitled simply, “Continuous Discovery” way back in October of 2012.
Product Delivery, on the other hand, is an attempt to answer the more technical question: “How should we build it?”. The huge implication here is that you’ve already figured out exactly what you should build. No team, no matter how collectively genius, can reliably guess the very best product to build without conducting a lot of product discovery.
Cagan continued his delightfully simple blog title trend in October of 2015 with this post: “Discovery vs. Delivery”, which walks us through the key differences.
Why is this important?
Increasingly, the difference between world-class product teams and the rest is the degree to which they conduct continuous discovery. That may sound like hyperbole, but it’s not.
The vast majority of new products and features fail. If your team could focus on building only those products and features that would add the most value to your customers, think of how much more successful you’d be. 🤔
This is especially true for so-called “product-led growth” companies. Product-led growth is increasingly becoming the go-to-market strategy of choice, especially for software and services companies. It’s difficult to execute well though. Your product has to be a pleasure to use and deliver immediate value.
Far easier said than done.
Delighting your customers is of critical importance for product-led growth companies and continuous discovery is one of the best known methods for improving delivered value on a sustained basis.
Consider the imbalance at most companies today: product teams spend more time in issue tracking and task management tools like Jira than any other tool. Therefore, they spend a lot of their time focused on product delivery. By comparison, they spend a tiny fraction of their time focused on product discovery.
It’s the equivalent of getting tied up fixing the print capability of MapQuest instead of building a GPS-enabled mobile maps app.
Say your team has just shipped a new feature. You feel confident because you’ve run sophisticated pre-launch experiments and post-launch product analytics and you have data that shows that your users are engaging with the new feature and seem to understand it. But could your development time have been better spent on something else? Something that brought even more value to the customer? You wouldn’t be able to answer this question unless you had a constant finger on the pulse of the customer’s “job-to-be-done”.
This is how you ruthlessly prioritize.
By investing more energy into discovery, on a sustained basis, product teams can build more impactful products and make better roadmap decisions.
How can I make continuous discovery part of our culture and process?
The single best way to make continuous discovery part of your team’s culture is to bake it into your delivery process. This allows the discovery process to piggyback on your already established delivery processes. Many product teams have delivery processes that they might even call rutted. The team begins to feel like a feature factory. Nobody’s quite sure why most new launches fail to live up to expectations.
Modernize and improve your product development process by making your roadmap discovery-driven.
How? Make sure that every roadmap and backlog item is clearly linked to the supporting discovery activities. Any qualitative or quantitative data, like user interviews or A/B tests, should be associated with the to-be-shipped product or feature in your product management software.
The “why” should be obvious and tied to each item on the roadmap.
Cagan summarizes this way:
“the discovery track is continuously generating product backlog items, and the delivery track is continuously building, testing and deploying these items.”
He goes on to note that a Kanban process may be preferable to a Scrum process as product teams move away from time-boxing and towards continuous delivery (also known as dual-track agile) and discovery.
Teresa Torres recommends using an Opportunity Solution Tree, where you begin with a clear desired outcome, then discover opportunities that drive that outcome, then discover solutions that deliver on those opportunities. From those solutions, your team can begin to design experiments to test and refine the solutions, starting with low fidelity tests and then increasing fidelity as evidence mounts.
Some specific additional tactics include:
- Talking to customers at least once per week.
- Running experiments to test product ideas.
- Conducting generative and evaluative research to flesh out product opportunities.
- Continually testing and evaluating features already in production, and pruning out those that clearly aren’t delivering value to the customer.
Despite the growing evidence that the effective practice of continuous discovery is one of the major contributing factors to today’s most successful product teams, most of the well-known product management tools don’t have spaces to collect, organize, and analyze discovery activities.
This is the #1 reason why we’ve evolved our own product, GLIDR, to incorporate a product canvas. It helps you reorient out-dated, feature-based roadmaps which have essentially become just backlog lists. They emerge as more strategic, discovery-driven roadmaps that focus on optimizing for delivered customer value.
Any item on your roadmap can be clicked to reveal all of the connected evidence.
With our new Intercom integration, that includes key pieces of user feedback. Now, in the view above, any user feedback pertaining to a particular product idea can be seen on the Evidence tab. No more hunting around myriad data silos to find that one VIP user quote from the other week.
Over time, GLIDR becomes your team’s centralized system of intelligence for all things related to your product management.
Try it for yourself. Take GLIDR for a free two-week spin.
Thoughts? We’ll happily answer your comments below.
