Lean User Research: Perfectly Execute the Right Plan

I recently watched a keynote by Tomer Sharon, UX Researcher on Google Search at the Google I/O 2014 conference entitled 'Perfectly Executing the Wrong Plan'. This talk was so good I have decided to break out the topic and explore it as a framework in this post.

Tomer is at the forefront of what is being called 'Lean User Research', which applies agile methodologies to the existing techniques of User Experience (UX). With connectedness leading to greater and greater complexity, and the need to get products to market rapidly so we can generate insights, it makes sense that we need to start to re-evaluate some of the more traditional UX processes that can often eat up time and resources.

The keynote itself was centred around app development, but this can definitely be applied to any product. It also is more focused on startups, but definitely has applications in all organisations. I'll build the framework around this broader product categorisation.

Perfectly Executing the Wrong Plan

Why do a huge number of products fail in the market? One of the primary reasons can be the fact that the product being built isn't actually solving a problem for the customers, which means that they will ultimately not care about what is on offer.

This leads us to the most important concept - whoever was creating the product failed to fall in love with a problem, which means there was no opportunity.

There are three variables we need to confirm to ensure we don't fall into this trap. This can be expressed in the following diagram:

Validating a Product Framework

Some Product Development Traps

One of the issues with the focus on the Lean Startup methodology is that the emphasis is placed on getting something into market as fast as possible. While this has merit, there are some basic elements that can be validated before we get building to reduce the risks of failure.

Tomer outlines a few of these key traps that may be the root cause of these issues:

  1. The team created a solution when there was no problem
  2. The team may have listened to users, but they didn't observe their behaviour (i.e asked friends and family). This may have provided red herrings or false responses.
  3. The team didn't test the riskiest assumptions. There should always be a keystone core idea that will make all other assumptions fall apart if proved wrong.
  4. The team rushed to make a Minimum Viable Product (MVP) without confirming the previous points.

Again, this ultimately leads to the trap of perfectly executing the wrong plan.

The Solution: Lean User Research

Our solution then is to apply some Lean User Research up front with the product before we jump into execution. By definition, this process provides insights into product users, their perspectives and abilities, delivered to the right people at the right time, and as fast as possible.

This following diagram shows these variables:

Lean User Research Sweet Spot.

Lean User Research Sweet Spot.

There are three key Lean User Research techniques we should explore. These are:

  1. Experience Sampling
  2. Observation
  3. Fake Doors

Experience Sampling

This technique requires that you interrupt people at various points in their day to gather insights. After defining a test group, you should ask them a question over and over again during a set period (for example five times a day for five days).

You need to make sure the question is great - no 'yes / no' questions, and it should ask about repeated behaviours. An example for a note taking product would be 'what was the reason you recently used a piece of paper to write something down?'.

This should help you get a deeper understanding of them as users - their workflows, needs, pains and delights.

Observation

This technique requires you to observe the user in a relevant environment. While we need to listen to what the user has to say and the conversations they have with others (their jargon and language), we need to make sure we are observing their actions to understand their deeper intrinsic behaviours.

Part of this process includes gathering and collecting artefacts - the things they use to create or complete a task. Try to also notice and identify what they want and need.

The following diagram outlines key elements of this process:

Observation Framework

  • Routines: What are the repetitive tasks they undertake?
  • Interruptions: What breaks their continuity or stops tasks?
  • Annoyances: What causes frustration in their tasks?
  • Delights: What do they love or enjoy about the task?
  • Transitions: What do they do in the lead up to a task or once they complete it?

This should help you learn about their assumptions, problems, workflows and goals, and hopefully identify key features.

Note, for both Experience Sampling and Observation, if you are curious about ample size, check out the Q&A in the video at the bottom at the 32:20 mark.

Fake Doors

This technique is about validating features before you build a product. So in essence practicing the art of "faking it 'till you make it".

Most often this can be done by creating a product landing page and using this to gather data.

The biggest mistake here is to only use the page to capture email addresses. While this may give you the ability to communicate to the person in future around the product launch, it does not give you any actual deeper data on intent.

Instead, we should try and illicit some form of commitment from the user, to prove that there is in fact a genuine commitment to the product if it is created. A good analogy here is Kickstarter - a project is only engaged when a certain level of commitment is achieved from the wider public.

Another technique that can be applied is the 'button to nowhere' or '404 testing'. This means either adding a button to your landing page about a topic or buying search or display advertising to measure click interest. Once they click through, display a 'Coming Soon' or similar message.

To use this technique accurately, decide beforehand the ratio of people who click the button or ad versus visitors or impressions, and then measure results to quantify.

The following example shows a page validating its users will commit by paying $5 for early access.

Fake Door Example

You may be concerned in this situation that customers may be being led to a product that doesn't yet exist, and they may complain to you that they are being lied to. This is actually a positive - if they have taken the time to complain, you know you have a product that they desperately want!

Evaluation

Once you have completed your Lean User Research, you will hopefully have a range of data points generated quite rapidly that you can dive into to determine product viability. With this in hand, you will be able to answer questions like the following:

  • Do people have a discernible problem we can try and solve?
  • Who are the potential customers?
  • Will the product be useable?
  • Will the product be better than the competition?
  • Do people actually want the product?

From here, the next stage is to get the product into market as fast as possible - Build, Measure, Learn and Repeat.

Check out the original keynote video below:

Tomer is writing a book on Lean User Research. Sign up for updates if your interested.


This post continues my series on Mental Models.