Software creates value by solving problems. But effectively solving problems is hard. How can we get better at it?


I have seen it many times in different teams and projects: We are certain our users need a new dashboard view. It will solve all their problems. A month later we are sure the users need 3 more filter options on the dashboard, then all their problems will go away. A year later users are still loading data into their custom Excel file and barely anyone touches the fancy dashboard we built.

We create solutions without actually knowing what the problem is.

We all want to create value for our users. We want to create solutions that truly solve their problems. We want happy users. We want to build features that remain useful and do not become a burden down the line. So how do we create solutions that effectively solve problems?

It all starts with really understanding what the problem is.

The problem is not always what it seems and the most obvious solution might not be the best.

Spend more time understanding the problem, its scope and the potential solutions. It will pay off many times over.

Not only do you significantly increase the chance of building the right thing to start with - you enable yourself and your team to improve the product sustainably in the future.

Capturing your thought also process creates a powerful artifact to work with in the future:

No one gets everything right the first time. And that’s fine.

But you want to be able to look back and know which problem you tried to solve. What was the known context at the time? Which solutions did you consider? What was the reason to go with the chosen option?

With answers to these questions at hand you don’t have to guess why things are the way they are and you can improve the product with confidence.


I like to follow a simple framework to guide me through the problem solving process:

  1. Problem Statement: State the problem in a clear and concise sentence.
  2. Context: Describe the context. What do you know? What do you need to know? What matters? What can you exclude?
  3. Options: List possible solutions. What options can you think of? What are the pros and cons?
  4. Decision: Decide for a solution. Write down the decision and reasoning behind it.

Make sure you talk to actual users when establishing the context. Spent some extra time on listing options. Discuss options with others. Be creative. Think of combinations of solutions. Doing nothing is also always an option. Sleep over it for at least a night before making a decision.

After you made a decision and implemented the solution, make sure to come back to it. It’s fine to get things wrong. You are one step further in any case. You gained new knowledge about what doesn’t work.

Problem solving is an iterative process.

Repeat until you get it right.


A framework can be a helpful tool to guide our thinking. But to become really good at problems solving we need to change our mindset.

Create a culture that encourages people to ask questions, challenge assumptions and explore alternatives. Learning, reflection and active listening need to become part of your daily work. Establish a team of people with diverse backgrounds and perspectives. Encourage people to think of interdependencies, feedback loops and long-term implications when choosing a solution.

All this is not a simple undertaking and takes time.

Start by making time for it and lead by example.


Software development is problem solving. Focus on understanding problems.

Define the problem and the context.

List multiple solution options and document your decision.

Putting in this extra effort to clarify your thoughts doesn’t have to be a big undertaking. For simple problems it might only take a few minutes. Your future self will thank you.

If you like to learn more, I can highly recommend watching the talk Design in Practice by Rich Hickey.