Build your team and product strategy around users (part I)

Most of the successful products have one important thing in common, they are user focused, and the user had been at the center of the product design.
As the product and the team grow, the product becomes even more complicated. In an agile organization, products end up being built by multiple teams, and the challenge becomes creating a cohesive product and organizational strategy. 
Working at an extremely agile and flexible organization, I end up constantly thinking about how to do this while making sure we build everything centered around the user.
This the first of four articles that share a model and idea that I have been experimenting with in my team to align the product organization and product strategy around our users. This model is by no means the final version, and where it should be, we are still experimenting with the model and iterating on the details. Here is a high-level summary of the methods, we have been using to build an organizational and product strategy around our users and their experience. 
If you end up using them and experimenting with a similar approach, let us know so that we can learn from your learnings as well.
These posts are mostly written with software and technology products in mind, but potentially similar models can be used in other industries as well.
Let us start with some background to help you understand the ideas behind the proposed model. I highly recommend that you gain a certain level of familiarity with the concepts below before getting deeper into the proposed model.

I have organised these articles in the following order:

Part I covers some basics and background context, and it gives a high-level overview of the concepts that have inspired this model.

Part II presents the model in detail with some examples and visualizations.

Part III provides insights into how this model can be used in practice and in conjunction with scaling agile in an organization.

Part IV will provide some idea on how this can use for strategy in a competitive landscape.

Jobs to be Done Theory

Our main inspiration for user centered product strategy and innovation is the Jobs To Be Done (JTBD) theory as introduced by Harvard Business School Professor Clayton Christensen:

”Most companies segment their markets by customer demographics or product characteristics and differentiate their offerings by adding features and functions. But the consumer has a different view of the marketplace. He simply has a job to be done and is seeking to ‘hire’ the best product or service to do it.”[1]

A JTBD is the higher goal for which customers use products, services, or solutions. Companies use JTBD as a framework for innovation inspired by user research and understanding, reducing reliance on chance and luck. 
Jobs can be broken down into multiple categories, such as Main Job, and Related Jobs. Each category can have emotional and functional aspects to it, for more information see the description in the Innovator’s Toolkit website.

For example, users might use a Music listening device to entertain themselves, relax or focus. The act of listening to music is just a means to the end. In this context, music is competing with TV, videos, computer games or sleep.

In using the JTBD framework, we try to map the high-level universal steps each user takes to reach their ultimate goal. Our goal is to systematically understand and design products that can make each step easier, faster, more efficient, or even unnecessary. This approach is heavily influenced by the article in Harvard Business Review Article “The Customer- Centered Innovation Map.” written by Lance A. Bettencourt and Anthony W. Ulwick.

My posts in this series do not cover the process of identifying customer/user jobs or how to create the job-mapping in detail. There are several useful resources available online for doing so, and there is a highly recommended book “Competing Against Luck” that covers the theory in detail.

Value Chain Maps

Another important concept that has inspired our work in this model and is worth mentioning is “Value Chain Mapping” introduced by Simon Wardley, Also known as Wardly Maps. We use the two terms interchangeably through out these series. 
Wardly Maps use topography to visualize the landscape and inform strategy. Wardly Maps use topography to visualize the landscape and inform policy. Value Chain Maps use always start with a customer need and end in commodities and things that are available to everyone.
We do not use Wardly Maps to their full extent in practice; we just use a concept very similar to Value Chain Maps to visualize and discover opportunities in increasing value delivered to our users.

The Strategy Model

This section is a glimpse of how we use the above concepts in practice. 
We use a simplified version of job mapping as shown in the figure below.

This model is used to identify higher level universal steps our users take towards achieving their goals and jobs that they hire our products to do.

In part 2 I will explain in detail what those steps mean and how they can be used in practice.

Universal Mapping of Customer Jobs

We have a layered value chain model that describes the different levels our internal or external products are managed.

Our Three Layer Value Chain
These two models are used as dimensions in a two-dimensional strategy model that can visualize and inform strategy.

In part II, I will discuss in detail how we combine these two methods in practice to develop strategy, communicate to stakeholders and organize autonomous agile teams.

Like what you read? Give Ali Sarrafi a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.