The teams at Claromentis often take it in turns to give lunchtime talks about their recent tech discoveries, passion projects, or an interesting book they just read. These talks are a great way to boost knowledge sharing across the company, giving people an insight into how other teams work and enabling staff to learn something new. Afterwards, the speaker shares their talk on our company intranet, so that anyone who couldn’t attend at the time doesn’t miss out.
Recently, our CTO Mike Christian gave a talk about a simple trick that can make problem solving a breeze. Taken from a mix of design and project management best practises, this hack can be applied to any business problem – from investigating the root cause of a software bug to diffusing a customer complaint – helping you get to the bottom of issues faster and more effectively.
Below is Mike’s talk in a nutshell – we hope you find it useful for resolving problems in your own organisation!
The problem with problems
When you encounter a problem – whether that’s getting stuck on a website login page or finding that your phone doesn’t switch on – a common reaction is to declare that it “just doesn’t work”. This is ultimately an emotional response, and doesn’t give you the information you need to create a solution.
Henry Ford, inventor of the car, understood this type of response when he famously said: “If I had asked people what they wanted, they would have said faster horses.” He knew that the real problem wasn’t that horses were too slow – it was something much bigger, and something that people couldn’t quite put into words.
And so the trick is to dig deeper, getting as much information as possible about a problem so that you can understand the user’s needs. This is where an effective problem statement comes in.
The problem statement
A problem statement is a set of guidelines that helps you frame an issue in a way that’s free from bias or emotion, so that you can focus on creating the best possible solution.
One way of creating a problem statement is using the “5W2H” method (catchy!), which is a series of questions that helps you decipher the issue. For example:
Why is it a problem? I need a day off to visit family.
Where does the problem occur? On the holiday booking system.
Who is impacted? Me and my co-workers.
When does the problem occur? It started yesterday.
How does the problem present itself? I get an error message.
How often does the problem occur? Every time I try to book holiday.
By asking these questions, you end up with a fully formed problem statement that you can use to create an effective solution.
User stories
Another way to write a problem statement is to use a method inspired by user stories, a process followed by UX designers when creating the look and feel of a product to ensure it’s easy for people to use.
This method puts you in the shoes of the person using the product or service, so that you view a problem from their perspective. A classic user story framework goes like this:
Trying to… (ie, what are you trying to achieve?)
But… (ie, what’s stopping you?)
Because… (ie, what’s the cause?)
Which makes me feel… (ie, what’s your reaction?)
To take the same example as above, you’ll get a problem statement like so:
Whichever method you choose to create your problem statement, by investing a bit of time in fully understanding the issue, you can reach resolutions faster and more accurately.
