Defining the problem to solve helps you avoid waste

A mis-attributed quote teaches us how defining the problem helps us get more done by doing less.

Starting off this week is a quote about problem solving often attributed to Albert Einstein, but may have come from the head of the Industrial Engineering department at Yale University:

If I had only one hour to solve a problem, I would spend up to two-thirds of that hour in attempting to define what the problem is.

There are few variations out there, but the premise of the quote is its worth spending some time figuring out a problem before you try and solve it.

But what if your first hint of a potential problem to solve is a request to deliver a solution?

Like I mentioned last week, that’s what people who work on internal products regularly face.

When I had been away from that article for a couple days, I realized I repeated a common pattern among product management advice givers - give some general advice with the implication that advice works in every situation.

Oops.

Now granted in the case I was talking about, the advice to ask some questions is fairly applicable to most situations. What differs is who you ask those questions, how you go about asking the questions, and what what questions you ask.

So not that much difference, really.

But seriously…

When you provide advice that leads with a technique, you’re bound to encourage people to try and shoe horn that technique into every situation, whether it fits or not.

Kind of like that old saying, when all you have is a chainsaw, everything looks like a tree.

Or something like that.

So in lieu of leading with a technique, here’s a story about a specific situation that you may face and how I addressed it, at least this time.

I do mention a technique, but the key point is the scenario in which I used it to help define the problem. Your mileage may vary.

The Situation

In the before times, I coached product owners and the teams they worked with at a retail company. One of the teams supported the operations of pharmacy part of the companies operations.

This team received a request to support a new express pickup option for pharmacy locations. The team was just starting to move from a typical IT fashion where they merely acted on change requests to a partner with the business unit where they worked collaboratively to identify solutions.

They knew something was up because their main contact in the pharmacy business unit sounded a little skeptical about whether it made sense to create an express pickup option. The contact implicitly asked the team to help explore whether the idea really made sense.

In addition as members of the product team started to think through the technical implications, they came up with several concerns. Many of which circled around concerns about privacy, HIPAA compliance and PHI.

I offered to facilitate a discussion about the initiative with key members of the pharmacy business unit and the product team. My intent was to provide an example the product owner could refer to for similar discussions in the future.

What we did

The setup

I scheduled a conference room for the discussion and hung up ten pieces of flip chart paper. On each piece of paper, I listed a question from the internal product opportunity assessment:

• What need will this satisfy?

• For whom do we satisfy that need?

• What can be gained from satisfying this need?

• How will we measure success?

• What alternatives are out there now?

• Do we have the right people to satisfy this need?

• Why now?

• How will we encourage adoption?

• What factors are critical to success?

• Is this problem worth solving?

I then threw a bunch of post it notes and sharpies on the table of conference room. I wasn’t sure if I’d use them for the entire exercise, but I’d rather have them available.

Then I had everyone pile into the conference room. We probably should’ve used a bigger one, but it was what was available. We overflowed a bit because we had the typical case of the small number of people who were inviting adding others.

Remember, this was a mix of people from the Pharmacy business unit (including the operational folks who came up with the idea) a few members of the product team, and some managers from IT. I could get into the politics of who all attended, but that’s a blog post for another time about stakeholder management.

From the perspective of the product team, I wanted to make sure the product owner and tech lead (ie architect) were there. As for everyone else, I left it open - come if you’re interested, but if you have other things to do, you don’t need to.

The discussion

I kicked off the discussion with a little background, then asked the folks who came up with the idea to describe it. Their description consisted primarily of describing the idea in terms of a solution. They mainly stuck to high level thoughts of what would have to happen operationally and technically.

I then asked everyone to write their answer to the first question (What need will this satisfy) on post it notes. Then one by one I had everyone read their post it note and stick it on the flip chart paper.

I wanted a chance for everyone to hear everyone else’s interpretation of what need we were trying to address. As you may expect there was a wide range of thoughts with a little bit of overlap.

I used post it notes for this part of the discussion so that everyone could get their initial thoughts out there with out the really load voices in the room dominating.

We discussed those ideas for a little bit and ended up centering around a small number of needs. As a bit of fore shadowing, it didn’t feel like there was concrete agreement on what specific need we were tackling.

Oops.

We then continued on to the next three questions in turn:

• For whom do we satisfy that need?

• What can be gained from satisfying this need?

• How will we measure success?

I’d pose the question, we’d have some discussion, and then we’d try to come to a conclusion. As you may expect, for “For whom do we satisfy that need” it initially started to look like this idea wold be great for everyone. We did eventually narrow it down to a few folks.

Then matters came to a head when we got to the fourth question. As we started talking about how to measure success. People involved in the discussion realized it was difficult to come up with a good measure of success, because they couldn’t define success.

Even the people who came up with the idea realized that they didn’t have clarity on what problem they were trying to solve. What’s more, the problems the group identified when discussing the first question wouldn’t be solved by an express pickup lane.

What ended up happening

The company shelved the idea and did not move forward with the express pickup lane.

My message to the product team was that the discussion was a success. Even though the discussion consumed about 2 hours of 15 people’s time and was sometimes messy and unorganized, we ended up avoiding a lot of wasted time and effort.

That freed the team up to work on other efforts that addressed clear problems.

Even better, everyone understood the decision not to move forward, even the people who came up with the idea in the first place.

Lessons Learned

As I relayed this story, a few things came to mind that I want to remember for the next time I find myself in a similar situation.

This is not a check the box exercise

My biggest mistake facilitating the discussion in the moment was I let the group leave the first question without reaching a firm conclusion about the problem they were trying to solve.

Part of that may have been due to the wording of the question (what need will this actually satisfy). Part of it was my initial inclination to make it through all 10 questions.

If you’re going to use this, or a similar set of questions, you really need to get firm clarity on the first question before moving on.

Remember, you’re having this discussion to get perspectives out in the open and reach clarity, not make sure you have an answer for each question.

10 Questions is probably overkill

The original list of questions for the internal product opportunity assessment is based off the Opportunity Assessment in the first edition of Inspired: How To Create Products Customers Love.

There’s probably a reason that Marty shortened that list down to four questions in the second edition:

• What business objective is this work intended to address?

• How will you know if you’ve succeeded?

• What problem will this solve for our customers?

• What type of customer are we focused on?

Next time I need to use this approach, I’ll probably use a version of these four questions, because they’ll drive the conversation needed to define the problem you’re trying to solve.

This is an activity best done in person

This particular approach to defining the problem is best done by a group of impacted people discussing it with each other in person. Preferably in front of white board with writing utensils and post notes near by if needed.

That doesn’t mean you can’t do it virtually, you can. It just may not be as efficient. And if you do have to do it virtually, make sure everyone is truly remote from each other. Having a group of people in a conference room with a few folks dialed in on a computer is the worst of both worlds.

How do you define the problem you’re trying to solve?

Hopefully this story is helpful to you.

If you’ve ever been in a similar situation, or have observations from reading through my story, I’d love to hear about it.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent