Introduction to Discovery
Just like a lot of people, I stumbled my way onto Product Discovery as a semi-organized process, I was doing parts of it. Reading "Inspired" by Marty Cagan lit the spark, with an impossible 10-20 tests a week". Reading "Continuous Discovery Habits" by Teresa Torres helped me place everything in order, and I want to help others gain the same knowledge.
My reasons to share this are a bit selfish:
If everyone involved in product creation knows what product discovery is and how to implement it, we'll find new and better ways of doing it
Here's how you can easily replicate the process and then dive into it, as deep as you want. In the post below, you'll learn and understand the following:
What is the difference between discovery and delivery
Why we need to do continuous discovery and delivery
The responsibility of a product professional towards each part
How to start the process
How to share the results and get value out of it
For me it started with the "Truth Curve". There are few variations of it, see one below.
I also have a version of it with a divider: Problem Fit (should we build it?) and Product Fit (can we create it as a business?), roughly between the Concierge and Wizard of Oz validation techniques (if not familiar, click the links)
It's a very rough division, which, in retrospect, ignores some aspects (i.e. that you need to address all the risks at every step). But it paints a vivid picture.
That idea someone shot past you by someone, or you have in your head? Perhaps fantasy. Nothing wrong with it inherently, just remember where it all starts. One saying stuck with me most of all: "Fall in love with the problem, not the solution". We'll get back to this through the article.
Why does it matter? Because a lot of the things product professionals do start of from the "live product" level. We have an idea, we discuss it, we might have even received it from someone higher up. We do research (mostly competitor research for existing products), we look at some data. We do the specs, design it, build it, measure the results and find out if it was worth our time. Even if the company for which you work isn't doing it (ask yourself if it's really not), others do. That naturally creates a lot of waste, frustration and lack of learning. Why does it still happen? Strong will from company managers, hierarchy-based organizations, but we'll discuss one reason we can affect - lack of product discovery.
See, when we're talking about creation of products, we're trying to address different types of risk (source):
Value Risk (would the customer buy this, or choose to use it?)
Usability Risk (can the user figure out how to use it?)
Feasibility Risk (could we build it?)
Business Viability Risk (would this solution work for our business?)
Here's what Teresa Torres has to say about these risks:
"The idea that a successful product is viable, feasible, and desirable has been around for years in the product industry. In trying to track down the origin, many people referred me to the IDEO Human Centered Design Toolkit. However, it may have been used even earlier by Anthony Ulwick, when he introduced the “Jobs to be Done” framework" (comment 47 in her book "Continuous Discovery Habits").
P.S. You can get Jobs To Be Done guide here
So, as product professionals (I'm saying this instead of "everyone involved in building a product"), we need to be constantly mindful of believability of the information we hold, and the level of effort required to reach a higher believability, and how we address each of the risks above.
Discovery and Delivery
As product professionals, we're constantly dealing with an influx of requests from multiple sources, competing with our ideas. Don't google "what a product manager does" if you're not willing to spend a few [frustrating] hours trying to understand how can a single role title encompass to many interpretations.
We're also less cooperative than we should be, some of us have (misleading) manager titles, others are domain-specific (design, backend, frontend, QA), yet others aren't perceived as part of the field (e.g. customer experience), while being vital to getting it done right.
So, we're often diving more and more into delivery. It seems costly to just let development teams sit and wait. It seems wasteful to have designers build prototypes for multiple ideas, and not the UI for that one thing we wish redesigned because it's "outdated". Pushing out feature after feature, investing too little time in thinking about the 4 above risks. Falling in love with the solutions, not the problems, opposite to what Marty Cagan advises:
"Why is this so important? Because, more often than not, our initial solutions don’t solve the problem—at least not in a way that can power a successful business. It usually takes trying out several different approaches to a solution before we find one that solves the underlying problem." ("Inspired", p 177-8)
We're falling in-love with delivery, because it has a predictable and addictive cycle: sprint planning, sprint daily meetups, review and retrospective, and back to planning the next day. Pushing output on a daily basis can play tricks on your mind, thinking you're being measured on filling the backlog with work for developers to do. Development teams doing Scrum might even be proud of their high velocity as a measure of their effectiveness. And there's no shortage of poorly thought-out ideas from your own head and other stakeholders that can fill up an infinite backlog, a roadmap, etc.
"There is an underlying theme you’ll see in all framing techniques, and the reason is that it’s just human nature for people to think and talk in terms of solutions rather than the underlying problems. This applies especially to users and customers but also applies to stakeholders in our business, other company execs, and if we’re honest with ourselves, it very often applies to us as well. This problem famously applies to startup founders. Founders will often stew on a potential solution for month, if not years, before they get the funding and the nerve to pursue it." ("Inspired", p 177-8)
That's where product discovery comes in: we're creating a separate cycle, which goes in lock-step with delivery, and mindfully splitting our time between it and delivery. Just like Continuous Delivery deals with the cycle of building our ideas, Continuous Discovery deals with the cycle of testing our ideas, or more accurately, discovery opportunities.
We're striving to create "Dual-Track Agile" or Dual-Track Development. This is a fascinating concept, and I highly encourage you to read the article from Jeff Patton explaining it. A huge side-benefit of this is sharing a lot of your work with the product teams, so you can empower them and free up everyone's time for more discovery. Consider it like this: if developers are busy building waste (features no one uses, or that don't move any metrics sufficiently), taking 10% of their time to participate in discovery, which will reduce waste by a larger % is worthwhile. Below are the illustrations of this concept. Take the time to read through it.
To sum up, delivery focuses on moving things through a pipeline from well-specified idea to a working product, and is measured by its efficiency, and is a vital part of providing users with the actual value, discovery focuses on "why" you're building that and not something else, and helps you decide what's more valuable to deliver.
Why Continuous Product Discovery?
First of all, Product Discovery is all about learning fast and answering the 4 risks above about potential solutions to any problem, so your focus would be on a desired product outcome, a value, e.g. "reduce anxiety" (from Bain's B2C pyramid of value) and not "gain new subscribers" (that could be a type of solution (but think of what user problem "gaining new subscribers" is solving...)). Instead of output, you'll start talking about outcomes and examining everything through that prism.
Another reason is that it's built on cooperation between product, tech and design (at least). By "forcing" you to cooperate from the problem stage on, instead of bringing them your conclusions and asking for their help only in their respective areas, product owners create better relationships as equals, instead of being perceived as a "client/customer" of development. If tech and design professionals don't participate in discovery with product owners, they'll completely miss out on potential solutions the product owner hasn't brought up, and even on the ability to correctly frame the problem at hand and explore multiple opportunities and solutions.
A third reason is that it moves much faster than other forms of testing you may be familiar with. Some may confuse discovery with A/B testing. While A/B testing requires significance, power, sample size, and tests competing solutions, discovery is focused on finding opportunities to meet a desired outcome via multiple solutions. Thus, it relies on more subjective signals, verifies if the problem was even correctly framed, and compares different solutions to each other, finding new opportunities along the way, and drilling down to the underlying assumptions, testing those (and not solutions) quickly and cheaply. A fourth reason is that product discovery "forces" you to start regularly talking to your customers via interviews (not only, but also), by setting the following benchmarks ("Continuous Discovery Habits", ch. 1) :
Weekly touch points with customers
By the team building the product
Where they conduct small research activities
In pursuit of a desired product outcome
And last, but certainly not least, discovery will help your stakeholder communication by shifting the discussions and debates from solutions, to opportunities and assumption examination. Especially with highly opinionated, competitor-minded stakeholders.
Why should it be continuous? Why not do it ad-hoc when you need to learn something?
"Customers and users are influenced by the people they hang out with—their communities, families, and friends. They’re also influenced by other technology —things available to them and on the market right now. Your customers and users don’t exist in a vacuum, and so their wants and needs change according to what’s around them. Likewise, your opportunities for how to address those wants and needs are constantly evolving. Directly controlling these surroundings is out of the hands of companies, so the only thing we can do is understand them better to know how to act." (Melissa Perri, "Escaping the Build Trap", p.11)
To sum up, discovery will be an outcome-driven activity, which will not only explore the "opportunity/solution" spaces (i.e. the "problem"), but will also help you acquire great new habits, and encourage cooperation.
The Product "Trio"
So, you're a product [owner, manager, designer, tech lead, analyst, etc.] and want to understand if you have a place in product discovery. The answer is rather short there is. The beauty of change initiation, is that while bottom-up is very organic and often happens, top-down is equally valuable, and required, or the bottom-up changes may die out.
Product owners are the obvious initiators. Tasked with creating customer and business value, and deciding what to build, they should be the first to initiate a process dealing with exploring opportunities and assumptions. Like a true "Lean Startup" entrepreneur, only avoiding "The Build Trap"
If you're a designer and you wish to be more involved and understand better? Go ahead, suggest it. UI redesigns can only get you so far without understanding what else you could be doing instead.
Are you a Tech lead who is tired of getting instructions with no context and then burning out on "features" with no meaning? Your place is at the table, asking to understand customers better and advise earlier in the cycle.
If you're any type of manager, you should encourage it as well, and be an active participant in the relevant stages. Why? Nothing beats outcomes. They move the needle of metrics, they raise NPS and retention like no "feature" that isn't outcome-oriented.
So, what parts do we play?
Active Interviewer
Despite misconceptions, customer interviews aren't exclusive to UX researchers.
A tech lead, designer, product owner trio interview helps ask different follow-up questions, to address the 4 risks.
No one better to warn about lack of feasibility for an idea than the person who'll build it. Who better to bring business context than the product owner? Usability risks are best addressed by designers?
However, over time, the product trio will learn to anticipate each other's needs better.
More importantly, it will get everyone out of the "expert mind" (where you know much more than any user about the system, but still assume you're the user/understand the user) and into the customer empathy area
"Mapper"
Even if not actively interviewing, your place in helping map the opportunity space to address potential opportunities, break them down into smaller pieces/separate opportunities is valuable. A tech lead may suggest a way to address the opportunity a designer doesn't know about. Why wait until "kick-off"/"planning" to hear the development side?
Experimenter
The testing of assumptions is so varied, that it may require multiple roles, depending on the context. From content writers, to marketing, to sales, you name it. Here's a good initial resource on various methods of idea validation.
Your place is rapid discovery is vital and you can even initiate the whole process. Some start with an assumption and validate it. Others gather data first and then think what they can do with it, to reach a desired outcome. A good data analyst can help move discovery, so can any business representative that talks to dozens of customers on a weekly basis. You just need to provide them with the tools and include them in the process
Feedback Provider
A fast feedback loop is vital to many aspects, from startup creation to delivery management (the sprint loop, down to the daily scrum loop). It's equally valuable in discovery. A good process, which shares discovery artifacts with stakeholders, enable them to provide valuable feedback about various aspects even the "trio" couldn't address.
I'm using "trio" because there any many additional roles that may be involved, from data analysts and scientists, to marketing, customer experience. Only your context will allow you to decide on the smallest possible group to lead the activity. It's intentionally small, to enable fast testing of ideas, instead of tying it all up in analysis-paralysis
To sum up, while a trio is a minimum for discovery, it can and will include more people at different stages. Some things are best not delegated, such as customer interviews, while others, such as data exploration could be.
How to start with Product Discovery?
First, remember, you're starting a cycle. You'll go through each step more than once, not necessarily in this order all the time, but you'll have the following artifacts:
Create Experience Maps. You may be familiar with Customer Journey Maps . This will tell you what you know (by the way, you can also envision the future, more on that later).
Schedule Interviews. I could write much more about this, but whatever your process may be (mine is mail invites with Calendly links), if you are having such interviews, it's a good first step. You'll use interviews to discover opportunities.
Draw an OST ("opportunity solution tree") - while not out of scope for product discovery, it requires a separate blog post. Start creating it.
Start by defining a desired product outcome, the highest node.
Move down to opportunities to reach it. These may come from interviews, data, these aren't features.
You'll be prioritizing opportunities, not solutions!
Each opportunity you discover may be standalone, may be part of another, larger one.
Your goal is to get to a state where the smallest opportunities you have are plentiful and are organized in a tree/pyramid.
Assemble the Product Trio. Why isn't this the first step? It may be. I ran into difficulties with this. By creating some artifacts, holding solo interviews, you may ignite a fire under some bottoms, some desire to participate. You may already have it, by the way. If not, you'll need to engage and explain why you should be doing product discovery. Maybe refer them to this post? :)
Only once you ran through the customer journeys, interviews and mapped the OST, you'll be diving into Solutions:
Ideation (more on this in a separate blog post)
Assumption identification
Assumption tests
These assumption tests should be on a scale where you can test 10-20 each week. How? Another blog post would be required, but you could start by browsing LearningLoop.io
Like Teresa advises, start small and iterate! One outcome, run through the process.
Sharing the Results of Product Discovery
Have you ever had someone tell you the story of their vacation from a place to which you've never been? How fun was that? Not great, right? Well, product discovery requires sharing with multiple stakeholders in a way that would engage them. It's also a huge benefit, as I mentioned earlier, as it enables them to participate in an opportunity-oriented discussion, instead of having a confirmation bias about their favorite solution. Confirmation bias is when we're facing a "yes/no" decision for something we wish to do, instead of comparing and contrasting multiple ideas/opportunities/solutions. That means sharing:
Interview snapshots
Customer Journey Maps
OSTs
To sum up, sharing the journey, not just the results (i.e. the assumption test experiment outcomes), you'll be gaining more understanding from people at any level.
The Value of Product Discovery
So, what should we get from this process?
We focused on outcomes (business and product goals) over outputs (features/solution)
We explored multiple opportunities of reaching a desired outcome (so we can compare and contrast them to each other, not just a yes/no decision on a feature, thus removing "confirmation bias")
We thought of solutions only after have a wide set of well-defined opportunities backed by customer interviews and data
We introduced multiple stakeholders (and ourselves) to the customers, reducing the "expert mindset" and seeing things from the customers' perspective
We dove into solutions and their underlying assumptions, and tested those, instead of a more costly and lengthy process of building each solution (even to an MVP level)
We provided multiple stakeholders with a way to join us on this journey, so future discussions would potentially revolve around opportunities, not solutions. Additionally, by constantly, openly inspecting our assumptions, we may be encouraging others to also think in this way
Summary
I tried to briefly touch on every issue related to product discovery from my point of view. Hopefully, this will spark interest in product discovery/cause you to inspect additional literature. I can't hope to sum everything up in a single blog post (Teresa's book alone is almost 300 pages). Some may find this too long, some too short, others - just right to start a journey and learn more about any item. If you found it interesting, let me know, so I can expand on each topic! Most importantly, read Teresa's book! P.S. If you think it's not for your organization, or that you already know this, here's what Melissa Perri, the author of "Escaping the Build Trap" noticed were product managers' complaints:
"“My bonus is tied to the features we ship. I need to get those out because it’s getting close to the end of the year,” I heard at one company.
“My manager was getting upset because we were not shipping. We were doing user research, but they couldn’t see the value in it. I had to get something out the door or I’d get in trouble,” said another.
I soon realized that it was not just the product managers that were stuck in the build trap, but the entire organization. Solving the processes for the team was not enough. It was about setting up the entire company to support good product management."
That's why it's vital we do this right (and I'm just learning myself) and support this top-down, and initiate it bottom-up. Just like with agility, it can't remain at the product team level.
Comments