Einstein was almost right
by A M Howcroft, SWARM CEO
Part 1 of 3
When Einstein famously said, “If I had 60 minutes to save the world, I’d spend the first 55 minutes defining the problem, and the next five minutes solving it”, he was sharing hard-won experience. Once you’ve got a clear problem definition, the solution frequently falls into place. But that’s not the whole picture. For one thing, problems aren’t static, and then there are other issues to contend with – such as cleaning and preparing data, or picking the right solution from a panoply of choices. Then there are the human factors involved; research shows that people with a role that involves building solutions find it very hard to focus exclusively on the problem – they have a cognitive bias towards evaluating solutions, even before they truly understand the depth of the issue.
Let’s explore this and see if there’s a better way to solve problems. The potential pay-off is huge, and the twentieth century’s most iconic genius may have been on to something.
Why do we leap to solutions?
Human beings are wired to jump to conclusions. In Thinking Fast and Slow by Daniel Kahneman he talks about two systems of thinking, one operates automatically and quickly with no sense of control (or even knowledge that it’s happening) such as when you encounter a lion and decide to run, while the other requires mental effort and attention, such as if I ask you to divide 2380 by 43. You would think that in business, where we might be trying to understand a complex supply chain problem, the second form of thinking would take control, since it is clearly a task that requires care and attention. However, the book illustrates that there are many ways in which the intuitive ‘system 1’ as Daniel calls it, can hijack, or set traps for the slower way of thinking. It’s too easy, even for an expert, to see a scenario and associate it with a similar (but ultimately different) situation they have encountered before and therefore make assumptions and choices that result in a bad outcome.
This is where we get the adage ‘to the lumberjack, everything looks like a tree’. Given the exact same problem it would be very easy for a machine-learning vendor, a specialist consultancy, or a provider of analytics software, to arrive at three very different solutions that each felt was a natural fit for the challenge. Vendors market and sell solutions. It is not in their best interests for you to explore your precise problem, because this delays the sales cycle, introduces competitors, and you may find their solution is not a good fit to the problem.
You would think a business would therefore be more deliberate about defining problems, to ensure they find a good match. However, they have their own pressures. A good-enough solution may be all that is required to save money, and the duration of a long evaluation might be an expensive in terms of lost-opportunity. Also, many organizations spend months researching the market to discover there is no exact solution for their requirements. The question that many buyers end up answering is not ‘Which solution best meets the challenge we face?’, but ‘Which solution do we prefer?’.
The result is that a very high percentage of projects fail, because nobody took the time to understand the real challenge, and/or the solution chosen was not fit for purpose.
Challenge Accepted – and Identified
As a vendor offering an AI software solution, we were caught in several of the situations just described. We sometimes lost deals even after demonstrating value, at times because we helped a client truly understand the issue and they then found an alternative solution or decided it was now simple enough to build a solution with internal resources. Running a Proof-of-Concept and then seeing the client walk away is a high cost for a startup. This conundrum was the impetus for us to build the SWARM Challenge Modeler. I want to take you through that thought process, and share some of the lessons we learned. It won’t be a heavy sales pitch for the product - partly because it is free for anyone to use, anyway.
Defining and understanding a problem is crucial to solving it, and as Einstein said, it should be the primary focus of your efforts. That was our starting position, and we tried to do this on every project, but we hit the following snags:
We were not experts on the client’s business, so missed critical context
Managers at our clients were also not always experts, and missed critical context
Often the knowledge was spread through a few key individuals
Those individuals were often wary and/or too busy to educate us
Many experts were close to retirement, risking the loss of ‘tribal knowledge’
It took too long to document a problem, frustrating both sides
Every time, the document was different, and something was always missed
Documenting problems was an art, not a science
We decided there had to be a standard way to define a problem, that could be applied in a consistent way across every project. It would be critical for the client to be able to do this themselves, and it should be something a subject-matter-expert could do, without requiring IT or Data Science knowledge.
At first we looked to see if this existed. We found a few methodologies for defining problems, but most of them were very heavy on theory, and not something that an everyday operations person could use easily. We opted to test a simpler approach.
Building a Tool to Define Challenges
Following the Lean Startup approach from Eric Ries, we didn’t start by building a software tool, instead we wrote a Microsoft Word template. We also decided to change the nomenclature. Nobody wants to highlight all their problems because that is a negative way of looking at your organization, too pessimistic. We changed the terminology to call the things we modelled ‘Challenge Definitions’. Let’s catalogue and meet our challenges – sounds better, right?
The document was structured with sections we felt were important, such as the scale of the problem, the value that could be unlocked if it were solved, the constraints and levers. We talked to our key advisors, both academic and industry figures, about how they personally tackled problems – sorry, challenges – in their worlds. For about 18 months we wrote a Challenge Definition for every client project we performed. Here’s what we learned:
Lesson 1: people like challenge definitions. It gives everyone a short, clear explanation of the issue, what the goal should be, and the potential business impact and benefits.
Lesson 2: you getter better each time. Because we adopted a standard approach, we discovered you get better at defining and understanding challenges, the more you do.
Lesson 3: every challenge can fit a standard definition. Early on we were concerned that there was such a wide variety of problems in the real world, that no single way of defining them would be generic enough to help. That was proven false. With a few tweaks to the report, we found it applied to pretty much anything we could throw at it.
Lesson 4: there are huge advantages in separating problem from solution. First, it keeps a clear focus on the task, and neatly divides the skills required. The business often understands the challenge but IT or Data Science teams are more frequently engaged in the solution. You can also change either side and then review the impact on the other. A new algorithm in a solution does not require a change in the problem definition, for example.
Lesson 5: problem definition is a collaborative process. In modern organizations, it is rare to find a single person that fully understands every aspect of a problem. This is a team game.
This was all great stuff, but we were still having to write the documents manually, and we were not experts in the subjects being defined. We built a software tool to automate the process but realised some additional structure could be helpful. Therefore, we partnered with industry experts to define templates for the key challenges, such as supply/demand planning, labor management, and logistic planning. We made the templates one hundred percent flexible – so you could delete, add-to, or update any part of them as required since it was impossible to build a template that fit every business. We also set the system up so you don’t have to use a template, you can start with a blank page. The added structure and expert guidance is helpful the first few times you define a challenge, but not required. There are 30 templates available now, and that grows every month.
Einstein – the parts he missed
It’s great to have a clear Challenge Definition documented, and we hope our wild-haired genius would be happy with the progress we’ve made on this, but what happens next?
Well, getting the right data into the right format, and cleaned, is the BIG problem that Einstein didn’t foresee. The modern explosion of data would, perhaps, have caught him by surprise, and certainly adjust his 55-minute timeframe. We will look at how to solve that in part 2 next week, where we’re hoping for a magic AI-wand to make our data woes disappear. Spoiler alert – they don’t seem to be on the horizon yet. We will look at why not, and what can be done.
Part 3 of the process is to find a suitable solution. That, surprisingly, might be easier than it sounds. Great strides are being taken here, and we have a little trick up our sleeves. While the Challenge Definition document is beautifully presented for humans, it cunningly captures the meta-data that our data scientists (and our machine learning tools) need to match to an algorithmic solution. More on that in the final post…
For now, a great place to start in solving challenges in your organization is to begin by simply cataloguing them, and defining the size, scale, and value to be obtained if they were solved. You are welcome to use the personal edition of the SWARM Challenge Modeler, for free on our website, to help with this process.
I did promise to explain why we decided to make this tool free. The answer is simple: we think it adds tremendous value and can instigate change in the way people view and tackle challenges. That could have profound benefits for everyone. Secondly, it means we don’t burn our sales calories chasing deals where we are not a good solution. When we receive a Challenge Definition we can qualify in or out of an opportunity very fast – which is good for us and our customers. Who says altruism doesn’t pay?