Are you a Problem Solver, or Solution Creator?
I’ve been thinking a lot lately about how some people think they are problem solvers, but in reality they are solution creators.
It’s kind of subtle at first glance. They’re the same thing, right? right? In my experience, they’re definitely not.
There’s a world of difference between being a problem solver and being a solution creator. And one of those tends to lead to spinning wheels, wasted money, and a lot of frustration – especially in client work.
Not long ago, a client for my WordPress development agency came to me asking for “WooCommerce optimizations.” That was the phrase they used. They wanted help improving site performance, cleaning things up a bit, maybe making WooCommerce run faster or more efficiently. Totally reasonable request, and I think most people would’ve heard that and gone, “Great, let’s start optimizing WooCommerce.”
But that’s not how I approach things anymore. I’ve learned (honestly, the hard way) that most requests like that are surface-level. They’re symptoms. And if you dive in without slowing down to understand what’s underneath, you often end up doing a lot of work that doesn’t actually help. Or worse—you make the real problem even messier.
So instead of getting straight to work, I asked questions. I looked around. I poked at the edges of what they were saying to see what was really going on.
And what I found was…honestly kind of wild.
They had five separate vendors all touching the same site. One for design, one for development, one for support, one for marketing stuff, and another I couldn’t quite figure out. One key vendor was building custom plugins that were brittle, messy, and hard to maintain. Like, really hard to maintain. Every time something needed to be changed, it was a coin flip whether it would break something else. The whole thing felt like a fragile tower of duct tape and hope.
And, of course, that vendor would charge the client every time it would break, which became very costly, sometimes putting their site out of commission for several hours just from doing something as simple as updating plugins on their website.
So we got on a call with that vendor and started asking questions. Basic stuff about the system they built, just trying to understand the parts. How does the system authenticate, where are the bulk of your customizations, what causes these issues when updating, etc.
Their responses were…concerning. There was always a long pause between each question. The responses were always vague. The kept referring to “the original developer”, and at one point, when asked about a critical security concern, they said, “We’re not doing anything about that.”
That meeting cost the client $3,000.
And the vendor ended it by saying, “Great meeting, everyone!”
I just kind of sat there blinking at my screen. It was not a great meeting.
If I had just taken the original request at face value and started tweaking WooCommerce settings, I might’ve looked productive for a few weeks. I might’ve billed some hours, made some changes, and sent over a few reports. But it wouldn’t have solved anything. In fact, it probably would’ve made things worse, because we would’ve been building “solutions” on a completely unstable foundation. Solving problems that doesn’t actually solve their real problem.
Instead, we pulled back, and had some candid conversations with the client about what we saw. We took the time to explain their problems, and talked through a plan of action on how we could help them actually fix these problems.
The list of problems we suggested to fix had nothing to do with WooCommerce, but by proxy, they did help them make their website work much more reliably, and faster.
It’s just wild how easy it is to fall into “solution mode.” There’s a kind of rush that comes from doing something – especially when someone is paying you to do it. But more and more, I’m learning to slow down. To question the request. To sit with the problem a little longer than feels comfortable.
Because rushing to solve the wrong thing is a great way to waste everyone’s time.
So now, when someone asks for help, I try to make “problem solver” my default state. Not because it’s more noble or something. Just because it works better. I want to build things that last. I want to help people make real progress. And that means I can’t just react – I have to think.
I like to think that people hire me not because I can create solutions, but because I can solve problems. I can consult with the customer, look deep, and understand their real problem. From that, I can help them create a path to actually serving them in a meaningful way.
I’ve realized that, well, it’s freaking hard to correctly articulate a problem sometimes, and there’s a lot of value in spending the time to help a customer understand what they’re asking for in the first place. Sometimes that in itself is out of their reach.
It’s not always glamorous. It doesn’t always look impressive right away. But it gets better results. And it keeps me from spending weeks fixing things that didn’t need fixing in the first place.
There’s a few lessons in this story, I think:
- If you’re asking someone for help, don’t prescribe a solution (like saying “I need WooCommerce optimizations”) instead, try to articulate the problem (“My website is unreliable”). This prompts your experts to think.
- Pay attention to when someone prescribes a solution without any context to you, and seek out the context. Think about, and understand the problem deeply.
For example, my nephew messaged me a few days ago, asking for a saw. Now, my nephew has many great qualities, but he isn’t exactly known as a handyman.
Looking at the line of questioning, I opted to ask him for context. “Why do you need a saw?”
To which he explains that he has a couch that is completely water damaged in his basement from a recent flood, and he has no way to get it out without taking it apart.
I do have a saw, but I can tell you with confidence that my circular saw (or really, any saw for that matter) would probably just make a gigantic mess and not really help.
As it turns out, this isn’t my first water logged couch (long story), so I happened to know exactly how to break it apart. Crowbars, hammers, and a utility knife. Those were the right tools for this job.
Now, had I just blindly said “oh yeah I have a saw, sure here you go”, it would have without any doubt made the problem worse. Sawdust would get everywhere, we’d probably hit a nail and damage the blade, it might get caught in the fabric and do something unpredictable. Someone would probably get hurt, and the cutting probably wouldn’t even help break the couch down.
But by asking a follow-up question, I was able to save my nephew (and let’s be honest, myself) a lot of pain.
My customer asked for “WooCommerce optimizations” but what they needed was someone to take ownership of their site, and make it work reliably. That’s a much deeper need that took some effort to work out.
My nephew asked for a saw, but what he needed was assistance getting a couch out of a basement.
Ask questions. Think about the problem. Understand it fully. Even when you think you understand it, ask more questions. You may uncover a deeper problem still. Keep going until you’re confident you have everything you need. More context only makes you more capable of solving a problem.