Wondering what is problem-solving?
I read about Design as Problem-solving in recent years.
But then wondered, what’s something that someone is doing around me that doesn’t qualify as problem-solving?
To be honest, I struggled to come up with an answer.
Felt, maybe I don’t understand the word enough. For better clarity, I asked myself “How would I explain the word Problem and Problem-Solving to a kid?”.
The best answer I settled with for the kid is
A problem is a gap/obstacle between What You Want and What You Have. Problem-solving is all about finding an answer to reduce/eliminate this gap/obstacle.
Some examples of problem are
Office commute
- What I want — 10km of commute should finish in < 30 min.
- What I have — At peak hours it takes up to 60–90 min.
- Gap/obstacle — Traffic jams and congestion due to construction work, lack of public transport, and carpool culture.
Food
- What I want — For better health, I want to eat home-cooked food. Willing to hire maid as well.
- What I have — On a typical day, I eat homemade food twice. For lunch and evening snacks I order from the restaurant.
- Gap/obstacle — Cook not available at my desired time or bad experience with the previous cook.
The answer to these problems could be in the form of design, policy, rules, formula, product etc.
Given this outlook, problem-solving is not profession centric. It’s relevant to anyone. Its applicability comes into existence once the problem is established and defined.
In a product sense, it implies
If we kick-off UI conceptualization without defining “what problem we are trying to solve?” … we are not solving a problem. Designing without a problem definition is gamble and not problem-solving.
If we ship a product based on coffee-table discussion and unvalidated assumptions … we are not solving a problem. Mind you, more than 80% of the startup shut down. A vast majority shut down because they were late to discover that there’s no need for what they had built.
In simple words, without a problem, there’s no problem-solving.
Secondly, finding an answer could be an individual act as well as a team act. For eg:-
Entrepreneur or Intrapreneurs commits to find an answer that’s
* Feasible — doable or buildable now.
* Viable — doable or buildable in the long run too.
* Scalable — easy to expand things on demand.A designer drafts an answer at the intersection of need of the served (customer) and the intent of the committed (entrepreneur).
An engineers finds an answer for “how can we execute best with the resources available?”.
Bottom line
Problem-solving relevancy lies with approach rather than domain. Addressing a real problem forms the basis of its applicability. The value of a solution lives or dies at the intersection of the need of the served and intent of the committed.
