The One Construct You Need to Describe Customer Needs

Andrea F Hill
Mar 26, 2018 · 6 min read

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:

Except.. we build BEFORE we learn? 🧐

Unfortunately, we don’t separate uncovering needs from designing solutions

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!

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.


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.


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.


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.

if we can keep our competitors focused on us while we stay focused on the customer.. (Bezos)

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:

Minimize, minimize, minimize!

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

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.


Commentary on innovation, customer value and design…


Commentary on innovation, customer value and design thinking. For more information on our consultancy, visit

Andrea F Hill

Written by

Sr UX Specialist with Canada Revenue Agency, former web dev and product person. 🔎 Lifelong learner. Unapologetic introvert. Plant-powered marathoner. Cat mom.


Commentary on innovation, customer value and design thinking. For more information on our consultancy, visit