Validate the Problem Before you Validate Your Idea

Most of us use a platform or framework every day without even thinking about it. Maybe it’s email, maybe it’s Microsoft 365, maybe it’s Slack. But have you ever stopped to think why?

The answer is almost definitely because these solutions are solving a root problem. You can create the most beautiful product in the world, but if it doesn’t solve a real problem, it’s essentially useless.

This is a universal challenge every potential product has, and while (for the most part), we’re all comfortable validating ideas and building MVPs, many startups miss an important first step – validating the problem. Especially a product that’s breaking new ground and has no competition yet.

If doesn’t matter how shiny your product is, how many groundbreaking features it has. If it solves a problem nobody has, it will generally fail. Yet many founders get so fixated on scratching an itch, that they don’t stop to think about whether what they’re solving is actually a problem for anyone else.

In this post, we’re going to look at some of the most useful methods for identifying and validating the problems your product (or potential product) will solve.

What is the right problem?

Plenty of beautiful products fail and no amount of great design or nifty tech can save you if:

• The problem your product solve wasn’t real in the first place
• Not enough people shared the problem
• The problem wasn’t validated early enough
• The problem can’t be validated without a huge time or financial investment
• Someone else solved the problem better and/or faster

So before you start developing everything, or even considering how your problem could be solved with technology, ask yourself….

The right problem, or rather a problem that could leave to a successful product, is:

• One that is shared by other people
• One that people will pay for (depending on your business model)
• One that no one else is solving well enough

If you’re trying to solve a problem that isn’t causing much pain in people’s lives already, your resulting solution will fail.

Getting to the root of the underlying reasons why your users need your product shifts the decisions you need to make. This early product discovery is mission critical and should be executed within a matter of hours of days. Anything longer and you’re missing the point.
Is this the right problem?

We’ve summed up some of the simple exercises that we use with clients to make sure we all understand the problem a product is looking to solve…

Create a problem hypothesis from your idea

Kissmetrics founder Hiten Shah suggests “problem hypotheses” as the first step in validating your startup idea.

“Ideas are just a description of the solution to a problem. Converting your idea to a problem hypothesis enables you to stay focused on validating the idea instead of building the solution.”

Shah says that it’s important to phrase the hypnosis around a targeted user group and what problem they might have. This gives you the added insight into your target market, which can be easy to skip over in the early days of a startup idea. The problem hypothesis should read:

[Group of people] have a problem [their problem]

Here is the original problem hypothesis for Contactzilla, our product that solves how to securely share contacts within the team:

“Business owners have a problem securely syncing and sharing their contacts with the team.”

This kept the team focused on validating the first assumption we’d made – it wasn’t just us who struggled with maintaining and sharing contacts within a business.

Now you’ve got a hypothesis, it’s time to start testing it…

Talk to potential customers

Once you have some problem hypotheses set out, you can test them by talking to your target customers. Find them at industry meetups, conferences, in the line at coffee shops or waiting for a train like this founder. Talk to them about the problem you believe they’re having, find out how they’re currently battling that problem and really listen to their experiences.

Steve Blank highlights the necessity of talking to customers perfectly in this interview for 99U…

“You’re trying to understand how something you see (and they don’t) will change their life. You want to understand the before and after. For example, what does the world look like before the computer and what does it look like after the computer?”

When you’re talking about the problem, take the opportunity to A/B test your hypotheses and see what resonates best with your target audience. If you get a recurring theme in the reactions then it sounds like you’ve discovered the right problem.

Conclusion

Only once you’ve validated your problem should you start thinking about developing a solution. Once you’ve defined your problem, identified an audience, spoken to potential users and it still seems like a good idea – then you can start thinking about how to create a solution.