Deliver a data-informed experience

Modern competitive advantage isn’t data-driven alone. It’s data-informed, inclusive of experience and intuition. Orienting an entire product around numerical outputs limits the team’s ability to provide actionable insight on the customer’s perspective. Service blueprinting is a framework used to define important aspects of the experience, what happens around an experience, what is worth measuring, and how to measure results. View the product through the lens of the experience. Then, focus and priority can resolve painful moments and expand on the quality of what works well.

There are four critical individual views to consider when understanding the impact of a new product, and any change management required:

1. The current state

2. The future state of the service and experience

3. The external factors that influence the service

4. The upstream dependencies and downstream impact

Understanding the current state

A blind spot for many teams is assuming an opportunity is greenfield and that nothing has been done before. Even greenfield efforts replace something, even if that something is largely empty. Understanding the current state is equally important for any replacement effort or consolidation.

Take time to understand what exists to date.

• If there is a product in place: Start by mapping out current state workflows and gathering current state metrics.

• If greenfield: Document the pains and opportunities that led to pursuing a new product, creating a baseline to measure against in the future.

• If replacing a larger system: Break each service down individually.

Avoid looking critically at design decisions and code quality because it was old, or the team at hand didn’t write it. Chances are the people who originally built the product did the best they could with the information they had at the time. Instead, take a step back to understand why the decisions were made that informed the original build. This way, the team is primed to build on top of past lessons learned, rather than repeating the mistakes made.

Defining a better future state

After unpacking the current state, define specific moments and aspects that improve the overall process. Is the new solution a one-to-one replacement? Or is there an opportunity to rework the surrounding business processes to elevate the success of the targeted solution further?

Any adjustments or new features have a broader impact that informs a number of actions essential for a successful implementation.

• How is the upstream data provided to the application?

• What would shifting downstream teams’ actions do?

• What would happen as a result of reworking the way a team is structured?

• Would anything change if individuals or teams physically sit somewhere else (e.g., closer or further away from colleagues) relative to each other in a workspace?

While systems-level changes may not be within scope, evaluate if modifications are necessary or beneficial. It’s critical to understand the impact of any changes to the workflow—even if the changes required are out of the team’s control. If not, time and time again, issues frequently surface as impediments to the success and speed to market of the development effort.

Investigating the external factors

Apply the completion of the current and targeted future state findings to the person using the application. Get into the headspace and location of the person using the solution. Having contextual inquiry of a representative sample interacting with the application provides the necessary context to drive a strong adoption of the product.

Some factors informing the larger context include:

Too often, in-flight products falter because processes are stapled onto the people building the product—not the people using the product. Talk to the people intended to use the application to know what’s at stake. Keep users involved throughout the process. Service design provides the framework for this effort.

Analyzing dependencies & downstream impact

Next up, evaluate the factors that keep the product and experience running. What tech needs to be in place to jumpstart the process? What needs to happen to keep the product working? Having a clear understanding helps paint an even more fulsome picture of the entire experience.

Upstream dependencies: The early steps in the journey, as well as other technical and organizational infrastructure that needs to work for a journey to start

The downstream dependencies: The next-step products or workflows, as well as the on-going lifecycle of customer experience management

Once identified, share findings with relevant teams as early as possible. These hand-offs become opportunities to build in advantage by coordinating across the experience for the customer.

Risky business

Each product is funded and prioritized on an individual basis. The teams tasked with delivering successful outcomes work towards given goals. As time goes on, they discover new dependencies—some of which may fall outside of existing funding initiatives. Often, to achieve objectives, teams create workarounds. While each product may individually hit the targets, the collective goal of providing a world-class customer experience falls short.

Fixed budgeting and planning cycles do not preclude teams from leveraging service design. Carve out time ahead of large planning and funding initiatives to build cross-team service blueprints that detail the entire desired customer experience and call out unknowns along the way. On smaller teams and efforts, use the same activity to build consensus among everyone involved.