I’ve been reflecting a lot lately on the difference between needs and wants, and how those relate to problems and solutions. Earlier this year, as I prepared a lightning talk about AI use cases outside of work, I framed everything around a straightforward structure: What was the problem? And what was the solution? It worked well enough for the talk. It helped me articulate the challenge and walk through how I approached it.
But after the talk, something kept nagging at me. I don’t go around looking for problems to solve—at least not intentionally. So I stepped back and asked a deeper question:
When is a problem actually a problem?
It turns out that question takes you someplace interesting.
Listening Before Solving
Over the years, as a consultant, I’ve sat with people who describe what they perceive as problems. And sometimes, after listening, observing their workflow, and looking at the numbers they’re working with, I realize they don’t actually have a problem. What they have is a need they don’t fully understand, and in the absence of that clarity, anything standing in the way starts to feel like a problem.
People often think they have a data problem when what they really have is a misinterpretation problem. They believe they have a workflow problem when, in fact, they have a perspective problem. They think something is broken when it’s actually just misaligned with what they need.
And the same is true for me.
So I’ve been asking myself more often:
- Is this really a problem?
- Why does it feel like a problem?
- Is it actually blocking a need I have?
- Do I truly need this thing I think I need?
When the answer is no, there’s nothing to do. When the answer is yes, then I can finally ask: What’s in the way? And what can I do about it?
That’s where the problem-solution pairing becomes relevant. But only after the need is clear.
Revisiting My Own AI Use Cases
When I revisited the non-work AI use cases from my lightning talk, I approached them differently. Instead of starting with, “Here’s the problem I solved”, I asked:
“What was the need?”
That shift completely changed how I looked at those examples. It made the examples more transparent, more grounded, and more honest. It also made me more aware of how many things I label as problems simply because I haven’t yet named the underlying need.
This led me to something that’s been shaping a lot of my thinking lately:
The Need → Problem → Solution Playbook
Put the need first, always.
Because wants are tricky. They sit between the need and the solution. In user stories, this shows up as the “I want to…” part. I’ve never loved that part, because wants can be misleading. The real value is in the “In order to…” part—that’s where the need lives.
By flipping the order, I create more space:
- The same need can lead to different wants.
- Different people with the same need can want different things.
- I’m less constrained by the first idea that pops into my head.
That’s where creativity comes from. That’s where real problem-solving starts.
Closing
I started writing this as a journal entry for myself, but I realized it fits perfectly as a blog post. It captures where I am right now in this ongoing reflection around needs, problems, and solutions.
Need → Problem → Solution → Next Need.
A spiral that keeps moving upward.
And speaking of spirals…
I’m releasing an early edition (about 80% complete) of my upcoming book, The Need–Problem–Solution Playbook: How AI became part of my workflow—one real example at a time. It’s available at a 30% discount through the end of the year, and everyone who buys now will automatically receive the full version for free once it’s published.
If this way of thinking resonates with you, I hope the book helps you explore your own spirals.
Leave a Reply