1.4 Business capabilities & functions

One of the hardest things about creating a product is defining exactly what it is. This is foundational. If we can't agree on "what," then deciding "how" is impossible to achieve.

In my experience, one of the hardest parts of creating a product is clearly and accurately describing exactly what it is. This has so many implications. If you can’t distill your features into concrete, tangible goals, you’ll probably never finish building it. If your customer can’t understand how your product adds value, they’ll never buy it. If your business doesn’t align with its financial model, delivery will fail.

Creating your product capabilities and functions is all about creating a story that fills in this picture. It’s a very crucial step.

Introduction

Welcome to the last step of Mobilization. Now that we have a clear understanding of our product vision, we’ll turn our attention to creating business capabilities and functions. At a very high level, this means defining a concrete list of exactly what the product will do, ideally using clear, customer-facing language. We will:

1. Enumerate a list of very specific business capabilities — or, a catalog of operations we intend to build.

2. Elaborate on those to create use cases that unambiguously define precisely what the customer experience is and what the expected outcomes are.

This is a lot harder than it sounds in most cases.

When we say “define what the product will do,” what do we mean? Are we talking about technical function? Or are we talking about how it enriches our customer’s life? Or, are we talking about the user experience?

Often, when distilling a products’ capabilities into concrete details we “miss the mark.” For example, we might create a very accurate technical description of how a certain feature is implemented — but in the process, lose sight of what the original customer-facing value is. We proceed to build the technical feature even though the customer sees no value in it.

Sometimes, the disconnect comes in translation from one step to another. Just like the “telephone game” we played as a kid, one group relays specifications to another, and then that group to yet another. Design creates a UX, architecture defines how to build it, development creates a specification, and somewhere along the line mistakes are introduced.

Use cases should feel familiar to most teams. Defining use cases is an activity we’ve all likely done. Yet, even though we’re familiar with the exercise, we see frequent missteps in delivery: Customers that aren’t happy with the result, failure in the system (bugs), poor resiliency, security elements that were forgotten. The list goes on. The playbook prevents these gaps by addressing the root cause: A poor chain of validation from ideation through operations. For example, we introduce specific objectives, key performance measures, and metrics that validate each and every use case. This is a control process that ensures we stay on-track, maintaining a clear “line of sight” back to the original customer value.

Building a clear roadmap

As we finish this last Mobilization activity and prepare for Blueprinting, we are laying the track we’ll follow as we deliver the product. The track needs to be well-aligned. It needs to create clear expectations for everyone involved, so that the resulting roadmap and technical execution moves quickly and accurately to delivery.

Think of building a railway from one side of the country to the other, starting simultaneously from each coast. If one side is off by even the smallest measure, a tiny fraction of a degree, the result would be disastrous misalignment.

Therefore, before we start defining our business capabilities and functions, we need to check our definition of ready (DOR):

If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!