A lot has been written about “user versus customer” as an abstract concept ever since (and probably long before) Jack Dorsey asked Twitter to stop calling its users users and start calling them customers. I’ve also seen product managers and UX designers write about how “product owns the customer; UX owns the user.” I think most of this discussion is useful and relevant in defining roles and responsibilities in a product organization, and I’ve referred to various aspects of it many times in my own work with other product managers, UX designers, and developers.
That said, while I don’t spend a lot of time on product management blogs, I haven’t seen a good, concise explanation of how to think about user problems versus customer problems when defining product requirements for design and engineering. I’m writing this post mostly to remind myself to think a little differently in the new year.
I often find myself sitting down to write up a PRD and starting from what I call the “customer problem.” But is it really the customer problem? For example:
- The customer needs to better understand retention and churn in their own customer base.
- The customer needs a better way to visualize the overlap between marketing segments.
- The customer needs to be able to upload massive amounts of customer data for analysis in our tool.
No. No. NO. These statements do represent problems, and they are probably even worth documenting and elucidating as we present our ideas and try to win advocates and acolytes to our cause, but they are not customer problems. They are user problems. They describe what a user needs to be able to do once they are already in the product.
Okay, then; what is a customer problem?
A customer problem—which should be at the beginning or near the beginning of every PRD and concept deck we create—should describe how the customer (a business) is failing to grow. Both customer problems and user problems describe inefficiencies, but customer problems come with a clear indication of the actual (monetary) value that a solution would provide to the businesses we serve, while user problems may only hint at that value.
As such, customer problems are more likely to describe something that would keep the CEO or CMO or CIO up at night than they are to describe something that keeps the day to day user of the product up at night. That’s a good thing, because it can’t hurt to start speaking the C-suite’s language.
Here are a handful of examples of what I mean:
- The customer has reached a point of diminishing returns from their acquisition budget but still needs to hit a top-line growth target of 20% YoY. The most efficient way for them to do this is by personalizing the on-site experience.
- The customer is facing intense downward pricing pressure from a smaller competitor who is trying to steal market share, and they are looking for new ways to engage with their own customers to keep them from attriting.
- The customer knows that segmentation is everything in marketing, but beyond their legacy market segments they have been going after for years, they do not know how to find the right groupings of individuals so that they can reach them in the right way at the right time.
- The customer has been unable to consolidate customer data stores across the enterprise and, as such, has not been able to empower various marketing teams with insights at the brand level.
- The customer has millions of dollars flowing into marketing campaigns across various channels, but has only a very limited view of how those dollars influence not just short-term revenue, but long-term customer value.
As I’m sure you can see, user problems can/should flow from customer problems. But we could solve any of the user problems a few paragraphs up from here without actually ensuring that we’re solving the real underlying customer problem that will help users of your product grow their business.
As I’m sure you can also see, the customer problems I’ve listed here are composites, more indicative of a market problem than anything any one particular customer is facing uniquely. (Unless you’re building a product for an individual customer, you will want to pick a someone from across your customer base to represent the customer problem, but it should reflect broader trends, obviously.)
All of this might seem obvious, in which case maybe you haven’t made it to this point in the post. In a way, it is obvious; we all probably try to focus on customer problems, but we often settle for user problems even though we know better. Why is that? As a colleague pointed out, it’s probably because we spend a lot of timing documenting problems, use cases, and solutions for developers, who do solve user problems with their work; thus, we naturally tend to put things in terms that developers are most likely to understand and relate to; however, those user problems should still be grounded in customer problems. This will enable engineering teams to understand the deeper problems as well, giving them the best chance to innovate in ways you could never have envisioned.
What if I don’t know what the customer problem is?
As a product manager you are probably fairly close to your users. Your users sit within the organizations that pay for your product, and many of them likely understand the factors that are limiting growth of the business. If you ask them what challenges the business as a whole is facing, they may or may not get right to the heart of the matter, but this is why (no pun intended) I love the “Five Whys” method of interviewing.
The theory is that within (roughly) five iterations of asking a person “why?” you can get to the root cause behind the initial problem described. You ask what problems are facing the business, and they give answer. You ask why that’s a problem. They answer. You ask why that’s a problem. They answer. Lather, rinse, repeat. By the fifth “why,” you should be at a root problem that motivates the users you’re interviewing to action in a big way. That should either be the customer problem or very close to it.
You may need to ask to interview the user’s manager, or his/her manager’s manager in order to get the level of detail you want in order to truly understand the customer problem, but the “Five Whys” method will help you get there.
A final huge benefit to thinking about customer problems
One of the most underrated skills in product management, in my limited experience, is the ability to convince people. You have a vision for your area of product ownership, and you’re likely competing for resources (development, UX, etc.) with other products or other features. You will get nowhere with that vision unless you are able to convince key stakeholders that what you want to do is supremely valuable to your customers (and therefore to your own business).
There are many factors that play into the “convincingness” of a product proposal, but in my (again, limited) experience, proposals that are based in a rock-solid knowledge of the problems your customers at large are facing, where the product manager can speak knowledgeably and authoritatively about the business problems preventing customers from growing, tend to convince more people more completely. These projects tend to get funded because stakeholders feel the customer’s frustration much more acutely than if the problem presented is purely a user-level problem.
One of my goals for 2016 and beyond is to do a better job in interviews with users getting to the root of the customer problem and being deliberate about making that the central focus of my product requirement/design work. (Incidentally, I think I’ve been reasonably successful at this, but more by chance than by choice.) I have no doubt that it will produce better products and features; I just wish I had come to these realizations much sooner.
Ah, well; I never said I was a fast learner.