A reader left a comment on this blog post I wrote in 2011. The Easter Coder suggests an enhancement to the technical solution I cobbled together for a problem I was facing at the time. After looking back on that solution now that eight years have passed, I’d like to offer a different perspective.

I don’t remember exactly what business need I was trying to address when I came up with that solution eight years ago, but I look back and shake my head. It seems like an awful lot of work for questionable benefit. I almost certainly could’ve been working on something more valuable. And it’s likely I wasn’t even solving the right problem!

If I could give my past self advice, I would encourage him to stop, ask the business some questions, look for different ways to define the problem, explore solutions for one of those different definitions, and, of course, determine the impact of simply not doing anything.

At the time, my understanding of the problem was that my team was delivering files that were too big for business users to view in Excel; so I solved for that problem. Here are some obvious alternative problem definitions and possible solutions I could’ve explored:

• business user software is out of date — IT needs to update their Excel
• business user is using the wrong tool to ingest large files — work with them to find a better tool
• business users have no direct access to data they need for decision making — they need tools, access and training

Of course, there are a lot of other assumptions implicit in all of these options that I never stopped to question.

It’s important to keep in mind that when people bring problems to you, they have already been stepping forward toward a solution from early on. They are bringing you in down the line, after they have already made some early assumptions and decisions. Although they often do their best to share those things with you, a lot of them are no longer obvious or visible. That includes the most important assumption of all: that this is something that must, in fact, be done! Due to this, it’s up to you to walk back a little and help them make the initial framing of the things visible, then challenge it. This will help you explore if (a) they really need it, and (b) if there are different ways to look at the thing.

The US Army TRADOC published a Framework for Strategic Communication that offers three questions I’ve found helpful when working with the business on requirements:

1. What problem are we trying to solve?
2. Why is this a problem that we need to solve?
3. When we solve this problem, what do you think that looks like?

These questions will help you uncover those hidden assumptions and decisions somebody made before bringing a problem to you.

Going back to the original problem I was presented with, I could’ve stepped back and asked the business these questions to explore more. What if I had uncovered any of the following?

• They assumed they should ask for the whole dataset but they really only had a few narrow questions that could’ve been answered with summarized data that would not have created a size issue in Excel.
• They were looking to supplement data that was missing for some screen on a key application, which could’ve been better addressed with a config or customization of that application.
• They believed their manager wanted it but after pushing back a little, they checked with their manager and it’s not what they actually wanted.
• They were sending that data to another system or party, which is something my team could’ve automated and sent directly.

Any of those may have been valid but I didn’t dig into the problem enough with good questions to find out.

Often, a great solution is simply the natural result of pushing to develop a great problem definition. More often than not, this means solving for a different problem than one initially presented to you. It pays to explore the way a problem is framed and ask the three questions above are tools for doing that.

Update: 20191023

An inveterate tweaker (this is revision 38), I changed the title of this from “Solve the right problem” to “Solve a better problem”. That title is a better fit for the article and I believe establishes a better frame through which to view problem-solving!