Do You Have a ‘Problem Queue’?

Do you know why you’re developing a feature? Do you know who you’re developing it for?

Before any feature makes its way onto our roadmap it must have started its life as a problem. It could be a problem faced by a specific customer or even ourselves. What it can never be is a solution.

If you do your problem discovery as early as possible you’ll be ready to build the right product or feature.

Customers come bearing solutions

Most people think in terms of solutions which are almost always either vague or too specific. This makes the design and development phases difficult. It extends the time required to understand what it is that needs to be built.

Recently, a customer invited us up to their headquarters in Vancouver to discuss some custom development work they wanted done. Their branch managers from around the country were going to be in town so they felt like it would be a good chance to get everyone in the room at the same time.

The meeting started as a round-table discussion of all the features they wanted us to build into our learning management system (LMS). One after the other managers when through their wish list. (Most of their requests overlapped in some way but I was surprised at the number of unique requests each had.)

The problem was that from our perspective we had no idea why they wanted the features let alone what the features actually were.

E.g.

• Trainee groupings and training buckets.
• Email notifications.
• Personnel system connection.
• A unique ‘case ID’ for every training assignment.

What the hell do any of these mean? We had way more questions that they would have answers for, had we decided to engage in the conversation on their terms. I.e. we were not going to focus on the solutions they presented. We needed to get to the root of what led them to the solutions.

Get people thinking in terms of problems

We could have dug into each item encouraging them to explain each request. We could have even started mapping out ideas or drawing out some designs. But the problem was that they were starting from the end. They understood the issues they were having that led to their solutions. We did not and so that’s what we needed to tease out of them.

Rather than fleshing out their requests we went through each one and got to the root of problem they felt it solved. We did this by going through each one and asking situational and probing questions around why and how they came up with each solutions.

E.g.

• What were you trying to do? Why? What did you do instead?
• What kind of information is useful to you? Why? What do you need to do with that information?
• How do you conduct your training sessions? Why do you conduct them that way?

We were practically starting from fresh as if we knew little about their business. We had a sense of how they did things but getting the details in their own words helped us understand and frame thing in our minds based on their view of the world.

Taking this approach allowed us to come up with solutions that were WAY better and WELL beyond theirs. It’s because we had defined the problem with precision and clarity.

Takeaways

Understanding customer problems helps you understand why you’re building something. You and your team can’t argue over it’s merits because its real data back by real customers. You’ll be on the same page, you’ll have a shared goal. To solve a real problem.

Do what ever it takes to understand customers’ problems. Go meet them in person. Watch them interact with your application. Ask them TONS of questions. Ask them to explain why they do things the way they do them.

---

Icons made by Freepik from www.flaticon.com is licensed by CC 3.0 BY