1.4 Business capabilities & functions

Before we start defining our business capabilities and functions, we need to check our definition of ready (DoR):

Before starting

This is the final Mobilization activity. You’re laying the track the team will follow through Blueprinting and Delivery, so alignment matters — like a transcontinental railway built from both coasts, a tiny error in direction now becomes disastrous misalignment later.

Here we build two artifacts: a list of concrete business capabilities (what the product will do) and use cases that define the customer experience and expected outcomes. The common failure mode is “missing the mark” — producing accurate technical descriptions of features while losing sight of the customer value they were meant to deliver. Clear, customer-facing language prevents that.

You’ll need to have finished 1.3 Product vision first.

Guide to business capabilities & functions

Your goal in defining your business capabilities and functions is to clearly exhibit the need your product fulfills. As noted above, this can be challenging when considering all of the different perspectives, terminology and value each stakeholder hopes to realize.

To solve this problem we want to create a common frame of reference:

1. Our list of business or product capabilities. This initial list is essentially a catalogue of product features that we plan to build. It will continue to grow as the team iterates on subsequent deliveries.
2. Then, we break down our list of complex business problems in brainstorming sessions to arrive at customer focused use cases, the foundation of our customer journey.

The outcome is a foundational roadmap to move forward with: Our business capabilities, usually categorized by function, and the use cases that belong to each capability.

It’s important to reiterate that customer and stakeholder involvement is absolutely required to ensure success. We need everyone that might have influence on the product at the table: Actual customers, product ownership, business leadership, design, technology, even operations. This activity is crafting what the product is. Everyone needs to feel comfortable and agree on a common understanding.

What are business capabilities and functions?

We’re starting with the visible parts of an iceberg, so to speak. We begin by imagining what our desired target state roadmap looks like. To do that, we list our business capabilities and functions:

• Business capability. Top-level business functions. For example, a bank might have issuing, funding and payment processing capabilities, while an e-commerce store might have shopping and fulfillment capabilities.
• Business function. Capabilities are further categorized into “function.” Functions delineate operations that might exist across different business domains.

For example, we might start by deciding our banking application needs two capabilities, “issuing” and “funding.” The former is customer facing, applying for, creating, and servicing a loan for a customer. The latter is the internal movement of money to fulfill the loan. Two very different capabilities that we can start to think of as “domains” within the business. (If you’re unfamiliar with the concept of domains, here’s a quick primer).

At the same time, these capabilities might do some things that are very different, and some that are a bit similar. The “issuing” capability needs to handle loan “applications” and “validation” of the loan application. On the other hand, the “funding” capability will have “issuance,” but also some kind of “validation.” Both need validation, but otherwise consist of different functionality.

Think of the capability as a name for the business domain; a high level conceptual place to group similar operations. Think of the function as the activities or verbs belonging to each capability. You should end up with expressions such as, “The issuing capability will take care of loan applications, and validating those applications.”

Don’t worry too much about what it means to have the same function across capabilities right now. Eventually, we’ll see these as hints to look for shared functionality across domains — but that comes later.

What are use cases?

Use cases are descriptions of how a customer (or user) interacts with a system. For our purposes it’s important to write use cases in the clear, ubiquitous language of the customer. That means using plain “customer speak” so that everyone at the table can read and comprehend the use cases.

For example, “Sally (Borrower) buys a new bike from Peloton (Merchant) and chooses to pay using installments. MyBank validates Sally’s application and approves a loan. Sally accepts the terms. Sally’s account is created, and her purchase is funded.”

What about “user journeys?”

User journeys tie together the different stories, or use cases, that a customer has with a system.

For Sally, the user journey follows her through different stages. Together, a collection of use cases make up the journey.

Part of Sally’s journey will include, “MyBank automatically debits Sally’s (Borrower) checking account each month, applying the amount to her loan balance. Sally receives payment advice by email.”

Inputs

• Vision and strategy documents.
• The right people and team participation (e.g., Product Owner, business analyst, business domain experts, customer).

Process

It may be helpful to start working on chapter 2.1 Product strategy in parallel. There is natural synergy here, so it’s often much easier to finish defining your capabilities and functions while also thinking about overall strategies. The product strategy activities define your user personas, customer needs, and objectives.

Our goal is to define a complete customer journey map. This map can take different forms. Personally I prefer to keep it simple and use a table. This makes it easy to create and edit the business capabilities, functions, and customer journey in your project wiki. You can use this template as a starting point.

This is a workshop exercise, where everyone is expected to contribute. This is particularly important — in essence, we’re inviting all the stakeholders to the table and asking them, “Tell us what you want the system to do?”

Some people will think in terms of capabilities and some from the perspective of user stories. This is fine. The important thing is to capture all the information.

I like to have a live, editable table that everyone can work on simultaneously, adding capabilities, organizing functions, and writing use cases on the fly (Confluence works great for this). If a live table isn’t your style, or if everyone’s in the same room, use a white board with post-its and sticky columns. It’s fine to have several people editing at the same time, too. Don’t stifle creativity!

Start with a table or columns that looks something like this:

From here, start adding whatever comes to mind:

Defining Use Cases

Use cases should be either a base case or an alternate:

• Base case. The “blue sky” use case. Generally defines a small, specific case around a single actor following their “happy path.”
• Alternate. Covers other small, specific, single-actor cases that arise from variations of the base case. Often “unhappy paths” that must be handled.

All use cases should be concise and follow these best practices:

New stories will be discovered along the way, all of which contributes to the whole user journey. It should be iterative. The whole journey doesn’t need to be set in stone from the start.

By the time we’re done, we should have something that looks a bit like this:

Notice a few additions and refinements that we’ve added along the way:

• The capabilities and functions get fleshed out and clarified. New functions appear that weren’t obvious at first.
• New actors show up, including third-party service providers (e.g., a credit bureau like Experian). See 2.1 Product strategy for more on defining your customer personas. Each persona represents an actor.
• Several similar variations on a use case get grouped together — label the variations as “alternate” use cases.
• Each use case gets tagged with a priority. P1 for the first product increment (highest priority) and P2 for “everything else” works well. Try not to create too many tags. What really matters is identifying what the team will deliver first, and what goes on the backlog.

Outputs

• Business capabilities and functions. At least 1 business capability, probably categorizing a few different functions.
• Customer journeys. At least 1 to 3 proposed customer journeys consisting of several use cases to begin exploring. Individual use cases will be grouped by functional area.
• Prioritization. An indication of which use cases the team will begin working on immediately, and what will be addressed at a future time.

Now that we have our business capabilities and functions, we have the foundation for a concrete roadmap. From here we can start building our product strategy.

If this section defined our “what,” next we need to start talking about “how.” Next up, our product strategy begins to lay the framework defining the “how.”

Templates

• Business capabilities and functions template
• Workshop invitation template

Next activity

• 2.1 Product strategy
• 2.3 Strategic event storming