You’re Not Just Solving User Problems

I regularly ask product people how they choose what to develop. Today, an increasingly popular answer is “we focus on the most important user problems”, or its more modern cousin “we prioritize opportunities”. Underlying these answers is a classic model that asserts that product development has to start with mapping out and prioritizing customer problems, later dubbed Opportunities, (I prefer the terms Needs of Jobs), before moving on to develop and test “solutions” (what I like to call Ideas). Each idea has to be directly linked to a user need. This approach is reflected in popular models such as the Double Diamond (explained below) and Teresa Torres’ Opportunity Solution Trees (OST). 

I really like how customer-centric this “user-needs-first” approach is and I believe it can bring a lot of benefit to product organizations; definitely an improvement over decision-by-committee or decision-by-HiPPO. What worries me, though, is that an increasing number of people naively think that this is the only way to develop products — the one true form of product discovery — and that anything that diverges from this sequential model is necessarily flawed.

This is a major problem because starting with user needs is just one of many ways to develop good products, and if you just practice it and nothing else you will severely limit your ability to create value, and likely also antagonize your colleagues, managers, and customers. In this article I’ll talk of some of the not-often-discussed limitations of the “user-needs-first” model, and why you should keep prioritizing ideas rather than needs.

Addressing Users’ Needs Is Just Part Of What We Do

Behind the “solving user problems” mindset there’s often a naive assumption: user needs are at the root of everything, and all that we do is solve user problems. This may be a good mindset if you’re working on client projects in a design agency, but it simply isn’t true for product companies. The company has plenty of needs of its own: generating revenue, growing market share, lowering costs, fending off competitors, meeting legal and privacy regulations, maintaining and scaling the software, and much more. The product organization is expected to contribute to all of these. We’re in the business of delivering value both to the market (users, customers, partners) and to ourselves. 

It’s definitely a problem if the needs of the company consistently outweigh the needs of the users — the company becomes overly self-centered and revenue-driven. It’s also bad if we try to address company needs, say by raising prices, without first testing with users and considering their experience. Users and customers have to be our focal point, but that’s not to say that everything we do is for them. 

You can try to save the “it’s all about the users” dogma by trying to map every business goal, no matter how selfish, to users’ needs. Sometimes this works, but often it’s just unnecessary mental gymnastics and process overhead. For example, if the company has to improve user retention, some solutions will come from adding more value to the product, while others from effectively resurrecting dormant user. Both are valid, but only one is really addressing user needs. 

Problems-Before-Solutions Is Overly Constraining

The “problem space before solution space” philosophy has been around for a long time. A popular example is the Double-Diamond Model, popularized by the British Council of Design in 2005, that breaks the process of design into four sequential phases that lead from user needs (left diamond) to solutions (right diamond). In the past decade, the tech product community embraced the Double Diamond and today it is presented as a best-practice in many articles, books, and workshop.

However, over the years many designers have criticized the Double-Diamond for being overly simplistic and restrictive. With today’s digital design and prototyping tools, many practitioners prefer to test ideas immediately as they discover them, in parallel to researching the needs. In other words, delaying the “solutions” part to a late stage is unnatural. It’s also not uncommon for the flow to go in the opposite direction — as you’re testing ideas (right diamond) you sometimes uncover new user needs that require investigation (left diamond).

For this reason, the British Design Council itself had abandoned the original double-diamond, calling it “flawed” and “not fit for purpose in modern design”, and started offering a more flexible model that flows back and forth between the diamonds. Interestingly, this change has largely gone unnoticed by the tech product community, where the classic double-diamond model is still being taught as an unequivocal truth. In practice, testing product ideas in cheap ways while you’re doing exploratory research is both common and effective.

Sometimes The Ideas Come First 

In 2001 a Google engineer named Paul Buchheit imported his personal email into a Google database to make it readable and searchable from a browser. In 2002 a group of designers and engineers at Apple stumbled upon an early multi-touch device and started creating a new user interface paradigm around the technology. These side-projects turned into Gmail and the iPhone respectively. Both ended up addressing an awful lot of user needs (some that we did not know even existed), but they started directly with iterating over ideas rather than by mapping out the needs. 

You may argue that these were lucky flukes (subject to survivorship bias), or that these folk were actually working on their own problems which they understood well. Both are valid points. However you should consider the broader context of both stories. Back in the 1990s and early 2000s Apple and Google actively encouraged people to experiment, create demos, run dogfood tests, and generally try out many ideas, irrespective of supporting user research (which Apple didn’t practice as a matter of principle). This approach of trying out many things cheaply, dropping what doesn’t work and doubling down on what does, was also practiced by Amazon, Facebook, Netflix and many others, and led to many of the most popular products we use today. 

The “see what sticks” approach is quite wasteful and perhaps better suited for rich companies, but of course it’s just a case in point — there are yet other valid ways to discover good products. It is very important to consider ideas from multiple sources. User research is a often the best source of ideas, but meaningful ideas can also stem from market research, technological advancements, data analysis, and competitive analysis. Of course the users and customers themselves will propose ideas, and so will your managers, stakeholders and team members. Deflecting ideas with “we’re not going to consider this because it doesn’t map to any of the user needs we identified” simply isn’t viable in my opinion, and is going to justifiably antagonize your colleagues, managers and customers.  

You Can’t Prioritize Needs The Way You Prioritize Ideas 

Sorting out user needs and figuring out which ones are most pressing and most frequent is a very helpful exercise. Still, you can’t trust the list of prioritized needs to dictate what ideas to develop. For one thing, deciding that need A (e.g. I struggle to find parking) is more important than need B (e.g. I want to shorten my commute time) involves speculation and interpretation of the data. You may choose to go all-in on A just to discover it wasn’t as burning a problem for the users as you thought, causing low adoption. That’s because you can’t test needs the way you test ideas — putting a version of the idea  in front of the users and seeing how they behave. 

A second challenge is that even if need A is indeed pressing and the users are seeking a solution, it may not check the other 3 boxes of Cagan’s risks: you may not be able to develop a good-enough solution (feasibility), the solutions may be too difficult to use (usability), and addressing the need may not make business sense for the company (viability). When testing ideas, you can explicitly validate such assumptions, until you can say with good confidence that the idea is going to create the expected effect. 

Lastly, even if you develop ideas that successfully address important user needs, that doesn’t mean that you will necessarily achieve your goals. The connection between user needs and company goals has its own set of assumptions. For example, we may add an elaborate “find parking” feature to our GPS navigation system, but still not improve customer churn, simply because customers are  switching to car brands with whom we didn’t partner yet (this would be uncovered by market research or data analysis, but not necessarily by interviewing existing customers). 

For these reasons I feel it’s better to evaluate ideas directly against the goals rather than against user needs. User needs can be a useful filter, and the evidence we find during user research should be factored in, but it’s better to have a prioritization system that is optimizing for the end goal, and is open to many types of evidence.

Avoiding Dogma

To be clear, I’m not trying to denigrate user research, design philosophy, or any particular product methodology. If mapping and prioritizing user needs helps your company be more customer-centric and less top-down, you should definitely keep doing it. 

But I am speaking against a dogmatic approach to product development that emphasizes just one form of product discovery at the expense of everything else. It’s well worth keeping in mind these points:

• We seek a product that both addresses users’ needs and the needs of the company (and these don’t always overlap)
• Mapping needs and discovering ideas are not isolated, sequential activities. In fact, in your roadmaps you should plan to overlap them
• There are multiple valid forms of product discovery
• Ideas can come from anywhere and should all be evaluated through a variety of types of evidence  
• We should prioritize ideas, not needs, and the prioritization should be against the goals 

The conclusion will not shock you: there isn’t just one right way to develop products. Having a broad toolset and an open mindset will go a long way towards developing high-impact products that deliver value both your customers and your company. Don’t believe anyone who tells you otherwise.   

Title photo by Ozkan Guner

---

If you want to ramp up you product skills secure your ticket for the next public workshop or contact me to organize an in-house workshop or keynote for your team. 

---