Why Do Products Fail? – Ignoring Context

Blog: Tyner Blain

Wrapping up the your product failed because you didn’t enable your users to realize value branch of the root causes of product failure, is this article on the context in which your user is using your product. If you ignore your user’s context, they won’t be able to realize the value you provide – or won’t be interested in solving those particular problems at that particular time.

Value Realization

One aspect of solving the right problems is making sure that you’re enabling your user personas to realize value.

[larger image]

This can be further decomposed into different aspects of realizing value.

[larger image]

Previous articles reviewed

Even when you pick the right users and the right problems, with a good understanding of what you need to do to solve those problems, you still may not enable your users to realize value – thereby not really solving their problems. One way to think about it is that your product doesn’t implicitly solve the problem – the user solves the problem, using your product, if they can. Recognizing that users learn, grow, and change over time is important to assuring that you are creating a product that they can use effectively.

You also need to make sure that your product is targeting the context(s) in which your users can – and want to – solve the particular problems you are trying to help them solve.

Context

“You keep using that word…” [Happy 25th anniversay, The Princess Bride!]. Fair point. Context from a product management point of view, means the environment, situation, and mental state of your user. In the user experience field, folks are trained to do contextual inquiry, essentially to help designers get a handle on the environment in which people use a product, in order to design a more usable product. A product manager, maintaining an outside-in perspective, can do the same thing, to make sure that the capabilities of the product are the right ones.

Precious has a great presentation where they identify several patterns for designing products, taking into account that we should not think about context as the device a user is using right now, but instead to think about all of the devices that people use throughout their day.

Patterns for Multiscreen Strategies from precious

They show that thinking about different interface form factors works as a reasonable proxy for the physical environment a person is in.

They go into more detail in their blog post, definitely check it out.

What they’ve keyed in on is that you can’t just design (or product-manage) for a persona, you also have to think about their environment.

The relevance of a persona’s goals, in a given context, are a reflection of the actions that person will take in a given environment. If you’re watching a video on a large screen, your entertainment goals may be immersion, but if you’re watching it on your phone, the goal is more likely to be distraction (to kill time).

One of the most successful mobile shopping apps, for example, was created with the intent of enabling a person, while standing in line at a coffee shop, to purchase something they already knew they needed – before reaching the counter. The primary focus was efficiently processing a transaction – oh yeah, I need a new thumb drive – not enable a window-shopping experience. The team that developed this app referred to their user as a “spear fisher” – capturing both the aspects of the persona and the contextual-relevance of a particular goal.

Getting Things Done (GTD)

As another validation-point of the importance of a user’s context as impacting which goals are relevant to users in a particular context, we can look to the popular Getting Things Done movement created by David Allen. In GTD, a context is defined as “the tool, location, or person that is required to be able to complete an action.” One of the ideas that makes GTD powerful is that it encourages you, when you think of something that you need to do, to “file it away” (if you can’t do it that instant) for when you can do it – this relieves your brain of the burden of juggling that to-do item, as long as you “trust” your system for filing-away and eventually doing stuff. The system for filing away items has evolved to include the idea of the context in which you can actually accomplish something. For example, picking up replacement furnace filters would be something that you can accomplish in the context of “while out running errands” – and your system will remind you to do this when you are out running errands. It will not remind you to get replacement furnace filters while you’re at home watching a movie. The emergence and embracing of this concept serves (me) as significant validation of the hypothesis that goals have relevance that varies by context.

Pulling that back into product-management, your product could have failed because while you identified an important goal for users, you didn’t take into account the context in which your product is being used – and that your product is being used in a context where solving the goal is not important – or where the user interface needs to be designed to support that particular goal.

Customer Journey Mapping (Customer Experience Mapping)

Chris Risdon at Adaptive Path has a great presentation on mapping a customer’s experience (or journey) throughout the lifecycle of engagement in a process or flow (or with a company or product). This is a tool / technique principally developed for informing user experience (e.g. design decisions). However, I have successfully co-opted some aspects of journey mapping to frame an outside-in, customer-centric view of user goals. The journey spans the breadth of engagement in an experience, broken up into different steps. Each step reflects a shift in context and it becomes apparent that different goals matter in different contexts. Some goals exist in multiple contexts, but with differing relative priorities, and often with nuanced differences of what it means to address the goals adequately.

If you’re dealing with a single (or simple) product, you may not get value from building out a journey map (and it is a non-trivial investment of time). If you’re looking across a portfolio of products, or looking for opportunities to address “adjacent” problems – this can provide a great framework for exploring and contextualizing (yup, I went there) the decisions you’re making.

Summary and Attributions

*Thanks Lane Halley for the image of people in chairs. Not sure where I found it, but here’s a link to a great presentation on UX for lean startups from Lane.

Make sure that you’ve got the context in which your users will use your product in mind when identifying the problems that your product will help them solve. Without that understanding of context, you risk creating a product that does not enable your user to solve the problem it was intended to solve.