Navigating Ambiguity: Uncover latent needs

This is part of a series called Navigating Ambiguity, designed to provide guidance on creating clarity from chaos when designing, inventing, and improving products or services. If you’re a product manager, strategist, user researcher, indie hacker, or basically anyone that builds, this is for you. Subscribe to get notified when the next article drops.

It might sound counter-intuitive, but to make truly great products and experiences, you not only need to listen to what people say, you need to listen to what people don’t say. You need to read between the lines, take a leap of faith, use your gut, infer, and ultimately create a hypothesis that’s (in)validated in market. From there, continued and keen observation can help you navigate towards something a critical mass of people might value.

To unpack what people don’t say, it can be helpful to think about unknowns. Unknowns typically fit into two categories: “known unknowns” and “unknown unknowns”. Known unknowns are defined questions that we know we don’t have the answer to yet. They’re typically grounded in an observed behaviour, action, or other factual data. Questions like “people are saying they want X but why are they doing Y?” or “why do people feel frustrated when signing up?” ground the question in the fact that there is Y action or a feeling of frustration, and leave us to answer “why”.

Unknown unknowns are the questions and data that emerge through the process of discovery. They are the questions you didn’t even know were important to ask, and they lead us to net new opportunities and tangential domains. The following framework might be helpful:
‍

‍
In either case, the combination of data from unknown knowns (your intuition), known knowns (facts), unknown unknowns (exploration), and known unknowns (questions), will inevitably help you infer what people need.

Some might call this inference a “latent need”, especially if it hasn’t been explicitly stated by anyone. I just like to call it a “hypothesis”. That’s because a need is not a static statement and it’s not “truth” until it’s proven in market. Even then, it’s something that’s continually evolving, depends on context, is being shaped by actual use of a solution, and is different for different people. This sounds easy to understand at first, but has taken me years to comprehend and put into practice (and I’m still learning).

The Jobs To Be Done (JTBD) framework might suggest you’ll have a eureka moment and discover a need:  “Aha! people don’t want a drill, they want a hole in their wall!”, or “Aha! truck drivers don’t want a milkshake, they want to stay awake during a long haul drives!”. JTBD can be a helpful way to reframe problems to open up the solution space. However, that doesn’t mean “tick”, you’re done. Limiting ourselves to a static need statement limits our aperture to the unknown unknown. In other words: simplification can make you ignorant.

It’s human nature to create static, simplistic definitions to ease cognitive load. We like to define large groups of people as a "segment" or a "demographic", but their needs are complex and heavily dependent on context. This cognitive bias is one of the reasons why persona's can fail, but it makes things easy. We look at people and problems as static, when in fact we live in a chaotic, dynamic, non-deterministic world that we don’t quite fully understand.

So, how we do we solve for this dynamic world?

If we take a page out of linear algebra’s book, we know that solving non-linear systems can be done by either linearizing the data, or iteratively approximating a system until the error is sufficiently low. The former results in generalizations that are inaccurate and lose the essence of the system. The latter attempts to get as close to reality as possible with each iteration, but takes many, many more iterations that must be solved sufficiently fast enough. Speed is important because we’re trying to solve a dynamic system that could fundamentally change by the time we’re done solving for it.

In the product world, this means that if we don’t actively and continuously research, we’ll likely be missing out on emerging needs to due rapidly evolving shifts in culture, values, policies, products, etc.

Unearthing unmet needs requires a combination of answering “known unknowns” and leaving yourself open to discovering new information and unlocking the “unknown unknowns. There’s not explicit step-by-step instruction that works every time, but it can be helpful to follow the following rough guideline:

1. Capture Data:

Observe, interview, and survey people to gain an understanding of how they behave, why they do certain things, how they feel, what they say, what they value, where they hesitate, where they take shortcuts, their hacky solutions, and more.

InsightLab’s AI-powered interviews can be a helpful way of getting the breadth of insight from surveys with the depth of user interviews, but it won't replace observational research in the field (yet). The image below shows a pathway (the designed solution), and a dirt path cutting directly across the grass (the desired path). Desire paths are a great example of how keen observation can lead to unique insights about human behaviour.

2. Analyze Data:

Get curious. What are the behaviours, values, actions, and feelings that people have? Do only certain groups of people behave a certain way? Find the discrepancies between what people say and how they behave. Find the “juicy tensions”. Find the themes and extract key quotes from your user research. Tools like InsightLab empower you to get curious and can help you with this.

3. Critical Reflection:
‍
Don’t simply ask your customers to solve the problems they are experiencing. They aren't the ones gaining a holistic view on the problem and can only solve based on their current paradigm.

“No problem can be solved from the same level of consciousness that created it”. ~ Albert Einstein

It can be helpful to reframe solutions your target audience might have mentioned as problems. If they say “I wish I could have a faster car”, reflect on whether that means they simply want to get from A—>B faster, or other. Zoom in and zoom out to critically reflect on the way people are doing things. From a systems point-of-view, does it make sense? It can also be helpful to consider the Juicy Tensions between what people say and do to unearth insights in this phase.
‍

4. Create & Test a Solution:

Sometimes the best way to tease out a problem is by creating a solution, typically in the form of a prototype. The purpose isn't to evaluate the solution itself, but rather to use it as stimulus to observe and critically reflect on how it’s being used.

Before I ever used an electric bike, I didn't realize that I had a need to feel safer at a traffic stop. I just figured stopping at a light on your bike was what it was and didn't ever think about improving that experience. It wasn’t until I had experienced the electric boost from the bike that I realised how much safer I felt by being able to accelerate and keep ahead of the traffic behind me: a new need was revealed through a solution.

The faster and deeper we can go through these four steps, the closer our understanding of customer needs will match the needs of users. We’re never quite “done”, but tools like InsightLab can help you both capture and analyze data so you can critically reflect and generate valuable insights.

DJ Sanghera