How to validate a user need

How to validate a user need
Photo by Kelly Sikkema / Unsplash

In order to make something you know the market wants, a useful series of steps are as follows:‌
‌1- What are the customers pains, needs and desires?

I'm a fan of Teresa Torres Continuous Customer Discovery. I like that customer needs can be categorised into 3 buckets because there's a spectrum of customer needs which you can prioritise according to your business goals. If I take an example of a site where you can book physio treatment these could be:

Pains: When I try to book an appointment with a physio, it's not clear how I book‌
Needs: I need to to see all the available slots I can book‌
Desires: I wish I could book a recurring slot with the same physio each month

Now in this example 4 users tell us the same pain relating to how unclear it is to book an appointment.

A helpful way to gather pains, needs and desires is to carry out qualitative research with upto 5 users. After that, you reach a point of saturation where you're less likely to see different results when testing specifically with your target user.

2- Prioritise the pains, needs and desires

Now you have a list of pains, needs and desires, you can prioritise them according to your business goals.

In this example, the business goal is to increase retention, therefore I'd like to understand the severity of the pains, needs and desires. The more important the user need, the greater the opportunity.

Now let's say a number of users mention the pain of not knowing how to book an appointment with a physio. This looks like a pain point I'd prioritise over 2 people mentioning a desire. Why? In my case, addressing pains could be a key reason we're seeing so 10% of users leaving the site.

3- Build something cheap which allows you to observe behaviour

Prototype something on Figma and then test with 5 users. You're measuring whether there's a cause and effect relationship between what you build and how they behave.

Now let's say we build something which enables users to book. It's a link to a calendar view with the dates and the user can select a date and time and book, getting an email confirmation with a booking number.

We test with 5 users and 90% of users can book the calendar. I'd say I've de-risked user value in a lean way. Now I'm going to extrapolate and hypothesise that 75% of users would be able to book appointments if we build this into a live environment in the form of an AB test.

We go live and gather statistical significance testing our hypothesis with 5000 users.

We see churn rate go down by 30% among the users who interacted with the new feature. There's a cause and effect relationship because the only variable with the group served the new feature is the new feature. Everything else is the same.

Therefore I've determined that the cause of churn was the customer pain point of not being able to book a physio easily. I've validated the solution. The new booking flow reduces churn and now we can A/B test different variants of this solution.

  • 551 words