Back
August 21st 2017

Problem statements and why you need them

Written by Andy McKenna

problem statements

One of the most valuable, yet underused, tools available to the Conversion Rate Optimiser is the problem statement.

What is a problem statement?

Before we go any further let’s look at a definition. Wikipedia defines a problem statement as “a brief description of the issues that need to be addressed by a problem solving team and should be presented to them (or created by them) before they try to solve a problem”.

Why is it important?

The problem statement serves as a link between business objectives and hypotheses by clearly articulating an area of concern to business stakeholders.

This means it is a great way of making sure your website experiments are relevant to what your company is trying to achieve.

If you read or listen to CRO experts you generally don’t have to wait too long before you start hearing about the importance of creating a hypothesis for A/B tests. However it’s less likely that you will hear them shouting about the need to create a problem statement.

Just as you shouldn’t push an experiment live without a strong hypothesis, ideally you should have a problem statement that underpins that hypothesis too.

What it shouldn’t be

A problem statement shouldn’t be a description of the lack of a solution – e.g. the problem is that we don’t have a CRM system.

It should be concise, but it shouldn’t be too short. It needs to include enough salient information to be useful and informative to everyone affected by the problem.

According to Six Sigma, “a problem statement containing so little information significantly reduces your ability to take specific action, enlist support, and obtain improvement”.

The structure of a problem statement

Management consultancy Ceptara recommends that a problem statement should have the following:

  • A vision
  • An issue statement
  • A method

Let’s explore each of these in turn.

  1. The vision is the description of how things would look if the problem were fixed.
  2. The issue statement is a couple of sentences explaining the specific issue.
  3. The method is the process you follow to solve the problem.

A great way to build a problem statement is by using the 6 basic questions:

  • What?
  • Why?
  • When?
  • How?
  • Where?
  • Who?

These act a useful building blocks for constructing the statement.

It’s worth fleshing out each of these, and seeing how they might apply to a business environment.

- What is the problem that we are trying to solve here? What is its impact on the business and on customers/clients?

- Why has it occurred, what was the cause? And why is it important that it gets fixed?

- When does it come about? Is it a recurring issue or is it there permanently? Is there a critical date when it needs to be fixed by?

- How are we going to fix it?

- Where are we seeing the problem occur? Which products and processes are being affected?

- Who is the issue affecting? All users of a system or only certain groups?

Example of a strong problem statement

Let’s say we are a company that sells business insurance policies to IT contractors. There's a form on the homepage of our website that captures lead information in a CRM tool and sends it through to a contact centre. We are seeing that a significant proportion of people start the form and fill in a few fields but don’t actually complete it.

We want to build a problem statement here that will get us to as meaningful and valuable a hypothesis as possible to validate any experiments we might run.

So we might break the problem statement down in the following way:

We want to increase the volume of contractor leads on our web form, so that our sales team can convert them into customers. (Vision)

Currently we have a web form that a high proportion of visitors are struggling to complete, and this results in customer frustration and lost business for the company. We need to fix this problem by making the form easier to use. (Issue Statement)

We will run an A/B test to evaluate the success of any design changes. (Method)

Adapting a problem statement for a testing program

What we have here is a detailed statement that provides context and clarity to a business issue. Whilst it’s great practice to include all three elements of the problem statement, sometimes the sheer volume of experiments you’re running calls for brevity.

At the very least we would recommend recording the issue statement on paper. You can communicate the vision and the method verbally if needs be.

Next stop, the hypothesis

Once you’ve mastered the art of creating problem statements you’ll be in a great position to craft water-tight hypotheses that can support your experiments. The content of the hypothesis should follow on logically from the content of the problem statement. We explain how to create a good hypothesis in another blog post.

Conclusion

A solid problem statement is unquestionably a useful weapon in the conversion rate optimiser’s arsenal.

If it’s well-crafted it will act as a conduit between a business objective and an experiment hypothesis, and will serve as an effective communication tool to anyone who has a vested interest in the issue.

Have a go at writing some yourself, and let us know how you get on. We’re confident you’ll find it helps to give your testing program more focus.

Back