BY PHIL WOODWARD, CEO - STEER73

What’s Your Problem? Our Problem First Approach to Projects

How much is it going to cost to build a new IT system or software product?

I have found the normal ‘formula’ businesses apply when considering the cost of software development is some function of:

T.(time to build it) x C.(daily cost of a team)

But this isn’t correct...

Any software product or system is built to solve a problem, and this formula ignores the largest variable, the most important question and the first thing you should be answering: what is the problem we are solving?

The actual formula you should think about is a function of

P.(clarity of problem being solved) x T.(time to build it) x C.(daily cost of a team)

Whoever said this, and however it is phrased, the point is simple: defining the problem is crucial to solving the problem.

Many businesses are good at solving problems but fail at properly defining what the problem is. The result of this can vary from spending longer than required to solve a poorly defined problem, through to a worst case of solving the wrong problem. When developing software products and systems, solving the wrong problem is particularly costly. It means modifying, pivoting or rebuilding what you have built.

Properly defining the problem will dramatically lower the overall cost of solving it.

This article describes the framework we use at Steer73 for creating a good problem definition, how we assess the quality of that problem definition and some tips for embedding a problem-first approach in your organisation.

1. Framework for creating a problem definition

2. Assessing the quality of a problem definition

3. Tips for embedding the process in your organisation

1. A framework for creating a problem definition

We always start any project with rigorously defining the problem we are solving, and we always come back to that as we develop a solution.

We use a simple framework to guide the problem definition approach:

Scale - Understand the problem scale you are operating at. Is it a feature or a product?

Duration - Define what duration of problem you are solving. Is it perpetual or temporary?

Engagement - Ask all stakeholders to define what they believe the problem is.

Definition -Synthesise this into an overall problem definition.

Alignment - Align and agree this with all stakeholders.

Refinement - Regularly revisit the problem definition(s) and refine them over time.

Scale

First, understand the scale of the problem definition you are trying to create. Is it a large-scale problem defining an entire product, or a smaller scale problem guiding feature development?

Why is this important? Well, how you define a problem is going to vary depending on whether you are just starting work on a new product, and need to define the overall problem your product is going to solve, or whether you have an existing and mature system and you want to add a new feature to it.

The principle of defining the product is the same, but the way in which you explain it and the level of specificity you require will vary greatly. Understanding the level at which you are defining a problem will also help ensure you know when you have reached a good level of problem definition.

We break down problems into three scales:

1. Product scale problem: what problem is this product solving

2. Module scale problem: what problem is this module of a product solving

3. Feature scale problem: what problem is this specific feature solving

An example to help illustrate this:

Peloton’s product solves the problem of staying fit without needing to leave your house. This is the high-level, product-scale problem they are solving.

When using the bike, the screen is the module that solves the problem of instructing and motivating you during a ride. It’s where you see your instructor, other riders, heart rate and so on.

The “high five” feature , where you can give other riders a virtual high five, solves a problem that riding alone can feel isolating vs. being in a spin class. It adds an element of social interaction.

Duration

Next, be clear about the class of problem being solved. Most can be summarised as either:

Perpetual: this is an ongoing problem, the solution we put in place will be required in the medium to long term (or, forever).

Temporary: this is a temporary problem, once solved it will go away, the solution put in place is required only in the short term to solve it.

A product scale problem is normally a perpetual problem. If you are building a software product then you should be solving a problem that is not going away in the short or even medium term.

A module or feature scale problem, however, might be short term. This helps focus the team on what needs to be built.

The product scale problem described in my Peloton example is a perpetual problem, it won’t change.

But there might be a short term, new problem that comes in that justifies rapidly developing additional features or modules.

A national lock down due to a viral threat, for instance, would be a very serious but temporary problem requiring a solution. In this case it is such a vast problem, that it justifies entire products be built to respond to it, even though it is temporary.

Defining problem scale and duration should not take very long, but it can spark interesting debate. And if you are developing new products it also forces the useful question: is this is a feature, or a product?

Engagement

You know the scale of the problem and its duration. Now engage with stakeholders to understand their view of the problem.

Product scale problems affect many stakeholders, and this is where it is critical to ensure everyone’s voice is heard. Different people in different roles will see the problem in different ways. You are trying to get as much insight into the problem as possible by speaking to a wide range of stakeholders.

Sometimes a problem might be very specific, e.g. an accounting matter that only affects the finance team. Generally, these are module or feature scale problems, and even in these cases the time should be taken to speak with different stakeholders.

How should you engage with these stakeholders?

Our approach is one-to-one interviews first, not a workshop. The problem with a workshop environment is that other people’s opinions will inform how those in the workshop express theirs, and you want to gather unbiased opinions at this stage. A simple 1:1 discussion is an efficient and effective way of doing this.

Definition

The next step is to pull all these different problem definitions together into a single, coherent description of what you are tackling.

When doing stakeholder interviews it is unlikely, and indeed not useful, for people to be thinking holistically, at product scale. They are likely only thinking about their problems, which is what you need. So, at this stage you will probably be able to create multiple problem definitions, at different scales.

Synthesising all these and breaking out problem definitions into different scales will help enormously when you need alignment of stakeholders. You can demonstrate to each stakeholder you have incorporated their issues into your definition.

The output you are looking for here is:

A single, high level “product scale” problem definition

One or more “module level” problem definitions, representing each stakeholder’s concerns

We wouldn’t advise getting down into feature level problem definitions at this point, that will come later in more detailed specification work.

Alignment

Using these problem definitions, you now need to ensure you are aligned.

You need to be careful here, this isn’t about proving you are right, or about trying to convince others your definition of a problem should be adopted. This is about taking what you’ve learned, what you think the problem is, and verifying that.

You might get agreement immediately, or you might find that now the problems are clearly defined people push against it and debate it. If it’s the former, then good job, you’re done. If it’s the latter, then good job as well! This is what needs to happen to avoid solving the wrong problem.

Work through objections, ideas, and refinements, keep synthesising these until you are aligned. Once you are, you’re ready to start work on solving it.

A tip.

Understand when to apply the 80:20 rule. As with many exercises you’ll get 80% of the way there with 20% of the effort.

Is 80% enough to start work? It can be if you ensure you follow stage 6, refinement. But if you do not think you will have the time to refine it later, it’s too important a problem to stop at 80%, or culturally your organisation is unlikely to do this, then spend the additional time now to get a better problem definition.

Refinement

Once the problem is agreed you can start work.

But don’t just set the problem aside.

Refer to it regularly. Start each meeting with a reminder of the problem you are solving. Write it down on the first slide of every presentation or in the first page of a hand outs. Make sure it is front and centre, and people are reminded of it.

Then, refine it.

As you learn more and understand the problem better, make refinements to the definition. This allows you to follow an 80:20 rule and start work with a problem definition that’s not entirely rounded out.

2. Assessing the quality of a problem definition

Having defined a problem, we measure a problem definition’s quality against three criteria. It needs to be:

Constrained: the problem definition places some constraints around how we solve it.

e.g. “Carbon emissions are too high” is not going to be a useful problem definition as there are no constraints. “Transport emissions are increasing despite a need to lower carbon emissions” is more useful, it places a clear constraint on what we are trying to solve – an increase in transport emissions. Though this is still broad…

Specific: the problem definition is specific around what needs to be solved

e.g. “SUV emissions are increasing despite a need to lower carbon emissions. This is due to an increase in sales of larger SUVs vs. last year. We need to solve the problem of why SUV sales are increasing.” – this is more constrained than before, it is about SUVs, and it's now more specific, we are looking at curbing sales. Without this specific statement we could decide to work on an engineering solution to reduce SUV emissions.

Compelling: if you can, wordsmith the problem description to make it more compelling. This could well be the clarion call at the start of a long project. Having a clear call to action will motivate the team to solve it.

e.g. “Climate change is the greatest threat this generation will face, and it is getting worse as more people are buying SUVs. We need to work out how to slow down sales of SUVs and contribute to the climate change fight.” It doesn’t need to be Churchillian rhetoric, just something that you know will galvanise your team.

It’s worth mentioned that it is assumed certain sense checks have been applied here as well. The problem the organisation is setting out to solve is solvable by that organisation, and the problem definition is easy to understand. But just in case, you can add:

Solvable: what you arrive at needs to be solvable within the resource constraints of the organisation (time, money, expertise).

Simple to understand (/plain language): it doesn’t use unnecessarily complicated terminology.

3. Tips for embedding the process in your organisation

A problem-first approach is not inherently difficult, but it can be perceived as taking more effort. It is important to demonstrate that it is not more effort overall, it’s less. Yes, it means delaying what is considered the ‘start of the solution’, but it ensures you have a smoother path to the solution.

This might require a cultural shift in how you operate. Here are some tips for making that shift and embedding this approach in your organisation:

Ensure senior management and project leaders lead by example.

Always start a project meeting with a reminder of the problem being solved

Practice regular exercises to embed this approach as part of your culture. This could be regular reminders to people to “state the problem being solved”.

Avoid “solutionising”: if someone starts telling you their solution, STOP! Back up immediately and ask them to go back to the problem they need solved.

Don’t assume you’ve nailed the problem definition, and regularly ask whether the problem is better understood or could be clarified further. This is part of refinement but also embeds the practice.

Know when to apply an 80:20 rule. You will get 80% of a problem definition in place with 20% of effort. That’s often enough to get going. This also helps keep a sense of momentum in the organisation.

Still work on the 20. If you start work with an 80% defined problem, then keep working on the remaining 20% as you work through the project. This will help you course correct during the work, and again reinforce the problem-first approach.

At the end of the project, when you’ve completed your work, take a moment to revisit the original work around problem definition and reflect on, or even celebrate, how it helped you create your solution.

Summary

Organisations that are good at defining problems will perform better. You’ll spend less time creating your solution and avoid solving the wrong problem.

To give your people a head start follow our simple framework for defining a problem.

Scale - Understand the problem scale you are operating at. Is it “Product scale”, something that defines the entire product or system, “module scale”, a sub-set of this overarching problem defining a component of your product, or “feature scale” relating to something that would be a specific feature.

Duration -Define what duration of problem you are solving. Is it a perpetual problem that will remain unless solved or a temporary problem that will end in the short term?

Engagement -Ask all stakeholders to define what they believe the problem is. Use one-to-one interviews to engage them in the most efficient and effective manner.

Definition -Synthesise this into an overall problem definition. Define one high level problem definition but also other more detailed ‘module level’ definitions which can be used to gain alignment.

Alignment -Align and agree this with all stakeholders. Use workshops where appropriate and if everyone agrees first time, well done. If not, work until alignment is achieved.

Refinement -Regularly revisit the problem definition(s) and refine them over time, all the way through to project completion.