What Seems to Be The Customer Problem?
Finding a customer problem worth solving is key to successful products and businesses. But how do you distinguish a pressing problem from a mere inconvenience? And what’s a customer problem anyway? Let me show you a Customer problem template to help you identify painstaking problems, as well as lead relevant discussions with your customers.
We all have product ideas. We want to solve problems. We strive to make things easier, more convenient. We are wired by nature to think about solutions. And yet, a striving business idea starts with an insightful understanding of a customer problem. But how do we know we’re dealing with a pressing problem, when we hear one? It depends on what you are able to hear.
When I talk to emerging product designers, they hear problems such as these:
- “The product X is missing the feature Y”
- “People need to use the device X to do the activity Y”
- “Insufficient information about resources”
These statements are not customer problems. The first one is an attempt for competition analysis. The second one is wishful thinking for a new feature. The third is a blunt observation of symptoms at most. All of them are rather vague problem statements to draw any relevant conclusions.
There is no one to blame. Our ears are rather tuned to hear solutions or hints of problems at most. We are not tuned to perceive problems. It’s difficult to build a skill when you don’t know what to listen to.
Let me show you my problem-hearing aid that I use whenever customers share their troubles. It’s the set of insights that I’m paying attention to grasp the context of the problem, its magnitude, and urgency. These insights help me prioritize problems, as well as decide what are the issues worth investing in. What are these insights, exactly? Let’s dive in.
Anatomy of a customer problem
Put on rubber gloves, we’re going to dissect the customer problem and study its anatomy. We’ll take a look at an aspirational description of a customer problem. The one that you’ll get when you pay attention to various signals while talking to customers. We’ll read through the example and slice it into insights. We’ll examine why each insight is important and how it helps you grasp and evaluate the problem as a whole.
Example: Project manager prepares a project utilization report
Delivery manager at a bespoke software development company prepares a report of how many man-days have been utilized on a project for a given client. The report serves as an input for a discussion with a Project manager at the client’s end to agree upon how and when the man-days will be invoiced. The delivery manager prepares a custom report in MS Excel.
At the end of the billable period, at the end of each month, the Delivery Manager spends 2 days collecting timesheet data from four development teams to fill out the customized spreadsheet to prepare a report. There are 10 delivery managers within the ACME company.
So far, Delivery managers were considering two solutions:
1. Custom development of a bespoke reporting tool
2. Customization of existing reporting tools
After ballparking costs (1000 man-days) for the bespoke reporting tool, they have decided not to pursue this alternative. One of the delivery managers reviewed existing reporting tools X, Y, Z, with the only X being able to match the complexity of their reports. He tried the solution to build two monthly reports and presented his findings to the rest of the Delivery management team. They decided not to adopt a solution X company-wide, because of reasons A, B, C.
Slicing the customer problem
Our example holds a lot of insights. Let’s transform the story into a customer problem template to surface the insight attributes we should care about:
A [role] is doing an [activity] to reach a [goal]. This is a [current solution] to get the job done.
When [trigger] occurs, at a given [frequency], the problem at given [magnitude] emerges.
So far, a role was [considering alternative solutions]. Eventually, they have [tried alternative solutions] and here are the reasons why they [abandoned alternative solutions].
Do you recognize how the customer problem template matches the insights in our example? Try a little exercise, before we move on. Look for the insights in the original story. And then, compare your findings with a filled in template:
How did it go? Did you find all insights? Congrats! You can take off your rubber gloves now. We have sliced the customer problem. We have identified the insights that are essential to understand and evaluate the customer problem. Now, let’s explore why you should care about each insight and how it helps you to build the whole picture of a problem, of its magnitude and urgency.
[Role]
First and foremost, we need to know who is having a problem! I’m using the term “role” here, but it does not have to be a job title. Here’s a rule-of-thumb to validate well-described role:
“If you (and your team) were to search this role in a crowd, what features would make this role stand out?”
Get inspired by a couple of examples:
- Delivery manager at a bespoke software development company
- Junior person who proofs invoices as their main responsibility in a Global company in Retail vertical
- 30+ first-time mom on maternity leave with 3–6-months-old
There is a reason why I’m giving you examples of roles and why I’m not recommending any particular role description. There is no set of universal attributes to define every role. Focus on attributes that will help you identify prospects effectively. It may be a job title, particular competence, demography or combination of traits.
Your knowledge about your customers and their role will evolve as you’ll progress. You may start your product idea targeting “Marketers” and grow to solve a problem for “Campaign coordinators with a monthly throughput of 10+ ATL campaigns”. A broad description of a role initiates learning about customers. But it quickly becomes obsolete as you’ll learn that only a subset of customers are experiencing similar issues. The role (and every insight) evolves as you’re maturing your business idea.
(Extras: If you’d like a further inspiration on how to think about roles, take a look at Jeff Gothelf’s article about proto-personas. If you’re past the point of early business validation and you’d like to get rigourous about the definition of your users and customers, I’d recommend a chapter about Personas from Kim Goodwin’s Designing for the Digital Age.)
[Activity]
Problems do not exist in a vacuum. They surface while we’re doing an activity and that is the most critical context we need to grasp. Let’s take a look at few cues to help you describe an activity:
Anticipate a verb and an object in the description of an activity. “Insufficient information” is not an activity as it lacks the verb.
Avoid mentioning tools. It should set off alarm bells, when you see an activity described as “a role needs to fill in Excel”. A tool is not the indication of an activity. We may use Spreadsheet software whether we want to “Outline a content production plan” or “Prepare a monthly report”. We may also use more tools to perform one activity. We are interested in what is the activity in question. A tool indicates how the activity is performed (and we’ll cover that later in a [current solution] section).
Aspire for a repetitive activity. It probably does not make sense to look for a solution to an activity that happens just once. Some activities can be both one-off and repetitive, depending on who’s doing them. Web Manager at university, who redesigns a web once in five years, may be involved in a content audit once. Content Strategist, a consultant, will do a couple of content audits a year. Even though the activity may be painful for both roles, there is one side that will benefit way more if someone would have listened to their challenges.
Aim for “Goldilocks” detail of an activity. Let’s think about “managing a project portfolio”. We could take this activity and break it down into smaller activities: “evaluate a project ROI”, “plan a project” and so on. And then we could split those activities further. Eventually, we could end up with indivisible tasks. When you’re at the beginning of your journey to learn about your customers, your goal is to find problems worth pursuing further. At that point, you don’t need to understand every tiny task. You’ll have time for that later. On the other hand, debating high-level activities may not bring you the desired insights. The art is to find activities granular enough to have a productive conversation to learn about your customers. Talking to customers about how they manage a portfolio of projects may be a good start, but eventually, you want to zoom in. For example, you want to have a conversation about how customers evaluate a project or prioritize projects. How far should you zoom in? Until you find a concrete problem worth solving. I’d gladly give you an example that signing a contract may be too small activity to bother, but teams at DocuSign would disagree.
[Goal]
A goal gives an activity a meaning. And it gives you a context why people do what they do. What do they want to achieve? What’s the desired outcome of their activity? Sometimes, it pays off to go down the rabbit hole to learn about the ultimate goal. For example, we can jog to lose weight (1st instance goal), to live a more healthy lifestyle (2nd instance goal), to live long enough to enjoy the moments with grandchildren (the ultimate goal).
When you know the goal behind the activity itself, you have a higher level of understanding of what’s going on. Goal a vital ammunition to design a one-step-better solution.
Let’s say we have observed “a developer who maintains internal tools at ACME company, full-time”. If we were to seek a solution to save developer’s time we would look into how to make activity itself more efficient. But what if we also knew the goal? Let’s say we knew: “A developer maintains internal tools at ACME company to enable/automate its business processes”. Recognizing the goal, we can start looking for solutions beyond the activity itself.
[Current solution]
Let the customers walk you through how they’re doing the activity today. Try to understand the good bits, the bad bits, the ugly bits. This is the moment when you start digging into finding a problem. Discuss the tasks that make up the activity. Review the tools being used. Pay attention to pains that cause the activity to take longer, cost more, or make it annoying. Double-check if your findings contain a [current solution], a [trigger] and a [frequency] when a problem of certain [magnitude] emerges.
Keep the [current solution] brief and without a description of pain. It’s ok to list tools in here. Use the [current solution] insight as a cue in other interviews, or for further segmentation. Let’s bring in the solution from our example: “Delivery manager prepares a custom report in MS Excel.” Now, when you hear other Delivery managers talking about custom spreadsheet reports, it’s a signal to dive into the topic. Or, perhaps, after a couple of interviews, you’ll see a pattern. Delivery managers, who use spreadsheets for reporting, experience similar troubles. This can help you narrow the segment.
[Trigger]
What’s the cause when the activity starts being painful? What triggers the pain?
An activity does not need to be painful every time. Also, various triggers may lead to painful activity. That’s why we’re looking for moments that trigger the painful progress of an activity. We’re not seeking a trigger for activity itself. Even though sometimes it could be the same thing. Confusing? Let’s take a look at a few examples:
“At the end of the billable period, a Delivery Manager spends 2 days preparing a report.” “Billable period” triggers the activity (prepare a report) and activity is painful each time. In this case, the trigger of a problem is also the trigger of an activity.
Now, let’s take a look at another example: “Developer maintains internal tools (e.g. home-grown CRM) at ACME company.” On any given day, the maintenance workload is Reddit & Chill. But this changes when C-level executives request a business process adjustment, which takes at least one extra day on top of other responsibilities. In this case — a change request — is the trigger, which makes the activity worse.
A trigger can twist a solution — you can focus to eliminate the trigger that causes the pain. Also, a trigger can lead you towards an estimate of how often the problem happens.
[Frequency]
It may not be feasible to solve one-off problems. That’s why we’re looking for recurring problems. They may appear once a month, twice a week, or every single hour. Capture how often the problem is triggered in a format that you can compare across the interviews.
[Magnitude]
How big is the problem? Observe the problem both in terms of quality and quantity.
“Quality” builds empathy towards a problem. Customers are fantastic at painting a vivid picture of their problems. A delivery manager from our example went into an immense detail of how she always has to remind her teams to fill in the timesheet and how she is copy-pasting the numbers from a timesheet to a spreadsheet, triple-checking each number to get along with this error-prone process. These details are gems that will help you tailor the marketing messaging later on. They would also help you identify the painful moments. But don’t fall for the apocalyptic scenes right away. Dig deeper whether the customer is talking about a one-minute problem or a two-day problem.
“Quantity” helps you estimate the size of a problem. How long does it take to do the problematic activity? How much does it cost? How many people does it affect? Aim for numbers that would help you estimate savings in case you would solve the problem. Quantifying a problem will show you whether you’re in the business of improving a mere inconvenience, or whether you’re about to solve the problem that’s bleeding money.
Let’s take a look at the problem magnitude of our example. The delivery manager is spending 2 days preparing a monthly report and there are 10 delivery managers at the ACME company. At an hourly rate of $40, reporting troubles cost the company $40 × 10 × 16 = $6400/month. Now, is it a big enough problem to care? $6400/mo sounds like a lot of money going to waste. This number may suggest pursuing a business idea further.
Before we’re going to build a solution, let’s remind ourselves that “value lies in the eye of the beholder”. Even though the problem may seem big enough to care about, first and foremost, we have to ask customers how they cared about solving the problem before we showed up. People are resistant to change. Large problems remain unsolved if they are smaller than the effort required to resolve them.
[Consider → Try → Abandon alternative solutions]
No matter how customers portrayed a problem; or how much it costs the company. It probably isn’t much of a problem, if they haven’t tried to solve it yet.
Ask customers whether they were looking for alternative solutions to their problem. If you get a “no”, you are dealing with a nagging rather than a problem worth solving. On the other hand, when customers start to name all the things they tried, you may be onto something!
Note down the recognized alternatives and review each from a “Consider → Try → Abandon” funnel perspective:
- What were the reasons to consider an alternative solution?
- What were the reasons/blockers to try an alternative solution?
- What the trial process looked like?
- What were the reasons to abandon an alternative solution?
Discussion about alternative solutions will give you the last piece of the problem mosaic. You’ll understand the motivation to resolve the problem, as well as, what are the difficulties to adopt the solution. Let’s observe hurdles in our “Delivery manager” example:
…Delivery managers were considering two solutions:
1. Custom development of a bespoke reporting tool
2. Customization of existing reporting toolsAfter ballparking costs (1000 man-days) for the bespoke reporting tool, they have decided not to pursue this alternative. One of the delivery managers reviewed existing reporting tools X, Y, Z, with the only X being able to match the complexity of their reports. He tried the solution to build two monthly reports and presented his findings to the rest of the Delivery management team. They decided not to adopt a solution X company-wide, because of reasons A, B, C.
We observe that Delivery managers considered two solutions, tried one and adopted none. They have already invested a couple of hours into ballparking the solution and one team member invested his time and reputation to shortlist and evaluate one of the solutions. There is a substantial motivation to solve the problem. However, the company-wide adoption failed due to reasons A, B, C which could serve you as further inputs to shape your business idea.
Summary
When I’m talking to customers, I’m leading a discussion to fill in an imaginary template to understand the context, magnitude and the urgency of the problem:
Context
A [role] is doing an [activity] to reach a [goal]. This is a [current solution] to get the job done.
Magnitude
When [trigger] occurs, at a given [frequency], the problem at given [magnitude] emerges.
Urgency
So far, a role was [considering alternative solutions]. Eventually, they have [tried alternative solutions] and here are the reasons why they [abandoned alternative solutions].
Recognizing these aspects helps me evaluate whether the problem is worth solving, prioritize the problems and design more insightful solutions.
Resources
I’ve made a couple of freebies for you. Here’s the template to capture the customer problems. I’ve also compiled more examples of customer problems that follow this structure. If you’d like any hands-on help in understanding your customer, feel free to reach out to me at Linkedin.
Thanks & Inspiration
Even though I haven’t linked the sources throughout the article, the template is based on the work and experience of many. It would be close to impossible to properly attribute all the bits throughout the article. Here’s the gist of inspiration that helped me shape the technique:
- I like the user story template or value proposition template, that’s where I got an inspiration for a customer problem template.
- Principles of goal-directed design and Jobs-to-be-done in all their flavors helped me grasp the angles of what people do and why.
- Ash Maurya’s Running lean and consequent blog helped me spot and distinguish urgent problems from inconveniences.
I’d also like to thank Tomáš Hrubý, Filip Zajac, Tereza Kulichová and Jakub Šlancar for a review and feedback.
💡 Have you found the article insightful? Buy me a coffee to fuel more posts on the topic. Thanks!
