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 organized 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.


Build your team and product strategy around users (Part II)

This article is Part II of my series of posts about our strategy model (Job-Value map). Refer to Part I for background information and context. In this post, I cover more on how this model is built and used in practice.

The Job-Value model

As I mentioned in Part I, two concepts have inspired our work, “Jobs To Be Done (JTBD)” and “Value Chain (Wardly)Mapping”.

User Job Steps

As mentioned before, we use a simplified version of “Job Maps”. This version is shown in the figure below.

Our 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. Note that we do not use this as a replacement for backlog and roadmap building tools such as “User Story Mapping”, the steps in this model are universal and are designed to cover a User Job. Our JTBD inspired model has the following four steps:

1. Define and Prepare

Your users usually decide on what to do before doing it. They might plan for the Job and try to understand how to do it. In many cases, this step is not performed explicitly and can be just a brief moment.

In one end of the spectrum, for example when a user decides to turn on the TV and watch the new Netflix show or watch the football match.

At the other end of the spectrum, it can include what an informed customer or buyer does to buy tickets for a carefully planned trip.

2. Execute

In this step, users take action on the mental or literal plan they have built in the previous step. The “Execute” step is where the users make progress towards the objective they have set for themselves.

The objective can be a simple goal such as getting relaxed by spending time in front of the TV. In this case, execution can mean the act of watching TV and not doing anything else.

The objective can also be spending time on away to relax and disconnect from the stressful life at home. In this case, execution can mean buying tickets and planning all accommodation.

3. Analyze

Not all users explicitly “Analyze” the performance of their progress. The analysis can happen as thinking if their like using (in C. Christensen’s language “hiring “) your product. It can also happen as the quantitative results of their progress towards their goal.

For example, a user might find the music they listen to, useful and motivational for his/her workout session and deem that session successful.

A user who wants to use your product to run a marketing campaign will look at the effectiveness of your product and how long does it take to setup his/her campaign.

4. Conclude

In the “Conclude” step, users either continue hiring a product or fire it. The conclusion step is done according to the performance of the product in helping the user in making progress. They also finish the job or move to another iteration of the same job.

Product Value Chain

We have also designed a layered value chain model that describes the different levels in which our internal or external products are managed. The value chain for each product or organization might differ, and you should try to map your layers and build your value chain based on your own needs.

This value chain has the following layers:

1. User Layer

This layer is where the actual user interaction happens. The User Job Steps, briefly define how the user interacts with the final product and how the user goal is achieved. The components in the “User” layer are built to ensure all aspects of your user’s JTBD are covered. Ideally, each of the “User Job Steps “ in the job map should at least have a component that ensures success in that step.

The “User Layer” is the only layer that should exist in every product and inform the requirements for building the layers below it.

There are many ways to assign components of your product portfolio to each step. For example, in an entertainment product, you can have a component associated with the definition and prepare step that tried to understand user behavior and predict when to trigger them with relevant notifications. Or a component that sends recommendations and notifications based on the user taste.

In Part III, I will discuss the practical goals and details of each step and the strategies for each step in more detail.

2. Core Layer

This layer usually includes product or components that are more aggregated than the infrastructure layer. These products are built to span across multiple user steps and be less opinionated about the end user. The role of this layer is to enable the layer above it to deliver its function more efficiently.

In many cases, especially in smaller less complicated end products the “Core Layer” might not exist. The need for having such layer becomes evident when the product and the team grow and more complexity appears in how it operates. The need for breaking things down into smaller chunks can be a strong motivation for such layer.

3. Infrastructure Layer

The infrastructure layer provides the basic building blocks and components that are least visible to the users. This layer is the should be viewed as given by the layers above it. Infrastructure in our context does not include the commoditised infrastructure that is available to every product (e.g. anything provides by AWS or GCP). It includes products and components that enable a chain-link effect, in your product strategy. These are very basic low-level components that are unique to your product’s needs and are built to be as generic as possible.

As with the “Core Layer”, the “Infrastructure Layer” might not exist in the early stages or smaller products but as the need for more efficient operations of a product arises such horizontal needs appear in your organization.

The Two-dimensional Job-Value map

We use the Value Chain and Job Map as the dimensions in a two-dimensional strategy model that can visualize and inform strategy. The figure below shows our two-dimensional map for strategy, for the sake of simplicity we call this model the Job-Value Map.

“A Job-Value Map is a visualization of Users’ Jobs To Be Done and your Product Value Chain in support of those jobs. It helps you understand, and strategize with the user at the center of your model. “

The goal for this visualization is to ensure that all of the components in your product strategy focus on enabling the user to “Get The Job Done”effectively, efficiently, and with satisfaction.

You can see in this model that each layer in the value chain might have many components and the components to a higher layer can depend on one or more components in the lower layer. Relationship among components in our model is similar to Value Chain (Wardly) Maps. In Job-Value Maps, the arrows indicate a need that is satisfied by the component at the end of the arrow.

Use Job-Value Maps to inform strategy

You can use the Job-Value Map and model to perform gap analysis, set strategic goals for components, compare your offering with competitors, scenario planning, and organize your team to work on the products that maximize the value delivered to the user.

For example, you can use Job-Mapping to identify a Gap in the “Define and Prepare” step, where there is no strategy for luring users towards your product when they have a “Job To Be Done”.


An important step after defining your value chain is to define strategic principles for each layer of the value chain as they relate to your Job-Value Map.
Here are some of the examples of principles we use for each layer:

User Layer

  • Build user-centric products and focus on user understanding to optimize user experience.
  • Map out customer flows into job stages and ensure there are no gaps in their flows.
  • Prioritize integration with other products from our value chain for chain-link effect.

Core Layer

  • Build for the User layer and strive for enabling our value-chain as a chain-link.
  • Build with various use-cases and multiple customer segments in mind.
  • Build for scalability, performance, and ease of integration.

Infrastructure Layer

  • Prioritize Core layer as a first class customer to accommodate chain-link effect in the value chain.
  • Build for wider use-cases and delivering value indirectly to end-user through integration with other components.
  • Focus on strategy-driven product development rather than user driven development.

I will discuss strategy building in Part III and provide some insights in how to focus innovation and strategy in each layer or step.