Let’s start at the beginning and talk about the first step in the tech development process – defining the problem.

Rob and I speak to lots of entrepreneurs, often 2 or 3 a week, and all of them have some kind of product in mind. The first thing we like to do with them, to fully understand what they actually want to build, is to understand the problem they believe their product is solving. Sounds simple? Not always!

Lots of start-ups fail, and many fail because they try to jump straight to building a solution without having really, truly understood the problem they are trying to solve. By the end of this article we aim to have given you some tools to define your problem and be able to write your own, clear “problem statement”.

While brainstorming and coming up with solutions are important (and fun!), it’s critical to pinpoint the exact problem before you start. Defining problems is a great skill to acquire. There is a famous quote often attributed to Albert Einstein which goes more or less:

“If I were given one hour to save the planet, I would spend 55 minutes defining what the problem is, and five minutes resolving it”.

The point is that by defining problems properly, you make them easier to solve, which means saving time, money and a lot of headaches.

Another fine mind, philosopher and psychologist John Dewey, believed that “a problem well stated is half solved”.

Here’s our own take on three useful tasks to help get your critical thinking moving so you can be absolutely clear about why you need a new product, and what exactly it’s going to do.

‍

Task 1: Ask yourself – “Houston, do we (really) have a problem?”

This is the very first question to try and answer: is this really a problem that needs solving? To do this you will need to try and immerse yourself in the problem itself, analyse it from different angles and avoid perceived but not real problems or just symptoms of another, different, underlying problem.

We have come across several instances of enthusiastic founders wanting to implement exciting products to solve a problem they haven’t really explored fully. After a few simple questions they realise that the real problem lies elsewhere. So how do you find out what’s a perceived problem – aka what you THINK the problem is – and what’s a REAL problem? Once you do this, you will have got to the heart of it. The real problem is going to be much more interesting to solve, and will bring greater benefit to users, increase their satisfaction and hopefully repeat custom.

‍

Root Cause

Often the best place to start is challenging yourself to figure out the root cause of the problem you are looking at. Am I looking at the real problem, or is it a complex of symptoms? Like a doctor, if you only treat the symptoms, the problem doesn’t really go away. To avoid focusing on symptoms, you can try a number of different “root cause analysis” techniques. One of our favourites is the very simple (but difficult to actually do!) Five Whys. Simply ask yourself “Why is this a problem?”, then when you have an answer, ask yourself again, why is this a problem? And repeat 5 times. Sounds simple…

To help you with an example: you might have a problem: your car does not start. But that’s not really a problem, it’s a symptom.

So first question:

Q1: Why does the car not start?

Answer: The battery warning light is on.

Q2: Why is the warning light on?

Answer: the car battery is dead.

Q3: Why is the battery dead?

Answer: The worse have come loose

Q4: Why are the wires loose

Answer: The car has not been serviced and the wire issue found

Q5: Why hasn’t the car been serviced

Answer: The vehicle was not maintained according to the recommended service schedule

It’s a bit of a silly example, but it demonstrates that the root cause problem was related to something very different to the original observed symptom (servicing schedule, not the car failing to start).

‍

Talk to People

Defining a real problem means removing your assumptions. Another very useful thing you can do to find out whether a problem really exists is to check it out by talking to people. You may have a perception of what the problem is, but you need more than just your own view. Figure out who you need to speak with, whether it’s an organisation leader or a key user, or a spectrum of different people who know about the topic in question. Find out what the user really thinks. This may sound obvious, but making sure that you have incisive questions and a good listening ear will help people to tell you why this problem matters so much, and then the better the solution you’re going to be able to build.

‍

Task 2: Set the scene – let’s get granular!

The more context you have for the problem you want to solve, the more you’ll know about the problem, and the better prepared you’ll be for your development journey. The more information and data you have, the better you’ll be able to measure and benchmark your proposed solution. You’ll be able to answer with confidence, “Is this problem really worth solving? Is this product worth building? Is there a real need for this and will people be willing to pay for it?”

Imagine if the answer is no – you’ll have saved yourself so much money, and blood, sweat and tears. Go find a different problem to solve! Imagine if the answer is yes – you’ll know you’re really on to something.

‍

Get Context

So, here are some of the “granular” questions to pose to yourself about your problem:

“When does the problem occur?”

“Who does the problem affect?”

“How do people feel about the problem?”

“What is the measurable impact of the problem?”

“What is the current fix for the problem?”

By finding out what is the emotional impact of the problem, you find out how seriously people take the problem, and therefore how to market the solution. The emotional information can be backed up with hard data to quantify it. And if you know what the competition is already doing or trying to do to fix the problem currently, you know exactly what needs improving, so you can create the ideal tech product that people want to use.

‍

Gather Data

Data will provide supporting concrete insight into an issue. Depending on the field you’re working in, sources of data could be Google Analytics, a CRM, BI tools or perhaps old school business reports. The more data points you can get your hands on, the better, but make sure you read the information with a critical eye: be aware of the quality, the context, and how it was gathered. Data feels inarguable, but it can be nuanced; again, the more you can dig, the better grasp you have of the numbers, stats or the reports you’re using, the better armed you are. Don’t always take things as read – analyse the analytics!

‍

Task 3: Define it! – Write your “problem statement”

Gathering data, getting context and answering all of these questions will help you to really define your problem (absolutely crucial we think!) and give you the basis to figure out a solution. The final task, once you’ve grappled with all the questions, is to bring everything together and write your “problem statement”. Writing a clear problem statement is not only going to give you a clear north star as you work through a solution, it will also help to explain to all stakeholders exactly why this is a real, true problem. We cannot emphasise enough how useful this will be to help you with building your ideal solution. Remember the quote we started with: “a problem well stated is half solved”.

There are lots of resources online to help you formulate your problem statement but at a very basic level you want it to simply describe the problem by answering the questions:

‍

Who has the problem?

The more incisive you can be, the more you will be able to identify exactly which customer you are targeting, so you can build the best solution for a specific group of customers, rather than build an average solution for an uninterested market.

‍

When and where does it happen?

Context is crucial, the more you know about the problem, the more easily you will be able to identify the window of opportunity—when the problem becomes acute and most painful for the customer, what they are doing at the time and also when they are also most likely to take action.

‍

What is the impact of the problem on the people it affects?

A full understanding of the emotional impact of the problem will help you identify triggers that will make your customers change their behaviour. Backing this up with the quantifiable impact will help you to determine the value opportunity, and perhaps help identify ways to communicate convincingly to the customer once you have a solution.

‍

What do they currently do about the problem? and What is wrong with these solutions?

Evaluating the competition and breaking it down into pros and cons will be a great help in identifying opportunities and helping you to develop your own solution.

If we take Netflix as an example, their original problem statement would have been something like:

“For people wanting to rent a movie in the evening or at the weekend, going to the video store is a pain. They get annoyed at all the traffic, they don’t like traveling back and forth just to rent one movie. The alternative is to rent multiple movies but then they incur late fees which they hate paying even more.”

Telling a story around the problem allows people to relate to it and understand it in greater depth. Notice also there is no reference to any kind of solution in this statement.A very good resource that you may find helpful in writing your Problem Statements can be found here. They call it the Problem Statement Canvas – painting the picture with words! And is a helpful way of setting out clearly all the elements that go to make up a strong problem statement.

‍

CONCLUSION: There’s no such thing as a stupid question!

In summary, to work out what is going to be the right tech solution for your problem, you first need to know what your problem really is. Get to the root cause by asking “why?”, “who?” “when?”, and “who cares?” Keep digging until you know the true essence of the problem. This is a process that will save you time and money – guaranteed.

Give the problem you are trying to solve as much context as you can. This will be helpful not only for you and your team to focus on, but it will also help other investors or potential customers understand quickly what you are trying to solve.

It also gives you something to return to and to refine. Your first solution will not be the end of the story. You’ll keep reassessing, to keep your product fresh. Keep going back to the defined problem, the context and the market; things will change over time.

‍