Start with Problem Validation, NOT Solution Validation

Start with Problem Validation, NOT Solution Validation

There is a difference between having an idea and validating an idea. Validation is the first step in moving towards learning more about the problem.

So you’ve just had that shower moment and thought of a potential solution to a big problem. This could be huge!

You rush to your computer and start fleshing out your unicorn idea. Perhaps you're the type that:

  • starts with writing a business plan
  • performs a Google search to see if any similar products exist already
  • you have some handy design skills and begin creating some wireframes
  • you have some technical skills and begin creating a prototype or MVP

Regardless of the type of person you are, you're missing a fundamental step prior to scoping and developing your proposed solution: Problem validation!

There is a difference between having an idea and validating an idea. Validation is the first step in moving towards learning more about the problem you are ultimately looking to solve.

Too many times people are quick to hypothesise a solution with little understanding of the problem. You need to understand the problem well enough to create a robust, well thought out solution.

When you spot a problem and think you have found a viable solution to create a business around, it’s all too easy to get excited and jump straight into ideating a solution.

I myself have been guilty of this on many occasions 🙋‍♂️- in fact, a lot of the founders who we speak with on a daily basis also come to us with proposed solutions to a problem, looking to partner with us to build their digital product or service. However, product development can be costly if you have no direction. You don’t want to use it as your main tool for iteration. There are often easier and cheaper ways to figure out if your proposed product will satisfy your end-users.

User testing twitter poll

Avoid making something and then hoping people buy it when you could research what people need and then make that.

One of the biggest risks with this approach is ultimately you build the wrong solution and waste months or years creating something no-one needs or wants.

CB Insights recently published their research stating the Top 20 Reasons Why Startups Fail. Number #1: ‘Tackling problems that are interesting to solve rather than those that serve a market need’.

Courtland Allen recently wrote a fantastic piece titled How to brainstorm great business ideas’ and quoted an excerpt of Seth Godin’s book ‘This Is Marketing’:

It doesn’t make any sense to make a key and then run around looking for a lock to open.
The only productive solution is to find a lock and then fashion a key. It’s easier to make products and services for the customers you seek to serve than it is to find customers for your products and services.

Courtland followed up his argument with “You’ll make your life easier and your business ideas better if you put the solution last and the problem first”.

To further emphasise my point: Let’s fast forward a couple of months, perhaps a year and you have a product built and launched. Now imagine how hard it would be to switch from targeting one market to another, undoing your business development, redirecting your sales focus and fundamentally changing your product. You could throw away months or years of hard work validating a concept, building a loyal customer base, attracting press or perhaps even convincing investors. The energy and financial cost of such changes further down the products lifecycle will cost far more than figuring it out prior.

So the question remains — how can we reduce this risk and rapidly validate the problem prior to validating the solution?

Evidence-driven product development is a core principle our product team at ucreate stand by. We try to ensure we don’t build a new product or feature until we have evidence to suggest it will provide a measurable improvement, provide value to the end-user, and maximise your chance of a successful launch.

This principle remains true prior to considering scoping any new product, feature, or improvement, and starts right back at the beginning of the product development process with what we call evidence-driven problem validation.

Before we jump into describing our evidence-driven problem validation framework, let’s address the elephant in the room:

A common question we get from both product teams and the founders we work with is — “we have a tight deadline — surely this framework will just add additional time to process?”

And the answer is quite simply, YES, in the short term it will, however, wouldn’t you prefer to de-risk the likelihood you spend weeks or months scoping, designing, developing, testing something which doesn’t satisfy your end-users or provide measurable value?

In some cases, you can gather evidence in a matter of hours and vastly de-risk your assumption. For new product ideas, you can test your core assumptions in a matter of weeks. Try to not think in the short term but plan for the long term more strategically.

Fundamental assumptions to validate before moving to the product validation phase

There are three core pillars to idea innovation as previously stated by IDEO in the early 2000s that contain these essential characteristics:

  1. Desirability: Do they want this? (problem validation)
  2. Viability: Should we do this? (problem validation)
  3. Feasibility: Can we do this? (solution validation)

The most logical phase to begin during the validation process is the desirability phase.

Starting by answering the following questions:

  • How big a problem is this? i.e. how many people encounter this problem? how many times an hour, week, a month? is it a big enough problem that people would be willing to pay for a solution?
  • Why does this problem exist?
  • Is anyone else already providing a reasonable solution to this problem? If so, are they doing a good enough job or is there room for improvement?
  • What type of people encounter this problem the most? What are their characteristics? Their persona types? Where do they live geographically? Where can you find them (online/offline)?
  • How does this rank compared to the other problems?

After you have found the answers to the above desirability questions and found confidence in your data and the insights you have gathered then it’s time to test the viability.

Testing for viability asks: does your business model fit with the way your customers want to use and pay for your solution? Is it capable of producing a profit? Is this a sustainable model?

And finally, feasibility requires you to objectively assess your personal and team strengths — technology, financial, branding, customer service, partnerships, etc. For example, is the technology needed to power the proposed solution available or within reach? Do you need to find a team with this expertise to join/support you? Do you have the logistic and partnership network in place? Can you raise the required amount to develop this initial product and take it to market? ⚠️ It should be noted this step falls into the solution validation phase.

Each element of the validation sprints brings up more assumptions and risks that need to be validated. However, with just a few weeks of structured rapid validation sprints, you can reduce that risk substantially.

The above framework might sound overwhelming at first glance, but if guided through this process it can be achieved in a matter of weeks and derisk your proposed solution whilst saving a lot of time and money in the process.

We at ucreate have built a micro-incubator programme focused around problem validation. Introducing, Spark.

Product Management
User Testing
Customer Development

Other Posts