What is Product Discovery and Why It Should Come Before the MVP?

22 Sep

One of the most important jobs as a product manager when launching a new product is knowing when you are on the right track. With so much emphasis on building an MVP, minimal viable product, and “The Lean Startup”, one would think it would be as easy as building a simplified demo version of an idea and then talking to customers to see if they like it, and more importantly, if they will buy it.

But hold on a sec. Before we waste our time on building anything, shouldn’t we first validate that a market even exists for it? How do we ensure that our future customers will be so excited, that they can’t wait to get their hands on it? How do we test out our theory that this is a good idea? That, my friends, is product discovery.

This year, our product team participated in an in depth session on “How to Create Products Customers Will Love”. There were a ton of valuable lessons that I learned in those 2 days, but the biggest takeaway for me was taking a step back, before building the MVP, and instead iterating through a product discovery process. During this phase, it is purely about validating that the problem we are trying to solve, really is a pain point and that the solution we are thinking about is one in which our customers would be willing to pay for.

Let’s talk through an example of how this would apply to a new idea in the B2B world. The background is that employees in offices communicate on their desk and mobile phones every day as part of their daily job. They communicate internally with their co-workers, as well as externally with customers. The product hypothesis is that those employees want an easy way to have a conversation, no matter where they are or which phone they are on. So how do I go about performing product discovery for this?

  • Create slides to facilitate a discussion – Sure, I could just start talking to people but guiding a discussion with visuals works best as it helps frame that we both are “seeing” and talking about the same concept.
  • Detail a list of questions – The purpose of these questions is to gauge how much pain they are suffering with in their current process. Have employees complained about having multiple phone numbers (desk and cell)? Would they prefer to have the ability to send text and picture messages too? Would they prefer to be more mobile and have the same conversation on either phone? Would they prefer to use one app to control all of their phones? All of these types of questions will get to the crux of how big of a problem it is and if I am headed in the right direction.
  • Determine the market segments and potential customers – Before I can ask those questions, I have to know who to talk to! So if the problem I am trying to solve revolves around employees using work desk phones, then my target segment is businesses that sell office phone systems. I then need to create a list of companies who meet that criteria and that list becomes the top of my funnel.
  • Determine which people in those companies to talk to – I usually start with fellow product management people first. Why? Mostly because they are in the same boat as me and understand the criticality of bouncing ideas off each other. They are also the ones who want to make their product user experience better. However, sometimes it makes more sense to talk to the person dealing with the pain each day, in this case, perhaps customer support.
  • Start reaching out by asking for advice – I always start the conversation or email by asking for their guidance and advice, because that is essentially what I am doing. Personally, I know for myself, that if I am being asked for my opinion vs. trying to “be sold” on something, I am much more willing to have the discussion. This step in the process is sometimes the hardest part because you need a thick skin and can’t let rejection rattle you. There will be lots of ignored calls and emails, but if I am stumbling on a big pain point and am not too pushy about it, people will talk openly to me about it.
  • Listen! Ok, so this one needed a big ‘ol exclamation point because it is so true. Really pay attention to what they are saying during our discussion. Do they seem to relate to the questions and wholeheartedly start telling me, yes indeed, employees want a better way to communicate than just talking on their desk phone? Do they start asking what my new app is and how it will work? Do they get excited? If so, then Boom. Game on. If not, then I have to start thinking of how to make the necessary pivots so that I can get that kind of reaction.

So, I made it all the way through. I have pretty much successfully validated that there really is a problem that my product can solve, and that there is a market for it.  Bingo. So am I poised for product stardom?

Maybe.

Seriously? Why not yes? Didn’t I just prove that my idea is a hit? Yes, but now I must prove that my solution will be a hit as well.

It is now time to move on to building the MVP, the minimal viable product. It is the simplest form of my proven hypothesis and a version of the solution. For me, it might be an app that simply allows me to add my desk and mobile work phones and have a conversation start on one and end on the other. I now have to prove that this simplified version of how to solve the problem is going to be the beginnings of an awesome product – the golden ticket to their happiness and one that they will love and buy.

This blog is the first in a series of blogs that I will be writing around “How to Launch a New Product.” In future blogs I will be talking about iterating on an MVP, beta testing, creating the right product marketing materials, educating and empowering internal teams, declaring official “product”, and scaling & growth. In the meantime, I can’t wait to hear your thoughts on product discovery. Cheers.

Deirdre Clarke
Deirdre Clarke
dclarke@bandwidth.com

Deirdre is currently a Director of Product Management at Bandwidth in Raleigh, North Carolina. She started her career as a software developer, after graduating from Rutgers with a degree in Computer Science. Before moving to Bandwidth in 2014, she was at Motorola for 18 years where she started as a software developer and then made the leap to more of a business role in product management in 2007. In this new role, she really flourished and today still enjoys creating new software products and features to help solve problems for her customers. At Bandwidth, she spearheads new software products in the call tracking and anonymous calling arenas. In her spare time, she is a deeply involved in the Triangle TechGirlz program, helping to ignite young girls' interest in future tech careers.

No Comments

Post A Comment