Problem definition

Last week I spoke with a gentleman who’s looking for someone to build a new CRM for his team.

It was a great example of how surprisingly difficult it can be for folks like you and me to define the problem we aim to solve.

On our first call, I asked him to name the business goals he was trying to achieve and not just the features he was looking for.

So he put thought into that, and we met a second time.

He had a lot of ideas on what the solution should look like: Lists of workflows to improve; flowcharts of processes to support.

But he had not named any actual business outcomes: Headaches he was trying to solve; opportunities he wanted to capture.

We talked for a while, and I pointed out that under “Goals” he had listed a few outcomes, but they were all phrased in terms of a solution, not in terms of a problem.

There was a wonderful pause in the conversation.

And after a few moments of silence he said, and I quote ...

"Oh. Right. I'm not the solutions expert here. I'm the problems expert. Dang it!"

Jackpot! Now we could get down to discussing his real problem. Only after that can we discuss solutions that truly matter.

Here's the thing:

Defining the problem is surprisingly hard.

It's definitely not as fun as dreaming up a solution.

But it's a critical first step, if you want to build a solution that solves problems that actually matter to you.

You can be the solutions expert later, or find someone else to fill that role.

But first you must be the problems expert.

All the best,
A.