If there’s anything product people love, it’s problems — solving problems, finding problems, uncovering problems. We just love problems. And there are lots of great frameworks for researching customer experiences to help uncover problems. Yet, no framework can ever tell you what the problem is.

So when you’re staring at a sea of Post-Its and knee deep in a spreadsheet, how do you determine where the problem is and what you should focus on to start developing the product?

I’ve observed that there are two main sources of problems that can be used as a lens to determine where to start with your product:

• Things that are done manually
• Things that are done inefficiently

Technology is wonderful for automating things and making them more efficient. Yet people will often not realize that what they’re doing is inefficient or could be automated. They may have frustration with their current process, but may have accepted it as reality and probably will not be able to articulate a better solution.

You or people in your organization may be asking, then, why even bother talking to users in the first place, if they can’t tell you what they want? A famous example of this is the oft-cited Henry Ford quote, sometimes used as a cautionary tale against user-driven innovation:

If I had asked people what they wanted, they would have said faster horses.

Even though Ford probably never said this and didn’t invent the automobile, it’s worth exploring what Ford might have encountered had he had a more open-ended discussion with his users. What if he had employed the practical empathy method and approached his potential customers with a curious, understanding, and listening mindset regarding their experience with their current modes of transportation? There he might have found something useful.

For example, instead of asking “What do you want?” and getting an unhelpful answer (“A faster horse!”), what if our hypothetical Ford were to say, “Tell me about your current means of transportation and what it means for your day-to-day life.” Then, he might have heard about how the horse needs to be fed often, creates a lot of waste, attracts flies, requires stabling, regularly needs new shoes, and needs rest on long trips. It would be clear that the existing process has a lot of pain points, and simply having a faster horse would not solve the problem, even if that solution were articulated.

The responsibility is then on the product developer to further question that experience and design a solution — which in many cases may take the form of the adjacent possible. As Steven Johnson explored in Where Good Ideas Come From: The Natural History of Innovation, the adjacent possible is a theory from scientist Stuart Kauffman:

The adjacent possible is a kind of shadow future, hovering on the edges of the present state of things, a map of all the ways in which the present can reinvent itself.

The strange and beautiful truth about the adjacent possible is that its boundaries grow as you explore them. Each new combination opens up the possibility of other new combinations. Think of it as a house that magically expands with each door you open…Keep opening new doors and eventually you’ll have built a palace.

The car pushed the boundaries of what people thought was possible or advisable. It’s hard to believe this now, but early motorists were not well received:

And yet, the automobile eventually caught on because it solved a problem and automated the manual process of caring for a horse to drive your carriage by removing the horse entirely. Most people probably never would have been able to say that the solution was removing the horse or imagine the adjacent possible where removing the horse was even an option. Yet they probably would have been willing to open up about their existing process — and help the curious interlocutor identify the inefficiencies and manual steps that pave the way for a new product opportunity.

But before you get to the new product opportunity and the adjacent possible — and naysayers shouting things at your users from the side of the road — there are a lot of artifacts to sift through: user interviews, surveys, industry data, and anecdotes. Even after you’ve de-duped and sorted the Post-Its and created the customer journey, the massive pile of insights and numbers may still not present a clear opportunity. (The wall above, for example, is one such pile of insights, and comes from a recent exercise regarding the process people go through to retire.) So here’s a sample list of things to look for as you analyze the activities your users are doing in their current experience, viewed through the lens of what people are doing manually or inefficiently:

• Are they writing things down on paper?
• Are they doing things in person?
• Pulling together multiple sources on their own?
• Doing things that take multiple steps to complete?
• Even better: multiple complicated steps to complete?
• Is there a particular activity that seems to take them an inordinate amount of time?
• Or an activity that seems to cause particular frustration?
• If it’s something they do frequently, are there steps in the process they often forget?
• Are there resources they find themselves lacking or forgetting that are necessary to complete the process (at all, without frustration, or within a reasonable amount of time)?
• Are they doing things that are not the highest-value use of their time?
• Are there simple things that you could make even easier?
• Are there lots of small steps? Could they be combined?

From there, you can start to see where the opportunities are, what the competition is, and start to hone in on the problem your product might be able to uniquely solve given your insight into the customer experience and your core competencies.

Ultimately, products succeed because they give us time. They allow us to spend more time doing the things we want to do and the things we’re good at rather than those that frustrate us. Your users may not realize it, but they want to outsource the things they’re not good to a product. And you can empower them to do so by finding the things they’re doing manually or inefficiently.