Leveraging Jobs to Be Done to Start a Target Architecture

Have you ever ordered take-out food and after driving 20 minutes home and realized that something is missing? It happens to all of us at some point. It also happens in software development. Agile helps make this less likely as you deliver products in incremental pieces and have close interaction with your customers. However, you still need to understand the larger why of what your customer is asking for as this could change your overall product and architecture vision. Luckily there is a framework in software delivery that solves for this known as Jobs To Be Done (JTBD).

Harvard Professor Clay Christensen explains the JTBD Theory as helping understand the why behind the what. Having this context and detail is critical before you start building anything as it defines how users want the product to be in the future. In this article, we will learn more about JTBD and how you can combine the output with other bottom up and top down data sources to start a target architecture.

Henry Ford is attributed to saying, “If I had asked customers what they wanted, they would have said faster horses.”

Ford realized he needed to go beyond what users say, and understand the why behind what they want. That is the underlying goal of JTBD.

The JTBD framework leverages a multi-step research process with users to determine what they really want. It starts with User Experience Research (UXR). This is an interdisciplinary science that deals with understanding user needs before a solution is created, and then using those findings to build a user-centered design.

There are two types of UXR research that are done as part of the JTBD framework - Generative Research and Evaluative Research.

Generative Research is done before building a solution, to answer the question “What should we be building?”

Evaluative Research is performed while a solution is being built, to answer the question, “Are we building it correctly?”

Both of these research steps involve interviewing users to understand their needs. Ultimately, after the research is completed, you end up creating the JTBD which follows the below format:

While doing [situation], users need to be able to [action], for the purpose of achieving [goal].

This provides a perspective of what the user wants from a future functionality perspective. Let’s look at an example. We will dissect the different parts of this JTBD later in the article.

While handling customer servicing calls, agents need to be able to view account details for the purpose of answering customer questions.

Inventorying JTBD for a particular domain area helps provide a holistic view of user requirements. This can then be used as an initial input for starting a target architecture.

Target architectures are a critical artifact for any software product. They define the target state for a software product providing a bigger picture view of how all of the pieces fit together and their interfaces. They also address a number of factors including functional and non-functional requirements (e.g. availability, durability, reliability, resiliency). A key point is they show how we want things to be (e.g. target state), not how they are today (current state). There are various approaches for doing a target architecture. I recommend a two pronged approach: top down and bottom up.

Top down approach

A top down perspective usually starts with a Product Vision.

This lays out the vision of what you want a product to be over time and provides overall direction. An example of a product vision could be a company that has many fragmented User Interfaces (UIs) and wants to consolidate all of them into a single UI. However, a vision by itself is not enough to do a target architecture. You need to ground the vision by leveraging bottom up data such as JTBD.

Bottom up approach

JTBD grounds the overall vision by providing that next level down detail of the what and the why. A vision without JTBD to back it up can be ambiguous and leave open room for misinterpretation of the requirements. On the other hand, JTBD without a vision can be too tactical and can lack overall direction. What I’ve found is you need both to be successful.  Going back to our example, if the product vision is to have a consolidated UI, you need to understand what experiences should be part of that UI. In our earlier example of a JTBD, “While handling customer servicing calls, agents need to be able to view account details for the purpose of answering customer questions” starts to provide some of that detail. You would want to map out all of the JTBD to have a full understanding of the customer needs.

Event Storming

Another valuable bottom up input is Event Storming. In my previous article on Decomposing the Monolith with Event Storming, we discussed how you can leverage Event Storming to start a target architecture. It's an interactive way to do Domain Driven Design based on current state. It often is used to decompose a domain to understand how it could be broken into microservices. It also provides good insights into the overall business process. However, it often focuses on current state. JTBD on the other hand is focused on how you want things to be. Leveraging both of these together provides a view of how it is today along with how you want them to be in the future.

Pain points

An additional bottom up input that is helpful for a target architecture are pain points.  These represent the things that need to change that can range from having a direct impact on productivity to the overall customer experience. Some example pain points include manual processes or lost productivity from having to flip between multiple applications/UIs.  It is common for pain points to come up as part of both Event Storming and JTBD frameworks.

So how do you bring the top down and bottom up data inputs together? The answer is capabilities.

Capabilities represent the ability to do something–e.g. display products, fulfill orders, etc. With Event Storming we explained how you can map Events to Capabilities. With JTBD, you can do a similar mapping. If we look at the JTBD story format, ”While doing [situation], users need to be able to [action], for the purpose of achieving [goal]”, typically the action is what can be mapped to a capability.

For example, while handling customer servicing calls, agents need to be able to view account details for the purpose of answering customer questions.  The capability in this JTBD is “View Account Details”.  This exercise can be done for all of the JTBD in a domain to produce a list of desired capabilities.

Next you can go through grouping exercises to align capabilities that are similar together. In some cases you may need to tweak the granularity of the capability so they are at the same level, either by going up a level or down a level in detail. In the Event Storming article, I mentioned creating a capability taxonomy to help with the groupings.

Once you have a set of grouped capabilities, you can then make a decision on what system should provide that capability in the target state. As part of that, determine what data sources and data outputs that system needs along with the interfaces. In some cases it may be an existing system, in other cases it may be a new one that needs to be built. Repeat this for each of the JTBD and then you should have an initial architecture blueprint.

In some cases where you are having difficulty deciding on the system for a capability, performing a Proof Of Concept (POC) in each system can identify additional pros/cons to help in the decision.

My personal recommendation based on my experience is to use both a top down and bottom up approach for gathering inputs for a target architecture.

This ensures a target architecture that solves for a product vision is grounded. JTBD ensures the proper research is performed to understand the why behind the what. This ultimately will improve target state decision making.

JTBD is an excellent way to understand what a user is really asking for by probing for the why behind the what. Using this along with Event Storming, pain points, and an overall product vision to map to capabilities helps provide the underlying data needed to create a target architecture. Not only will this help get buy-in from various stakeholders to the target architecture, but will also improve the accuracy and longevity. I hope you found this article useful and learned some new concepts!