4
Heard that before?
Product Discovery, often referred to as Customer Discovery, is hardly a new idea. Despite that, many companies often forget about it or do it plain wrong. This applies to giant corporations, tiny bootstrapping startups, and anyone in between.
In this comprehensive guide, we’re going to solve the mystery that surrounds Product Discovery. We’ll tell you WHY everyone should be doing it, WHEN it should be done and HOW to do it. In case you’re not familiar with the concept, we’ll also explain WHAT product discovery is.
Let’s begin.
What is Product Discovery and why do products fail?
Product Discovery is the process of testing a concept with customers. The goal is, of course, to build the right product. By right, we mean the one that solves real problems, is well-timed and is possible to build with existing technology and available resources.
Sure, that’s easier said than done. But, if the product discovery is done right, it might make the difference between success and failure.
Yet many companies don’t do it right.
In a frenzy to outcompete their opponents, companies ship new features over and over again. The dust hardly settles after the last major launch, before the two other teams are already beta testing new concepts. All that to keep their market position or outpace their biggest rivals.
Many aspiring entrepreneurs also target that tiny chunk of the market. They’re hoping users will jump to their product right away and will grant them eternal glory in Silicon Valley.
To no surprise, many of these products collapse and the list of the most notable failures goes on and on. Let’s mention only a few of them:
- Windows Millenium
- Apple Newton
- Google+
- The New Coke
- Ford Edsel
- HP TouchPad
Each of these companies had a virtually unlimited budget. They could have spent hundreds of millions of dollars on marketing them. They could have hired the world’s top talents to build and sell them. They did.
And yet, each of these products is considered a spectacular failure. Because, whilst they were great in their own way, the customers didn’t really need them.
They gave them a try, some lined up in front of stores for hours. A few even emailed or tweeted friends about them (except maybe for the Ford fanbase in the ‘50s but we can understand that).
Yet, none of the above products really took off, and each was, sooner or later, shut down. These companies still remain some of the world’s biggest and most successful despite these failures. We can’t say the same about thousands of startup founders who lost all their savings (and likely several years of their lives) building failed products.
Product Discovery vs Product Delivery
Product Discovery in agile methodology is often confused with Product Delivery. Despite the name similarity, it’s important to note that these are two completely different processes. They should both be a part of the process that leads to shipping a product, but you shouldn’t mix them up.
Product Discovery, as stated above, is about understanding what kind of solution is needed. It’s about understanding clients and their needs. It’s also about addressing their pains and creating value for them.
Product Delivery, on the other hand, is about building the solution figured out in the discovery process, with scrum methodology for example. It’s about bringing it to clients, seeing their reaction and building on it with future releases.
To make it even clearer, Product Discovery is about building the right thing, whilst Product Delivery is about building the thing right. Simple, right?
Now that we have the WHY part covered, and we covered a bit of WHAT too, let’s move on to WHEN.
When to do product discovery? What is continuous discovery?
A very reasonable approach is to begin with proper product discovery, starting very early. It should happen before you even write the first line of code or attempt to sell anything.
Retreat with the team for a few days, relax, brainstorm and generate tons of ideas. Come back, put them in place and see what users think.
Now, likely the feedback won’t be all so positive and you won’t get a perfect hit at the first discovery session. Users won’t be so crazy about the product and user acquisition will be harder than expected. Clients won’t use a feature you thought would be crucial, or that feature will get lost in the process.
That’s why continuous product discovery should be a part of your delivery process. This doesn’t mean weekly retreats with the team (however nice these sound). It’s not about going through the whole process over and over again. This means:
- Craving user feedback. It’s about reading app reviews and analyzing support tickets. It’s about harvesting as many feedback sources as you can to understand your users’ point of view.
- Testing how users use your product, where they get lost, and what the bottlenecks are.
- Reaching out to users, asking for their opinion, and trying to figure out what the problems they’re struggling with are.
- The discovery session leaves you with several key hypotheses and an idea of a model you could test with users.
- During the delivery, the concept is built and given to users. The first downloads happen and users are onboarded.
- Users didn’t like the concept but gave some valuable feedback. The concept goes back to the discovery table.
- A new concept is designed, under different assumptions. It’s passed to the delivery team for development.
- The second iteration is ready and is given to users. More downloads happen than last time and higher user engagement is visible. It looks promising.
- It turns out that users were eager to sign up, but didn’t find any value in logging in after that. Back to the discovery.
- The delivery team shipped the new concept and it finally seems to be the right match! Growth is significant, users keep coming back. There’s an interest in premium features. Now it’s onto the delivery team to keep improving the product while keeping the discovery team involved at all times.
Continuous Discovery is a bit easier than the initial product discovery. You (hopefully) already have some clients who can help you validate some hypotheses. The more users you ask, likely the better outcome you will get and the more informed decisions you’ll make. Assuming you’ll know how to interpret their answers.
We now have the WHEN part explained so let’s move to the core of this article – HOW to do a proper product discovery.
Product Discovery – questions to ask yourself
Whichever discovery method you choose, there are several product discovery questions worth asking yourself. They will also help you visualize what you want to get out of the process.
- Will the customer use this feature? Will they be willing to pay for it?
- Will it bring any value to them? Will they feel a difference if you take it away?
- Will they know how to use it?
- Are we capable of building it? Do we have the right skills, experience, and budget?
- Is it aligned with our business goals?
These are not simple questions and you might not know the answers. At first, you’ll probably do a lot of guessing and you’ll get some answers wrong. But over time, once you get to know your users better and test some assumptions on them, it will become clear if your approach is the right one.
If you already have some early adopters, a great method of getting the questions right is by exposing the team to your users.
Many companies ask non-customer focused employees (developers, designers, product managers, etc.) to spend a bit of time with clients. They answer their support tickets, respond to forum posts, jump on calls.
Even a few hours a month can do miracles. This can point you to an approach that wouldn’t cross your mind even on the best-facilitated product discovery session.
Product Discovery techniques
Over the years, many Product Discovery techniques have been proposed. Some gained little popularity, others became omnipresent on product discovery sessions. The most common methods you’ll encounter are:
- Design Thinking
- Jobs to be Done
- OKRs (Objectives and Key Results)
- RAT (Riskiest Assumptions Test)
- BRIDGeS
We cover them one by one on Railsware's blog.
Thank you for reading and let me know if you found ths helpful! :)
