[Guide] Framing Problem Statements

In order to get the right answers, we must learn how to ask the right questions first!

The philosophy behind Ideaspace is rooted in the theory that emanated in the early 1940s as a way of improving existing systems. It is famously called Systems thinking and it suggests that in order to solve problems, one must look at the system as a whole and cater the solution in such a way that the whole system is satisfied than looking at events in isolation.

If you think about it, naturally we think in systems. So once you figure out how this works, you’ll be on your way to framing problem statements quite eloquently.

All Systems are interconnected.

Nothing exists in isolation. Everything that exists and is performing a functioning is either dependent or is catering to the dependency of another functionality in the system. And hence it is important to figure out how things are connected when looking at a system. Try to mentally map all the elements that are connected to what you are observing.

What you see is the tip of the IceBerg

When looking at problems to solve, most people will react to what is an event. They order for food, and the delivery is late (happened once, happened twice) and they map it as a problem that needs to be solved. However what that was, was an event. The problem is usually much deeper and higher up the line, if you can get to it.

Events, Symptoms, and Structures

In the case of the above quoted example, the delay in delivery is an event. The symptom might be the fact that the restaurant prioritises diners more than take-outs, or prioritises customers more than delivery orders. Structures are one level above that, where you start looking at the overall landscape of food, the mentality of customers and how it is delivered.

Don’t fix events. Fix the causes.

For simpler understanding, You could rename these as Events, Causes and Landscape.

Events are what happens. Causes are what trigger these events (and you have to solve them if you want to change events). The landscapes are the platforms are which all of these systems stand - they are fairly complicated and also high risk. They involve building infrastructure to change things dramatically, but they also provide you with the ability to build dramatic moat if you succeed. They are tied to long-term trends and can significantly change everything. Clean breathing air, would be a landscape problem statement for eg.

Fundamental solutions take longer and are higher risk, but yield higher reward and are also long term sustainable.

Think one level in abstract - atleast in symptoms

It takes significant understanding of an ecosystem to tackle change and interventions in the landscape / structural level. At the same time events are the most tempting, but you must find a way to ignore them. For a sustainable and viable solution, you start in understanding symptoms (or the causes) and find a way to improve that. Fix those and you have a real solution in hand.

Examples

Let’s take an example that we can all relate to: Health. Let’s say someone gets diagnosed with a headache. It happens once, it happens twice. Yep, it is a problem to solve. The solution to a headache is a pill. You take an analgesic pill and you are good to go. Now this is fine, it is a simple headache, but lets imagine this is a migraine or there are far serious issues. Taking an analgesic and even taking far stronger doses of the painkiller, doesn’t really solve the problem, but masks it.

Understanding what causes the headache in the first place, would lead to a long term and healthier solution, rather than popping pills everyday.

—-

The other example that One could cite is that of punctuality. Your friend is always late for meetings. And the trigger here becomes the event - that people are late and we need an app for that. But if we start wondering why is the person late - do they take friendships lightly (some folks are bit relaxed when it comes to personal relationships than professional), or is it that he/she genuinely misses deadlines? Is it a habit or is it intended? Getting to the cause of it, usually gets to far more sophisticated insights and better outcomes. Solve the cause of the event. Start by identifying what causes it - or doesn’t cause the intended outcome.

Don’t go too niche

One suggestion that I would make when framing problem statements is to see whether there is a pattern there, that can be applied to a larger demographic. You don’t want to go too niche, and at the same time you don’t want to go too generic either. Zoom In / Out at just the right level.

Focus on patterns, not on the details.

Stay clear of needs & wants

The human mind has the gift of imagination and we also often ponder if life would be better if there was an app that could do X and Y. And then we walk backwards and create a hypothetical problem statement in our minds and try to solve them. Don’t do that. Find a problem that is real and ensure that it pinches, causes pain and makes you lose sleep.

Good luck and wishing you lots of luck!

An Initiative by The Startup Centre