How to conduct efficient product discovery when building MVPs

by | Mar 11, 2020 | Corporate Company Building

7 min read

Product discovery may be the most critical step in your product development process, and it might be even more important when building MVPs. Simply put, find the right thing to build and you’re definitely on the right track. But define the wrong thing to build, and even the most talented team will not be able to create a product that will gain traction.

Getting started with MVP building

So how do you define the right product? Unfortunately there is no magic formula, but there are some clear guidelines everyone can follow:

  1. Define your target group & hypotheses
  2. Decide on how to test these hypotheses
  3. Conduct your research, analyse the results and iterate

In this article, I will walk you through these 3 steps using a case study in which we conducted Product Discovery in the HR space in less than 2 weeks. As the HR space is now considered a red ocean (i.e. a market with lots of competitors), this discovery phase required a strong structure to ensure we would not get lost or demotivated, and that we could iterate from phase to phase.

Definition of target group & hypotheses | 0.5 days

The first thing to do is to define the target group you want to investigate. Based on your market research, decide on the one where you think you could add the most value and then commit to it for the current phase. If you have done your quantitative research right, you should be able to identify the most promising target group.

You will gain better insights when focusing on a single target group rather than investigating two target groups at the time without going into detail on either. In our case, we decided to investigate HR managers of young digital startups.

Once you have decided on your target group, it is time to build your hypothesis. What do you want to know? What do you want to test? What are you unsure of? Your hypothesis set should be comprehensive, grouped, and ranked. Your hypotheses should cover all questions and be easy to read for someone outside of your organisation that would provide feedback.

As you will want to visually show which hypotheses are the most critical to test, focus on your uncertainty level and the potential impact each hypothesis would have if unvalidated, and use this to calculate your Risk score.

For each hypothesis, express how uncertain you are about it and what the impact would be on a scale from 1 to 5, and multiply the two to get your Risk score.

At the end of the exercise, the hypothesis log should look like the following

In our case, we wanted to test the viability of a solution helping recruiters screen candidates more efficiently, which would enable them to focus both on high-added value tasks and on the most promising candidates. You can immediately see that our 4 most pressing hypotheses were the following:

  • Screening is the part of the recruitment process recruiters are most likely to entrust to a 3rd party
  • Recruiters have trouble comparing candidates to one another to make screening decisions
  • Recruiters would be willing to skip the “traditional” application process and rely solely on a questionnaire
  • Recruiters will trust automated matching / scoring technology

If you have looked closely at the picture, you might be wondering what the test format and the status are all about, and this is what we will look at in the next point.

Validate your hypotheses via solution prototyping | 2-3 days

Once you have your hypothesis log, you will of course need to test them. I strongly believe that as soon as you have some understanding of your target groups, prototyping a solution is by far the best method. Doing so will help you gain a better idea of your hypotheses as well as gaining deeper insights from the people you will test the hypotheses on. And users will naturally suggest next steps that will allow you to react much faster.

However, there are a few guidelines you can follow to ensure you make the most out of your prototype in a limited amount of time.

  • Only test the hypotheses you have defined above: There is no need to engage in a full representation of what you have in mind.
  • Do not code anything: This will allow you to shorten time spent on prototyping and will force you to focus on the most important issues. In case you are wondering, some tools you can use are Sketch and Marvelapp for basic prototypes or no code tools such as Makerpad, Webflow or Bubble for high fidelity ones. I recommend spending no more than 2–3 days on creating your prototype. In the ideal world, a prototype should be created within a day in order to test your ideas as fast as possible, but because you will likely be juggling between tasks I believe 2–3 days is a reasonable goal when building a prototype. In his book Sprint, Jake Knapp writes that you should aim at “Goldilocks quality” and not forget that your goal is to test specific hypotheses only at this moment.

 Once you have created your prototype, take a look back at your hypotheses to make sure you haven’t forgotten anything. If there are hypotheses you couldn’t cover with the prototype, integrate background questions or further questions in the interview script you will go through before showing the prototype. At the end of the day, all your hypotheses should be tested, and twice is better than once.

Here, you can find screenshots of the prototype we created in 2 days and then used to test all our hypotheses: 

Further Research, Analysis & Iterations| 7-10 days

Now that you have your hypotheses, your prototype and maybe additional materials, you are ready to conduct user interviews.

Even if the goal of this article is not to go over user interviewing, there is one big rule people building MVPs should not ignore: Start scheduling your interviews from the start of the research phase!

Because you lack resources, time and brand image, finding customers that will agree to test your prototype will be long and time-consuming. So start getting customers and scheduling your demos as soon as you have defined your target group in step 1. And scheduling demos early in the research phase also has an unexpected benefit: It creates a tight deadline that will force you to work hard while focusing on the most important issues.

Potential users may all also not be available on the same days, which will make the whole process longer, so make sure you do your part to make it as short and efficient as possible.

If you are too much in a hurry and that you cannot afford to spend some time on LinkedIn acquiring free users, several tools will enable you to get people, such as User Interviews orbTestingTime. However, these tools are not free and you would save a lot of resources by tackling this issue in advance.

Once you have conducted all interviews, gather all the answers to your hypotheses in a single sheet and analyse the results so that you can share the results with your team. If the findings are good, then keep going in this direction. If the signals are not good then try something else or change your target group.

The rationale here is that shortening the whole process will allow you to conduct more research rounds in a short amount of time. Not to mention that if you keep investigating the same target group, you should be able to shorten the whole process to 1 week as you now have people to contact.

If you wonder what our outcomes were, we unvalidated 2 of the 4 most pressing hypotheses and found out our solution would not save that much time for HR Managers:

  • HR managers will only trust 3rd parties if they can check and validate their work, therefore automatic screening wouldn’t be such a time save
  • Recruiters are not ready to rely solely on a questionnaire and would only accept a new tool as a support (if they decide to use one)

As a result, we decided to completely change our focus and investigate a new target group. However, some of the findings became highly interesting later on, so remember that nothing is ever lost and that this whole process should eventually enable you to find the right opportunity.

Written by Matthieu Boussard (Product Owner)

 

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *