The Problem Defines the Solution

“Given 1 hour to save the world, I would spend 55 minutes defining the problem and 5 minutes solving it” - Not Albert Einstein ^⊙

It’s unfortunate that we don’t know who said that. ¹ I know an untold too many quotes are attributed to Einstein, and I have no problem believing he COULD have said it. The problem is that as best we know, he did not. Even funnier is that 3 months from now you may likely drop the “NOT Albert” part of that quote and just succumb to the natural tendency to give smart people all the credit - but lo that is the topic for a different post.

Backwardness

It is incredibly challenging to the know the answer to something without the context of the question. However, all too often as engineers, as technologists, as software people, as gadget people, we think up solutions seeking a problem.

This may feel comfortable because it is a natural exploration of capabilities - said differently - it is an exploration of what we COULD do vs looking at what pervasive problems our users have and are willing to pay us to solve. We often come up with these inside-out ideas when we are actively listening and physically observing users in the wild.

Pre-Game Chatter

Undoubtedly, there is a real place for inside-out ideas, and some of the most innovative ideas are in fact inside-out ideas. But more often than not the second product in a category wins. The inside-out ideas have to do so much to flush out the idea - more importantly, the market they intend to serve. This market education helps them - but helps their competitors as well.

Without a problem - there can be no solution. Without a problem - many solutions are all on equal footing in terms of architecture, implementation aspects, etc. Like teams giving “spirited banter” before a game - everyone is entitled to their opinions before the game starts. With enough time and constraints, only one team will win. (unless it ends in a silly tie)

SimilarlyThrough the lens of a problem statement, one and only one best design pattern arises, a single architecture emerges in terms of how to serve millions of similar users, and there are objective facts to grade alternate solutions.

A Great Problem Statement

Like the snorkelers shown in the image at the top of this post; consider someone who loves to swim in the ocean with fish. They have distinct and concrete problems.

1. It is hard to see clearly underwater to look at the fish.
2. It is hard to look at the fish for extended periods of time since I have to hold my breath
3. If I want to get a better look at the fish, swimming is though in the open water - even though I can swim proficiently in a swimming pool.

From these three statements - clear solutions “fall off the bone” like expertly cooked ribs.

Writing while you are hungry has its occupational hazards. Perhaps the only thing more dangerous is reading this post while hungry.

But these problem statements coupled with some design considerations about human factors results in a standard (or even best) design for goggles to allow snorkelers to see, fins to aid in swimming, and lastly a tube called a snorkel allowing swimmers to stay face-down in the water observing the underwater wildlife.

Great Problems impart a few things:

• Who is the user so we can make assumptions about a typical user
• What is the pressing problem that needs help in solving
• Why is this is a problem, what is the user’s goal or motivation

** References: **

1: Not Albert Einstein from QuoteInvestigator