The One Construct You Need to Describe Customer Needs
If your goal is to design winning solutions that meet customers’ needs, you have to know what those needs are, and how to articulate them in a way that’s understood across your organization.
But uncovering needs (learning) is one thing, and solving for them (building) is another. We see that time and again in fancy charts:
Unfortunately, we don’t separate uncovering needs from designing solutions
Too often, we task designers with both uncovering needs and designing solutions for them.
This is a shame, because there are very different skillsets, outputs, and corresponding incentives that should be associated with these two activities. Mike Boysen has shared a very robust breakdown of roles he sees as taking place in the process of innovation:
So why does this happen?
Because we see that chain of “informs” in Mike’s diagram and get scared of what will fall through the cracks or be lost.
Many (most?) organizations lack a shared language to describe a customer need. It doesn’t have to be this way.
We know how to articulate functional technical requirements. We know the language of browser specs and load times across the organization. But when we talk about our customer needs, we stumble and stutter and hope others interpret things the way we mean them (meaning, our interpretation of what the customer meant).
No wonder we get confused!
The Customer Needs Statement to the Rescue!
People hire products and services to get Jobs done. By focusing on what they’re trying to get done — absent from a discussion of their current solution — we can uncover their needs. Needs are a higher-level order than feature enhancements. It’s not “I have four video feeds and I really need eight so I can talk to my team”. That’s a feature request tied to a specific product.
I won’t get into the tactics of how to uncover customer needs in this post. This post is about how to structure your needs statements. Framing your customer needs in this way can cascade through your organization and change how you do business.
Are you ready for it?
That’s it.
Minimize + {the time OR the likelihood} + object of control + [optional contextual clarifier].
Capture and document your customer needs like this, and you’re well on your way to more productive discussions and decision-making.
At first glance, this format may seem limiting. Surely there’s more to innovation than minimizing things?
But after attending the Strategyn JTBD+ODI Masterclass in Atlanta on March 15th, I finally got it.
There are a number of reasons this format is ideal for structuring statements that arise through customer interviews.
1-Practicality
To reduce, to minimize, to lower, to eliminate… when we use different phrases, we run the risk of introducing some subtle nuance, or unintended intent. We humans love to try to see patterns, so if we use “minimize” in some cases and “reduce” in others, our brains will try to dig through to understand if there’s nuance behind the variance.
Remember helping people do Jobs better is reducing the variability of the results. By limiting the input, we are reducing the number of variables that could influence the results.
2-Precision
One of the attendees at the Masterclass suggested that an outcome could be “maximize comfort”, which feels different than “minimize discomfort”.
But reflect on that a moment. They DO feel different: we’d rarely say “minimize discomfort” because it’s just too vague.
We’d dig in to the specifics: “minimize the likelihood of temperature fluctuations” “minimize the risk of jagged edges”… these descriptions are more tied to the circumstances than the vague and squishy “maximize comfort” and give our designers specific things to focus on.
As an aside — I found it really interesting that we’re ok with being vague when we use the direction “maximize” — as though we are comfortable with being open to as-yet-unstated possibilities. When we switch our brain to what we should minimize, we demand something more actionable.
3-Scope
“Minimize” has a clear ideal state. When we aim to minimize cost, we go to zero. When we aim to minimize time, we go to zero. We can measure current state, and know how far we have to go to reach the ideal.
How can we ever know how close we are to attaining a maximal value? At that point we’re chasing a variable that could change over time.
Jeff Bezos is known for his quotes about not focusing too much on the competition, and that’s fitting here. The goal isn’t to be marginally better than competition: it’s to get customers closer to their ideal state. If you always keep that firmly in mind, rather than getting distracted in feature wars with others, you’ll stay in front.
As an aside, while finding the quote above I came across this one, which also seems appropriate:
It can be tempting to add to our products and make them more robust. But adding more comes at a cost, and unless it’s truly valuable to the customer, it’s not helping your bottom line.
That’s why this focus on what to minimize is so compelling. Rather than guessing at what is valuable and building it.. and then iterating on it.. and building some more… we focus on clearing the path for our customers to help them along their way.
Statements, not Opinions
Lastly, structuring customer needs in this way removes the tyranny of opinion. We can believe we know what customers want based on how we see them behave. We can guess at their motivations, and try to articulate them as best we can.
Or we can interview them to understand what they’re trying to get done. We can dig into where things are time-consuming, frustrating, or may lead to error.
We can capture those statements in clear language that can be shared up and down the org chart, and share a common understanding of what’s important to the customers you aim to serve.
Focusing on your customer needs, rather than your product’s current features, serves as a foundation for innovation. Would this work in your organization? Can you imagine how conversations would change with everyone speaking the same language?
I hope this helped you understand the benefits in structuring customer needs in this way. With due respect to Blaise Pascal, if I’d had more time, I’d have written a shorter Medium post. [minimize, minimize, minimize!]
Learned something? Click the 👏 to say “thanks!” and help others find this article.
Andrea Hill is the principal consultant at Frameplay. Frameplay is an innovation consultancy that helps companies become more customer-focused and thrive in a rapidly changing world. Learn more at frameplay.co
