One of our maxims at thoughtbot is to start with the problem, not the solution. It seems obvious at first, you need to know what you’re solving for, but I often catch myself jumping ahead and skipping out on some juicy divergent thinking. It takes an occasional reminder to catch myself as it happens.
When kicking off a new project, start with the problem
The first thing we do when kicking off a new project is to get everyone in a room and collaboratively define the problem. If you skip this and start with a solution, you might get stuck on it and internalize your assumptions as truths. You may also close yourself off from exploring other competing ideas, which greatly limits creative thinking.
Let’s take the example of a property owner trying to incentivize her tenants to reduce their energy bill.
Solution first: Create a service for our tenants to compete against each other so they’ll reduce their energy consumption
…could be restated as…
Problem first: How might we get our tenants to reduce their energy consumption?
Starting with the problem allows you to explore many solutions without getting attached to any one in particular, which significantly increases the likelihood of success.
It can also serve as a guiding light to help focus all future product decisions. Does this new feature work toward solving the problem? If not, say no.
When writing a story for a new feature, start with the problem
When we see something that needs fixing, there’s often an immediate solution that jumps to mind. It’s tempting to add that to the Next Up column in your project planning.
Solution first: Filter energy consumption by tenant
If someone else were to come and pick up this story as written, they would have no context for the frustrations and experience surrounding this. They’d be designing (or developing) without compassion, empathy, or understanding.
Again, this is also limiting in considering other options. By restating it as…
Problem first: Tenants are unable to compare their progress to others’
…we can now consider many alternate solutions, with much greater context. This is where job stories come into play.
When giving feedback, start with the problem
It’s important that we respect our fellow designers and their ability to design independent solutions.
Solution first: The tenant’s name should be bigger
…could be restated as…
Problem first: The text’s hierarchy isn’t clear
There are many ways to improve hierarchy other than font size.
When giving feedback, presenting a solution instead of the problem can imply that we know more than the designer, and don’t trust in their capacity to do their job. It also stifles creativity.
It takes practice
Our culture raises us to come to the table with solutions, good or bad. It takes repetition, patience, and restraint to decide not to put solutions on the table, and instead reframe something as a problem first.
At the end though, our work is better for it.
