Stop Solutionizing and Start Problem-Solving
I made up a useful word a while ago, though I doubt I’m the first to have done so. The word is solutionize, and it means “to come up with a solution for a problem that hasn’t been defined (and might not even exist).” Solutionizing leads to solutionization, or “any outcome of the act of solutionizing.”
This all sounds like nonsense, because it is nonsense. The word solutionize comes from materials science and has nothing to do with design.
Some blatant examples of solutionizing, as I define it:
- Designing an iPhone app for users who don’t have smartphones
- Building an MVP that addresses no customer need
- Creating UI for a service users want to get from a person
More common examples are things like developing a feature because you can, iterating and building without research, or selecting a platform or pattern before knowing the required functionality.
Solutionizing can’t always be avoided, and it’s a helpful word to have in your lexicon to appropriately acknowledge a known compromise. However, I find the word especially helpful in those blatant cases of “wait, what?”
The issue with solutionizing isn’t just that it’s silly. The issue is that it confounds success and begets failure.
It takes time and money to create something new, so it’s essential to understand whether the new solution is successful. Without knowing the problem, all potential metrics for tracking that success are reductive and simplistic ones.
Solutionizing, or designing a solution without defining the problem, makes it impossible to assess meaningful measurable improvement.
Beyond the inability to evaluate success lies something more subtle: the failure to spot opportunity. When you solutionize, you artificially narrow your scope. This can eliminate innovative solutions to real problems, and the cost of missing that opportunity is incalculably high.
The solution is the problem, and the problem is the solution. By that I mean, often we understand a problem by working to solve it, but focusing exclusively on the solution can obfuscate whether the problem actually exists. Define the problem, and you’re on your way to successful solutions instead of solutionized solutionizations.
