Leveraging Jobs to Be Done to Start a Target Architecture

Understanding the “why behind the what” to take both a bottom up and top down approach

Have you ever ordered take-out food and after driving 20 minutes home you realize 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).

In this article, we will learn more about JTBD and then how you can combine the output with other bottom up and top down data sources to start a target architecture.

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.

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

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:

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.

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.

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.

JTBD ground 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.

Another valuable bottom up input is Event Storming. In a previous article, 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 is focused 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.

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:

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.

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 difficultly 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!

DISCLOSURE STATEMENT: © 2022 Capital One. Opinions are those of the individual author. Unless noted otherwise in this post, Capital One is not affiliated with, nor endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are property of their respective owners.

Related posts:

We all have some hectic days which drain all our energies. Work overload, prolong hours meetings, work under pressure, work in an emergency is some of the situations which stress our muscles. Here is…

With recruiting season in full swing, the team at TechTogether Boston is launching a new social media and Medium series called #techtogetherworks aimed at providing a platform for our team to provide…

You can follow the instructions exactly and apply the product religiously every day. But then find yourself asking “Is it actually doing anything?”