What problem are we trying to solve?

From a recent meeting:

PM: Wait. Can we backup and talk about what are the problems we are trying to solve here?

Me: Sure.. but it's much more fun to talk past each other while we prematurely debate our solutions!

Let's face it: we in the software business love focusing on solutions. We love building things, and solving problems by building things. But this tendency leads us to focus too much time thinking about and debating solutions before we have really nailed down the problem we are trying to solve. Over time I have learned and re-learned the lesson that you almost can't spend too much time trying to understand and define your problem.

One of my favorite aspects of working with folks in Product Management is that those folks are trained to avoid prematurely jumping into discussions about solutions. They have learned from hard won experience that when anyone says "We should build feature X!", it is critical to back up, ask a lot of questions, and seek to truly understand the problem that that feature is meant to solve.

This came up recently in a discussion about a proposal that I had made for some changes to our project management process. I had been thinking about these changes for a while, so I wrote down a proposal and brought it to a group of Directors for discussion. The result of that discussion was not much progress on the solution, but a recognition that I needed to do more work documenting the list of problems that I was trying to solve. It was clear that lots of people had ideas about problems that needed solving, and so if we didn't agree on those problems and their definitions first, then the discussion about solutions was likely to go nowhere.

Without doing that work you will typically end up in a discussion with a bunch of people "talking past" one another: disagreeing about lots of different aspects of the solution because they've brought different ideas of what the problems are into the discussion.

I found the discussion ironic because I should have known better. I see this failure mode all the time. One of my primary bits of advice for folks in my org who want to do demos or project presentations is to explain the problem, in detail, right at the start. So many demos start with someone jumping in to show you some new feature and all of its cool details, but they just assume you understand the problem just like they do. But when you're building in a specific and detailed domain (accurately measuring TV advertising) it is quite likely that your audience has only a faint grasp of what problem your new feature even solves.

On the plus side I have been doing better with an architecture group that I have been meeting with regularly. Over a number of months so far we have focused almost completely on simply defining and documenting a set of difficult cross-cutting technical challenges faced by our org. People often want to jump into discussing various solutions, and I spend most of my time redirecting them to spend more time understanding and documenting the problem. We will get to the solutions phase eventually, but when we do we will have a much greater chance of success, and critically success of gaining buy-in for the solutions across the org because of the time we have spent documenting the underlying problems. It is much easier to evaluate a technical change when you understand the assumptions that the author was making about the problem to be solved.

This is a great tool if you ever find yourself in a discussion that seems to be contentious or going nowhere - ask yourself if everyone in the room understands and agrees on the problem you are trying to solve. Make sure you haven't skipped this step (even thought it's not as fun as debating the solutions).