“We must not fixate on what this new arsenal of digital technologies allows us to do without first inquiring what is worth doing.” – Evgeny Morozov, To Save Everything, Click Here: The Folly of Technological Solutionism
In my last post, I talked about how a product manager’s job is to distill problems.
This post features some categories into which I fit problems. “Why categorise?”, you ask. Well, because our framing of the problem has a great impact on what type of solutions we devise and whether it is worth even trying to tackle them with technology in the first place.
Distinction 1: Known vs. Unknown
We either know what the problem is, or we don’t.
Whether a the cause of a problem is known or not is unrelated to whether you know what to do about it. Nor does it matter whether the problem has been seen before (See Generic vs Unique). How many other people have other theories on what the problem is is also irrelevant (See Wicked vs Tame).
Unknown problems occur either:
- When we know that something is wrong, but are not sure exactly what. That’s where additional research is needed to define the problem.
- When we have no idea that something is wrong. For obvious reasons, we don’t dwell on that here. Not a lot we can do about them.
Beware unknown problems masquerading as known problems!
Problems are slippery and often evolve over time. Never stop asking questions to make sure you definitely understand the beast you are dealing with.
Distinction 2: Generic vs. Unique
The problem is somewhere on a spectrum between generic and unique to the situation and context we are facing. I frame this as a spectrum because I don’t believe that problems are ever entirely one or the other.
In the case of generic problems, wisdom from those who have dealt with similar problems previously may help in devising the solution.
For unique problems - creativity is key to devising the correct solution.
Distinction 3: Wicked vs. Tame
“[A wicked problem is a] problem in which the various stakeholders can barely agree on what the definition of the problem should be, let alone on what the solution is.” Source
A tame problem is simply a problem which is not a wicked problem.
Characteristics of wicked problems:
- incomplete or contradictory knowledge about what constitutes the problem,
- a large number of people and opinions involved,
- the large economic burden involved in solving the problem, and
- the interconnected nature of the problems with other problems
It’s important to note that attempts to solve wicked problems are likely to change the very nature of the problem. For example, a campaigning intervention (say, absailing into an important political meeting to disrupt it via an unguarded skylight) used by an activist to disrupt a political event in support of a campaign goal may not be used again, because those who it is being used against will know to put in place mechanisms to stop it next time.
Examples of wicked problems
- Tackling climate change
- Recovering from the financial crisis
- Solving political instability
We may never convince everyone that a wicked problem has been solved, because of all of the different definitions of what the problem was in the first place. So particularly, in the case of wicked problems, we need to learn to pick our battles.
A problem can fit into multiple or a single one of the below categories. For example, a problem can be known, generic and tame, unknown, unique and wicked (ARGH!) - or some combination. A large problem will usually be composed of many smaller problems.
How accurately we define the problem will define how accurately we are able to tackle it.
An accurate assessment of a wicked problem will not turn it into a tame one, but it will inform our expectations and our tactics in how we go about tackling it.
That doesn’t mean we shouldn’t try or start. But with so many problems to pick from - how do we know which ones are worth fighting for?
Distinction 4: Crunchy vs. Fluffy
To help me pick my battles I have what I call a ‘crunchy heuristic’. (The opposite of ‘crunchy’ is ‘fluffy’.) I call a problem ‘crunchy’, when I can get my teeth into it. In a practical sense, this means:
- I can imagine at least one headache of a person who is personally affected in some way by this problem. Note that this means that I both have to have a specific person in mind, not a vague abstract term, like ‘a citizen’. The person has to have a face and I have to be able to imagine why they would care or interact in any way with the solution.
- I have to be able to generate some kind of hypothesis about how I can help them (in this context, with the aid of technology)
The balancing act
So, you know what your problem is. Is it unique or genuine?
Whether it is a project to fight government corruption - or a dashboard to track the spread of a contagious illness, a lot of technology projects in NGO land are only one part of a solution to a wicked problem. In a wicked ecosystem: egos, agendas, poor communication, language barriers, cultural norms and a pile of interwoven problems all make the difference between success and failure.
This means two things:
- Have realistic expectations - your technology project will not fix a wicked problem on its own. You and your tech project are going to need a lot of friends to share the load.
- Have realistic expectations - if your technology project does not fix everything, that is ok. Take a look back at the problem statement you originally set for yourself was one that technology could be expected to fix.
In wicked problems: human factors and technology often intertwine heavily. Make yourself a list of problems within the wicked one that are going to need to be fixed by diplomacy, charm, education, outreach or outrage and then come back and look at your problem statement again.
Does the problem you are trying to solve still look the same?