Customer discovery and the journey to MVP.
This article is based on my personal experience as a product manager and, prior, while contributing to a product on the tech side. Your experiences may be different.
I have worked for several start-ups born from an academic setting, a small enterprise 20 years into its journey and a large multinational. In all of those environments, I was part of teams trying to develop a minimum viable product (MVP) — either because the product was brand new or because the product was being reimagined for a new market. In both scenarios, we had to be super clear what the MVP needed to be and a vision how to get there.
In order to launch a successful product, a key component is understanding what the customer’s main problem. This is right along side the need to understand how often the problem occurs, their willingness to pay, and the risks associated with trying to come up with a solution.
As the title suggests, I am keen on the customer discovery process. To the nubes reading this — I am referring to the process of engaging with customers or (more often) potential customers to understand what is causing them pain. In other words, what are the challenges they face in trying to do their work. This includes identifying the work arounds that they are executing if a non-optimal solution exists. The objective in asking these questions is to understand what solution you can offer in the product that will resonate with they because the tasks they are trying to perform easier, faster, and/or cheaper. The beauty of the customer discovery process is that it can also reveal opportunities for solutions they didn’t even know they needed.
Some of you may be familiar with the concept of the five whys. But I want to state it another way:
As the product manager your role is not to ask customers what they want but to ask what their workflow is and the challenges they face to complete their objective. Prompt them to tell their stories and be an avid, engaged listener.
Discovery questions should not be “Do you like this feature we want to release?” Your questions should be more along the lines of:
- Can you describe to me your main task?
- What are all the steps?
- What steps are the hardest? Why? How often do you do these tasks?
- What steps take the most time? Why? How often do you do them?
- What tools are you using now? Have you had to create work arounds?
This list of questions is not exhaustive, its not meant to be. Hopefully you are working on a product because you know what objective your customer wants to achieve and you will adjust these questions, and create better ones, accordingly.
Henry Ford is often credited with the quote “If I had asked people what they wanted, they would have said faster horses.” It turns out that he never said it, according to this article, but it illustrates the point nicely. Why is this so relevant? Because customers are not the technology experts, your team is.
When a customer says — “Why don’t you just build X?” They may be right. But just as often, they may be wrong. They don’t have the full picture of your existing technology, they don’t know (or care) how hard it is to productize that item they are requesting, and they probably haven’t sat down an analyzed the multiple other ways to solve the problem. If the thing that they are suggesting actually solves the problem. Their suggestion may not …it may just be some cool tech that they read about.
So let’s tie this discussion back to the MVP. The goal in creating the MVP is to create solution that just addresses the customer’s problem, alleviates their pain such that they are willing to pay. It is the minimum that they need that complies with your vision and quality standard.
So start talking to your present customers and those customers that you want to have. Use the discovery information, along with the other factors such as your present assets, knowledge, risk tolerance, etc. Get a sense as to what’s needed and focus on that so that you get something to market.
Once you launch, listen to the signals, and adapt. Despite this process you may need to pivot, after all there is no guarantee.
