Software is a solutions-oriented business. It's what we do: ship solutions as quickly as we can. But one common pitfall is jumping to solutions before defining problems.

It seems obvious to say "start with the problem." But it's easy to forget when you are in the thick of solution-mongering.

My manager reminded me of this a few weeks ago in a specific context, and it was a great help.

There are a lot of benefits:

• Problems explain "why?" Problems provide a shared sense of purpose in a way that solutions do not.

• Problems provide a north star. Starting with a problem asks the implicit question: "Does your solution actually help?"

• Problems allow for creativity. Two people can look at the same question and see different answers. By sharing the problem, you might learn of new solutions.

• Problems promote ownership. It's more inspiring to get problems to solve than solutions to implement.

Some examples of where this can help:

• Defining a new role: start with what problem the role will work to solve, not what duties it will do.

• Making a process change: start with the pains of the current process, not what you want the new process to be.

• Creating a new initiative: start with what problem the initiative tries to solve, not what projects you plan to implement.