Do you prefer talking about problems or solutions? Most people like to solve problems, and today I want to talk about the “Problem Space,” and why it’s an important framework to hold on to when meeting with clients.
Marinating in the Problem Space
I’m lucky enough to get to walk to my office in the mornings, and I often listen to podcasts while I walk by the river. I’ve been digging Genesis expert Carrie Dils’ OfficeHours FM podcast recently, and last week I listened to an episode in which Carrie had Chris Lema on the show, and he talked about the importance of “marinating in the problem space.” That really resonated with me, when thinking about how to work most effectively with clients, and I want to share some thoughts on that here.
In the episode, Carrie was picking Chris’ brains about how to work effectively with clients, and Chris highlighted how important it is to fully understand the problem a client is facing before you start thinking about potential solutions.
This is where the idea of the “problem space” comes in.
Picture that first meeting between a designer/consultant/agency and a client: you start out talking about what the client wants. As a consultant, I try to turn the conversation toward the problems that the client hopes will be solved by working on the project together, because, as Chris Lema put it:
“the more you know about someone’s problem, the better your answer will eventually be”
However, as soon as we start talking about problems, the temptation is to jump immediately to possible solutions. It’s a temptation that’s hard to resist. After all, I want to demonstrate that I’m a “problem solver,” and everyone feels better when they know a solution is in sight.
But it’s important to stay in that problem space for a while, and really try to get to the bottom of why problem X is such a sticky problem, and why the client hasn’t managed to solve it so far. To quote Chris again:
“the more you listen, the more you get at what the core of real problems are; what some of the hidden problems are.”
For example, say the client runs professional development trainings, and they’re not getting enough registrations to cover the cost of each event. As soon as I hear “event registrations” my nerdy, WordPress-developer mind is tempted to jump straight to thinking about what plugins might work for handling registration, maybe a customized Gravity Forms set-up, or an all-in-one solution like Event Espresso. But I have to stop myself, because already, I’m starting to think about solutions I might implement, and chances are I don’t fully understand the problem yet. We need to explore the problem space some more and ask questions like:
- Do people know about the event, but aren’t registering?
- Is there a problem with the current registration process?
- Is the training priced correctly?
- Are visitors arriving at the website on a mobile device, but the event registration is not optimized for mobile?
- Is it actually a marketing problem; that people just don’t know the training is available?
These are all important questions to explore before starting to think about where to focus our effort (and spend the client’s money) on potential solutions. And this type of exploratory discussion takes time. That’s why Chris Lema talks about being willing to “marinate in the problem space.” He uses the analogy of marinating a steak to drive home the point that some things can’t (or shouldn’t) be rushed. You shouldn’t marinate a steak in ten minutes before throwing it on the grill, and you shouldn’t start a web design project without first taking the time to understand the client’s pain points.
Who does this benefit?
At this point, it’s worth noting that when Chris Lema talked about this problem in the podcast, he was focused on improving the process for the consultant/designer (i.e. for me). He makes the good point that you can’t accurately quote or build out a proposal for a project if you don’t fully understand the scope of the problem.
But this is crucial for the client as well: if you’re working with a consultant, an agency, or a contractor that doesn’t take the time to understand your business and the problems you’re facing, then you’re not getting a good deal. The chances are you’ll come out of the process with a product that might look great, but doesn’t solve that underlying issue, because you didn’t take the time at the beginning to explore the problem space.
How to leave the problem space
When you’re sure you’ve listened enough and gained a solid understanding of the client’s business, you can leave the problem space and start thinking about how to approach the project. But before you start thinking about solutions, ask yourself this:
How will we know if we’ve solved the problem?
Think about metrics. What data can you monitor after tracking during testing or after launch to make sure that underlying problem has been addressed? Write down the problem, and the tests you’ll use to see if it has been fixed.
During development, stay close to the problem space
Even though you’ve now left the problem space, I still suggest staying nearby. During development of a new website, or A/B testing of an email campaign, keep that problem statement and set of metrics nearby so you can stay focused on the client’s core issue, and make sure you’re delivering the best value you can.
Featured image courtesy of JohnONolan