It seems rather silly to propose such a simple practice as solving a single problem each day. I have to agree, it is. But my experience reveals that it is not put into practice as frequently as it should. More often than not I’m asked to solve a problem that immediately reveals itself to be too big, and the moment it is broken down the whole thing runs down smoothly.

The biggest impacts this practice brings are evident and, quite honestly, tame:

1. Consistent execution: the simpler your problems become, the easier it is to solve them.
2. Increased focus: smaller problems are easier to tackle, and the cognitive barrier to focus is significantly reduced.
3. Better time management: if the problem is smaller, it is far easier to control and plan for a solution.
4. Increased trust and accountability: especially in a team setting, you become more dependable if you manage your time more effectively, all because you know how to tackle problems effectively.
5. More predictable estimates: as contested as it is, estimates are still a part of work and life. Breaking down problems into smaller chunks reduces cognitive barriers to estimation.

As uninteresting as these benefits are, they qualify as foundational for productivity, both at the individual and the group level.

Why break stuff down?

There are at least three categories that deserve our attention, especially as professionals who have problems to solve, such that if left unsolved do not spell the best fate for the business.

First, the category of time. When teams are tasked to solve a problem, they are often required to provide an estimate of completion. The request itself may seem inocuous on the surface, although from experience it usually causes unintended — sometimes harmful — effects.

An estimate, by definition, is uncertain. It has a non-commital nature to it. The main goal of an estimate is to guess the extent of something within a degree of reason. Therefore, it is not meant to be taken as a hard figure to any schedule. Also, the likelyhood of the estimate being met is almost 0%; it’s almost like it’s meant to fail. I would submit that taking estimates as binding commitments is a serious error in judgment.

There’s even a worst offender in the software industry in particular. Too much time is spent on too many meetings just to provide estimates for someone else. I have heard someone say that the one reason for their subpar performance review was their “inability to meet estimates”. You might be asking why I share these stories and the reason lies solely on culture. Solving problems is the task, not estimating the time it takes to do it. It is far more profitable to understand the highest priority problem and break it down to the point of being able to show daily progress than to spend hours or days proposing an entire schedule without any hint of certainty.

If you’ve ever estimated effort in planning sessions or so-called “refinement meetings”, you know the frivolity of putting a number on ten user stories at a time just because some executive says they have to. When the focus is more on slapping a number than it is to understand the problem to be solved, it must be called out.

On balance, breaking down a problem rethinks estimation completely, from how long does this big thing take? to how big must the thing be to take a single day?. As long as the culture prioritizes true understanding over religiosity or unwarranted commitments, it should be fine.

Then there is the category of scope. Depending on the magnitude of the problem being solved, it is very unlikely that the whole solution will be conceived quickly and effectively. Therefore, it comes as no surprise to realize the benefit of breaking things down.

The process of discovery engages the mind on details that otherwise are neglected. A problem well solved presupposes the entirety of it is exposed to begin with. This is not to say that it will be exposed fully on the first try, but it is important to keep poking until it is. This is the very tenet of complex digital products: to learn about their customers and their problems, all the while figuring out tiny bits of a solution and checking if they work.

A problem too big can be approached tactically through mapping. Much like a project has a hierarchical list of tasks, so do problems. If there is a sequence, it can be mapped. If there are rules, they can be mapped. If there are people or roles involved, they can be mapped. If there are options to choose from, they can be mapped. This form of analysis brings clarity to an otherwise dim perception, and the categories that emerge give structure to our thoughts and ultimately shape our response, one that preferably prompts us to ask: what can I do in a single day?

Finally, the category of risk. Every problem left unattended carries a risk, and so do solutions. The challenge is when the magnitude of each of them is so grand it is paralyzing; and that is a risk in and of itself. There is the odd possibility that the perceived risk is not real, only because our observation is distorted by such perception. It is also possible that the perceived risk is admittedly real, but we can only come to that conclusion if we explore the risk itself, not just the problem at hand.

The same way a problem is broken down, so can risk be subject to the process. Rather than asking if this is not addressed, what happens?, it is perfectly reasonable to ask instead, what happens when this portion of the problem isn’t solved?. Decomposing risk is just as valuable as decomposing the problem.

Why a single day?

The 8-hour window is the most natural timeframe. It gives enough room to frame problems the right size and accommodate distractions if they happen. It also provides enough structure to work together with others by planning early, executing throughout the day, and reviewing the whole exercise at the end.

While it is possible to experiment with more or less time, the rhythm of a single day is ideal, not only for the reasons mentioned but also for balancing our personal lives. When a problem is successfully tackled in a day, the body and mind respond positively, which provides longlasting benefits for the person, his family, his team, and his communities.

How to respond

We have established that the fundamental technique for figuring out time, scope, and risk is decomposition. There are many ways to go about it. Depending on the nature of the problem or solution, different shapes apply.

1. Anything that enhances visual understanding is indispensable, even if you’re not a visual person. A problem well understood is half the solution, and visual aids that support breakdown sustain that outcome considerably. Good examples of this include:

   • Written outlines: checklists, agendas, decision trees, lesson plans, indexes, etc.
   • Graphical outlines: mind maps, process maps, story maps, fishbone diagrams, etc.

2. Ask open questions. They trigger a brain reaction that forces it to look for an answer. When that happens, problems don’t look so big anymore, and teams start to unlock ways to move forward. Here are some good examples:

   • How long does this take?
   • How much of a problem fits in a day’s work or less?
   • How important is this problem that it must be solved?
   • How is X more urgent than Y?
   • What happens when I do X?
   • What is the reason for this problem to exist?
   • How can I make this big thing into smaller things?

3. Identify your detractors. Most of the challenges behind solving problems is not what we expect to happen but rather what we don’t. When that happens, face it, deal with it and find ways to prevent it from happening again. The Eisenhower Matrix is a great model to get started with. If you don’t know what it is, here’s a rough gist: you either do it, schedule it, delegate it, or drop it. These unexpected circumstances are guaranteed to happen; it’s quite the paradox. It is, however, your responsibility to handle them properly in your planning. More detractors usually means smaller problems to tackle at a time.

4. Plan together, work together, review together. A task done is not a problem solved. Therefore, the scope of what you plan goes beyond that two-hour task. A problem solved usually means that the benefactor of the solution is banking on it. An entire team may do fifty tasks in a day, but if someone gets zero benefit from them, consider it a loss. One problem well solved is worth a fortune compared to ten problems half-solved.