Design thinking and problem statements
Modern innovation practice is underpinned with concepts such as design thinking. The point of processes like these is to spend as much time up front to understand the problem and understand thoroughly before we jump right in trying to fix things. A core tenet of design thinking is to really, truly evaluate the problem and write a clear and distinct problem statement. So, let’s start there - what is a problem statement?
A problem statement is just what it says. It’s a way of defining the problem as wholly, but clearly and concisely as possible. The thing is, defining a good one takes a lot of practice. Sometimes if we’re not very familiar with an issue we take what a user has said and make that our problem statement as-is.
For a number of years I worked on a helpdesk for a small IT managed services firm. We’d often have calls come in about issues such as:
“My phone isn’t working, could you please send someone to come take a look?”
Let’s assume we take the problem statement as-is. It infers a few things about the problem and it infers potential:
- the issue is the user’s phone handset
- the phone handset itself isn’t working
And it infers potential solutions:
- it can only be fixed by one of our team
- it can only be fixed in-person (“come take a look”)
Now, if you ran a business acting exactly on what a customer was suggesting you wouldn’t get much work done. You wouldn’t yield to every customer asking you to come round to have a look at a handset which, on the basis of their non-technical diagnosis, is not working. What if the phone itself wasn’t the problem? What if you could actually fix this in another way?
Sometimes it’s as simple as semantics. Some people say their phone “isn’t working” when it just isn’t working as they’d expect. Calls like this change dramatically when you ask them to describe what’s wrong and how they tested it.
“Well, when I ring my number it’s just going to voicemail and not ringing on the handset”
Ah, well that’s a different issue. Are you sure your phone isn’t just on DND?
Without getting geeky with the ins-and-outs of business telephony systems, this initial problem could have been caused by any number of issues. In my experience, some of these issues could actually be define with the following problem statements each of which have distinct potential solutions that don’t necessarily involve sending out an engineer:
- The phone is not ringing as the user has disconnected the phone
- The phone is not ringing as the user has left it off-the-hook
- The phone is not ringing as the building was struck by lightning and the whole system is fried
- The phone is literally smashed into pieces on the floor… and not ringing
These are real solutions I’ve experienced to the same initial call statement above.
The above can generally be triaged fairly quickly. In the grand scheme, a business phone system is a complicated asset but it certainly doesn’t generate problems which are complex or chaotic. Generally, there’s a set number of inputs that can be multiplied together to create a set number of outputs and with a bit of logic we can decipher the problem. Defining a good problem statement takes a large portion of the way toward fixing the problem. Investing effort up front helps save time later when you don’t have to send an engineer to plug the phone back in the wall.
When this becomes more pronounced in environments where there’s more to lose. If the cost of sending an engineer was scaled up tenfold then we might be extra vigilant about these upfront definitions of the problem. Or if sending that engineer was a massive risk from a H&S perspective, or would cause issues with operational SLAs.
A great example that was shared with me some time ago was for lifts/elevators.
Throughout the last 100 years, high-rise office towers have become commonplace in the growing metropoles of the US East Coast. The problem here was that as the buildings got higher, and the number of people working in the buildings grew more numerous the lifts were failing to keep up with the demand of the users.
Complaints started coming in that the lifts were too slow. Users we either waiting too long in the lobby, or waiting in the lift as it stopped floor-after-floor taking a long time to get to a destination. The building management consulted with the lift manufacturers to discuss solutions. The lift manufacturers assessed the available space in the building and stated that installing more lifts to increase capacity was going to be costly. Like real costly. Building management fed back to the tenants that increasing lift capacity would be a costly exercise - the feedback was not warm.
There was a deadlock. Users were unhappy with the time it would take to get to their destination within the building, the building management and lift company couldn’t increase capacity without dramatic engineering changes, and the tenants did not wish to foot the bill.
The story goes, as it was told to me, that a rookie in the building management company asked for a shot at fixing the problem. Except instead of the thousands of dollars for the lift capacity extension, he only wanted a couple of hundred dollars. The building management were growing tired of the discontent and decided to give the rookie a shot.
Within a few weeks a solution had been put in place and the number of complaints dropped dramatically. What did he do?
The real problem
The rookie started back at the original lodgers of the complaints - the lift users. He spent some mornings sitting in the lift lobby looking at the behaviour of the users. He wasn’t trying to prove or disprove that the lifts were slow, he was asking why having a delay was so impactful.
The problem was that the users were either bored or in a rush and didn’t want to wait. Therefore the problem statement shifted from “the lifts are too slow” to “the experience waiting around for the lift is too boring or a waste of time”. So how could you fix this problem?
The answer was mirrors. The rookie lined the lobby with mirrors. Suddenly the “bored” users had a source of entertainment, checking themselves out, and the “in-a-rush” users could save some time by fixing their appearance without a trip to the restroom. In both cases, by putting some mirrors up they dissolved the users perception of “waiting around”.
Whilst there was a solution in the techical domain that the lift manufacturers could address, there was an easier problem to fix in the human space. Innovation doesn’t necessarily mean you’re building something faster, or better in one domain, it might be that you’re fixing it in another domain.