So you're working on a problem people need solving, you're communicating with them often, and your product should make money if it works. It might feel like it's time to build something, but it's time to double down.

Making something extraordinary is a lot easier when you truly understand why you're making it.

You've already spoken to some of your audience about their problems, and now you're connected with more people to talk to. So let's talk to them and learn what the ingredients to our secret sauce will be.

The comparatively small amount of time it takes to become an expert in the problem you're solving, and your audience, is possibly the best time spent in product development.

There are few products which only have a single audience. As you work to research and understand your users and their problems, make sure you pay equal attention to each audience.

Research, research, research

There are few better ways to gain information than by talking to people. We’re social animals, and we’ve evolved to absorb so much information by communicating (not just talking), face to face. Individual answers in a survey offer a fraction of the insight a five-minute conversation provides.

It’s scary, but talking to more people, especially strangers, using in-depth conversations is one of the most powerful ways you’re going to understand your audience and their problems.

That’s not to say that survey data is useless. We should be constantly seeking quality data. But unlike machine learning, huge datasets are only helpful to us humans if we know what we’re looking for in the first place. That’s where user interviews come in.

Quantitative or qualitative?

I find it useful to think of qualitative meaning investigative, and quantitative meaning comparative, at least in terms of user research.

Qualitative research is uncovering which questions to ask, and quantitative research is asking them at scale.

When we're first finding out about a subject, breaking new ground, we delve deep into tangential fact finding, often down rabbit holes, until we begin to get a sense of what we're looking for. Your first conversation with someone on a new subject you're trying to learn, will be structured and executed very differently to the hundredth.

In the beginning, because you don't know what you don't know, every piece of information seems as valuable as its peer. But over time, as you repeat the process over and over, patterns emerge and you streamline how you approach the conversation, focusing on emerging trends.

For example, imagine you were looking to help the elderly dial relatives using their smartphone, because you know they sometimes find it difficult. For the first few people you spoke to, the time of day they made the calls might feel as important as the reason they needed contact. But as you speak to more people, you realise there are occasions when they need someone to pick up, for help, rather than just for a casual chat. So you double down on those reasons, seeing that a need is emerging to distinguish between reasons of calls, making sure to capture this additional information. You didn't ask these questions at the start, but through investigation, you realise these were important data points to record.

If your plan was to then survey 100 elderly people, you'll only have a limited number of questions you can feasibly ask in this format. Knowing which questions to ask is the difference between success and failure - think Hitchhiker's Guide to the Galaxy and its meaning of life. Quantitative research will tell you which questions should appear on the survey, and quantitative research helps you sort, and make sense of the answers that come back.

As your current goal is to understand a user’s problems deeply, it stands to reason you employ a method to investigate which delivers deep analysis, like long conversations, role playing; a qualitative approach. Problems are often complex and affect the world around them in weird ways, so take time to really learn about them.

Early in your research, try fewer high-quality, deeply insightful user interviews when understanding a problem.

You won’t reach statistical significance at this stage; and you shouldn’t try just yet. User interviews are the most effective tool at this stage.

User interviews

A quality user interview should be focused on its objective and the stage you’re at. Early in understanding a problem, you’ll want to let the user talk broadly about the issues they face, but as you narrow down the scope of the problem, you’ll want to be much more targeted in the information you’re trying to elicit.

You should already know how to find your audience, so inviting individuals users to one-to-one sessions, diving deeper into their needs, is the next stage. You may want to incentivise these sessions, by either offering to buy a coffee, using vouchers or just cold hard cash.

Asking users to give up an hour, or two hours of time is a big commitment, so offering money is a reliable way to secure it.

Make sure your users know it's the time they're being paid for, not answers. They shouldn't feel compelled to give answers if they don't have them, and this won't help you either.

The value you're mining during these sessions is enormous. Without this knowledge, it's very unlikely you'll create a product people want. If you're new to interviewing users, it can feel like a formality, as you often believe you already know what they'll want. In my experience however, even when dealing with users whose problem you share, you'll always be surprised by the insights you learn, and the secrets that help you build something great.

When can you stop interviewing users? Well, never. Not until your product is out of service. In terms of when you know enough though:

I'm ready to start prototyping when the last two interviews with users didn't reveal anything new, or at least anything significant.

For further research tactics, a great resource is the UK Digital Government Service's Service Manual. Check out their user research resources.

Beware solutions offered by your audience. As you talk to many people, you'll find people offering solutions, instead of thinking about their problems. We're all natural problem-solvers, so it's to be expected. However, it's only by understanding a problem in its entirety, can we hope to solve it comprehensively.

Someone saying "I need an app that...", isn't the problem. Focus on a deep understanding of the problem itself. Problems naturally lead to solutions. Solutions have to look much harder to find real problems.

When and not if this happens, politely take down their suggestion and then get back to examining their problems.

Personas

We create better products when we inhabit the worldview of our users. Personas are a hack to get us in an empathetic mindset when designing for them.

We're really just at the beginning of understanding our audience, and so we won't spend too much time here creating personas to represent our them. Our personas, like almost all other tools and assets we'll develop, will iterate and evolve as we learn. Creating some basic ones now will help make sure our prototypes actually deliver value to our users.

Personas are concepts to help us test ideas against; a vision of our ideal customer. For example, if we're thinking about how a user journey will feel to the different types of people who will experience it, we can pick up a persona, and see it through their eyes, to help us understand their emotions, their needs, their fears. These personas can also be used to help us target our marketing to different groups of people.

A simple persona would describe attributes such as age, sex, family structure (e.g. single, married, married with children etc).

Let's take a guess at an early persona for Airbnb. Twenty-something person (male or female), single, professional in California. You'd likely have many personas, and they grow in complexity over time, but hopefully you can see by mapping out just a few of your early users, designing your product with its users in mind becomes a little more methodical.

Right now we'll capture the main personas that represent our audience. Don't create a persona for every person you interview, but instead at this stage, a single, or maybe two to three personas should suffice. Try to capture the common features of these people, for instance if they're all a similar age, or hold similar family structure.

There's plenty of time to create more personas in future which represent our growing audience.

Problem diagrams

OK, so by this point hopefully you'll see the emphasis on really understanding your audience and their problem(s) before you begin building your product. This isn’t procrastinating - this is more crucial to the success of your product than fixing critical bugs before a release.

Laying out problems visually really helps with our comprehension of the issue and its many factors. Let's look at a couple of ways to capture a problem in visual form.

Spider diagram
Spider diagrams are a great way of showing how different elements/entities/factors/attributes are related to each other.

They'll help us identify related problems, to the core problem our audience is facing.

They not only show relationsips between these problems, but also provide a rough hierarchy, with the bubble in the centre representing the high-level or summary problem, and each ring of bubbles moving outwards, becoming more detailed, narrow and specific sub or child problems.

I'll use an example of a parent needing someone to look after their children. We would have spoken to lots of parents and taken down what they tell us the problems are that they face when trying to find a childminder.

In the centre we have the core problem, the problem which is at the heart of what you're trying to solve. As you move out to the next layer, you have the level below of related problems, which arise as a result of the core problem. You can add additional levels of problems if you've captured them too, drawing a line back to the problem which derived them. For example 'I don't know who is available when I need them' could spawn problems like 'I don't know who is currently open to childminder', and 'I don't know the time of day people are available to care for my kids'.

Childminders also have a problem which they're trying to solve; earning money. It's crucial you create a diagram for each audience.

Ensure you're considering the problems for each audience (if you have more than one), giving equal though and research to each. Often their problems overlap, and the solution to one, is a solution to another.

Laying out our problems in this way gives us a great reminder of what the issues are, as well as understanding how they're related to each other.

This simple problem diagram is a form of proof in your level of understanding.

360 diagram
This is a diagram I created to help me visualise a problem, its impact, audience, triggers and causes. It's simple, but effective in helping see the issue holistically, and completing it ensures I’ve understood where the problem comes from, all the way through to its effects.

It differs from the spider diagram, in that it doesn't seek to identify related problems, but instead the elements and entities related to the problem.

In the childcare example, there’s a parent audience, and a childminder audience, each facing their own problems. So I would creat a diagram for each.

As you can see, there can be multiple causes, triggers and so on each diagram, and you may want to draw lines between each bubble, to show how they're related.

Visual representations of our research helps us understand more comprehensively. Next we'll look at a method to summarise what we've learnt through our research, in a single sentence.

Problem statements

Problem statements are a way of condensing many aspects of a problem, down into a single sentence.

It's an efficient and concise way of storing your problem; a way to remember it and all its factors.

If you've followed the detailed interview template and completed the problem diagrams, you should have all the information to-hand, to write this sentence.

A problem statement might look long, and slightly awkward, but when you realise all of the aspects of the problem it covers, it’s remarkably compact, yet impactful.

I personally like them as a way to ensure I’ve understood a problem. If I can’t reduce down its elements into a sentence, there’s a good chance I’m confused about the issues and need to tighten-up my understanding.

Let’s look at an example:

Example: As a parent between 20 and 35, because my young children can't look after themselves, when I need to run an errand, I want to leave the house, but it's hard finding someone to look after my kids because I don't know who can help, which makes me feel frustrated, fearful and helpless.

This sentence is describing some of the many factors which we need to consider when looking to solve this problem. It consists of different components, which we can work through methodically, until we have a full sentence.

This is the format:

As a {persona}, because {cause}, when {trigger}, I want to {objective}, but {problem} because {reason}, which makes me feel {emotion}.

Distilling down the problem into its persona, cause, trigger, objective, problem, reasons and emotions, gives a very solid and clean bed to invent upon. You can adapt this format to your situation, but try to include these key components because they describe the crucial elements of the problem.

For each audience, create a single, high-level problem statement. This is a milestone to reach in your product development journey, because it encapsulates hours of analysing the market, talking to your audiences, and digging deep into their problems.

Current user journeys

Something my time in business analysis taught me was the importance of separating the what from the how.

At this stage in our product lifecycle, we want to capture the current experience of our users (the current state); how they interact with their problem now.

We'll do this with a user journey; simply a way of describing the path a user takes, from beginning to end. As with many of the methods in this book, there are no formal, hard and fast rules to creating a user journey. Some people draw rough sketches of screens the user would see, others make a step-by-step to do list. I prefer using a flowchart, to create a 'process flow'.

When we begin problem solving and thinking up our big idea, we'll then create a process flow for how we'd like the new journey to look, solving their problems (the future state).

Everything we do is a process, which is why I use process flow diagrams. They're a flowchart specifically showing processes. Everything done by anything is a process. There are actors, as in the people (or machines or organisms) enacting the steps in the process, and sometimes there are assets (things) which might be needed. For example, 'person (actor) hammers (process) nail (asset)'. Even algorithms can be described as processes, applying steps to solve a problem, with conditions and loops.

If you can create a user journey (the what), without mentioning any technical solutions (the how), you’ve managed to comprehend your audience’s experience into its purest form. Strip back our technical innovations, and people still have to solve the same problems (mostly). For example, being socially connected without physically located with each other has always been a problem; a problem Facebook tries to solve.

It's not always possible; obviously some problems are caused by technology, and so the solution will involve another technology. Like for example Hootsuite, which helps solve problems when running marketing campaigns on Facebook (as well as other social networks).

Learning how to create a working process flow sounds like a good reason leave this website immediately. But it’s immensely powerful, and really quick to learn.

You could just list out some steps based on what the user tells you, but when it comes to designing an experience around this list of steps, you'll likely find holes and problems. Creating a working process flow means we've recorded the information consistently, which is crucial to then replay it properly, and to build something from it. The journey 'flows', which should hopefully mean we've captured it accurately.

Could the concept of Airbnb be described without technology? Yes. Someone could require accommodation (trigger), go knocking on doors to find accommodation (search), figure out which place is suitable (comparison), hold their place (book) and then settle up (pay). Perhaps they even wrote in the guestbook afterwards (review).

Technology sometimes invents new experiences in our lives, but most of the time it makes existing processes more efficient. Even virtual reality, a nascent technology (at the time of writing this in 2020), can be described in a process. It seeks to create reality virtually, so we could just create a process flow of reality (current state), and then create another process flow which shows virtual reality (future state). If this is slightly confusing, don't worry, we'll get clearer soon.

With our Airbnb example, our big problem is finding other people to stay with. Laying out the necessary steps to finding, booking and staying in accommodation, plots the journey of our user, pure, free of any assumptions about technology. We've broken down our big problem into its smaller constituent parts. Now we can look at the journey and apply our solutions on top, basing our prototypes on the raw data, not assumptions.

Ask your audience to step through their problem, and how they would currently solve it without technology (if possible). Start to lay out step by step, how they experience the problem, so you can record it.

Creating a process flow

There are different approaches and levels of technicality to good process maps, like BPMN or UML, but I’d just stick with flowcharts. Events, activities and decision gates.

Let's start by looking at each element we'll use in our palette:

EVENTS

Step 1:
Choose the process you'll draw. Name it after the objective the process is achieving, like 'Go shopping', or 'Call someone'.

Step 2:
Draw a swimlane for each actor (person or system) which does something during the process.

Step 3:
Draw a start event and label it with what triggered the process. Now draw an end event.

Step 4:
Draw an activity for each step in your process, and name them in the active tense. For example 'Cook food' not 'Food cooked'. This helps for consistency and because steps don't always get completed (it's the intention that counts).

Step 5:
Are there steps where something may or may not happen? Maybe a point where multiple things can happen at once? Use a gateway (you'll see below).

Step 6:
Have an activity that might interrupt your process? Like 'Have a shower' interrupted by 'Phone rings'? Use an intermediate event.

Step 7:
Bask in the warm glow of a well formed process flow.

Let's look at an example

Here's our Airbnb process for booking accommodation.

Notice how the big problem of needing to book accommodation quickly starts looking like a series of smaller problems? Let's imagine you can receive a recommendation for a place to stay during the process, and look at the part the host places during the guest's booking experience. We'll add a little more detail in the form of another actor (the host), gateways and an intermediate event.

This process map very clearly lays out the steps in the journey, and gives us a great framework to know what to investigate next (i.e. the activities in the process). Process maps are also a very effective ways of communicating these ideas to your team and stakeholders.

This example is simple, and purposefully so.

I recommend drawing a maximum of 15 activities on a single map. If you need to draw more, you're being too detailed in one diagram.

Try simplifying your digram and then explode out the activities to be their own process flows (child process flows). In the example above, search for accomodation could be 15 steps in itself (if not more), so use layers of detail, depth, rather than huge maps and more real estate.

These diagrams will help you to map out what your users do today to solve their problem, or if they don't have a solution, how they'd solve it step-by-step. For example the first video call solution would look something like:

1) Select person to call.
2) Ring callee.
3) Callee answers call.
4) Converse with callee.
5) End video call.

Capturing user journeys

Through your user interviews, you should be building up some great evidence for your audience's current experience.

Create a high-level process map for their experience, end to end. From the trigger of the main process, to what ends it. If your process is describing something that happens again and again, like making a call, the beginning would be needing to make the call (the start event trigger), all the way through to what ends the process (ending the call, the end event).

With this high-level master user journey, you can take each activity and break that into its own process map. You'll probably find using these maps will highlight gaps in your knowledge, in your user's experience. If you know what happens during some of the activities in the flow, but not others, you'll soon realise and go back to your audience for clarification.

Being able to lay out your user's current journey to this level of detail means you've reached a level of understanding few share.

It's genuinely a rare thing; if you've taken the trouble to understand the problems of your audience this deeply, you're in the tiny minority of product managers.

These diagrams are assets you can go back to when you need a refresher, as well as key peices in sharing knowledge with your team.

The depth to which you understand the problem is proportional to the value your solution will yield.

Now let's look at solving these problems.

CHECKLIST

Are you an expert yet?

Interviews
You've spoken to several members of your audience, in-depth, capturing a rich seam of data points.

Problem diagram
From your interviews, you've captured the core problem and related problems, and translated them into an easy-to-read diagram.

Problem statement
From your interviews, you've been able to pare down the big problem they're experiencing, into a single sentence.

User journeys
Based on your conversations, you've mapped out your audience's current experience, with the same level of understanding of each activity.