Defining “value” in agile product development is a challenge for organizations of all sizes. The definition is often framed and answered from an operational perspective, focusing on metrics like on-time delivery, productivity or predictability. Enterprises also define value from an outcome perspective focusing on financial benefit, user satisfaction or product scope delivery. 

Numerous challenges arise when defining value from these perspectives. When looking at value from an operational perspective, it is possible to optimize metrics without actually realizing business or user value. From an outcomes perspective, it is not always apparent how the metrics relate to one another and they can even be at cross purposes. Furthermore, it is often unclear how to combine distinct values to prioritize or improve a process or outcome. 

IBM Garage has developed a sequence of steps and versatile tools to align business and user value and we refer to this as value orchestration. We use value orchestration to guide product UX strategy and experience transformation and continuously deliver value in an agile environment. This methodology has been deployed and refined across multiple industries and Fortune 500 clients. Detailed below are the methods and findings: 

Step one: Understand business value through user behavior

Value orchestration begins with the understanding that business value is rooted in user behavior. We define users as any internal or external end-user of a process or tool. A business owner realizes value when their users behave in a certain way. For example, if the business owner is running an e-commerce site, they recognize value when users (new or existing customers) visit the site, purchase products and respond to advertisements. If the owner creates a workplace optimization tool, they might realize value when their employees complete tasks, do so quickly and don’t make mistakes.  

In the cases above, it is straightforward to understand the business value of  visiting a site, viewing an advertisement, completing a task or making an error. It is equally straightforward to imagine how the business might measure changes in these behaviors and quantify the value of those changes.  

And so, the process begins with asking product stakeholders to specify how they would like their users’ behaviors to change. A business owner might say, “I would like my users to not abandon their carts so often.” Reviewing shopping data, the business owner can settle on a goal to reduce the cart abandonment rate from 75 percent to a more modest 50 percent.  

Having a goal and a measure of success provides several advantages to the effort. We can answer three essential questions to which we can align any number of individuals or teams: 

1. What are we trying to achieve? A reduction in cart abandonment from 75 percent to 50 percent.   
2. How will we know if our solutions are working? When cart abandonment goes down. 
3. When will we be “done?” When the cart abandonment rate hits 50 percent. 

Once we’ve arrived at our goal, the next thing we need to do is answer, “Why are users abandoning their carts 75 percent of the time?” 

Step two: Create a value model

With a goal behavior and measure identified, we build a value model that links the behavior changes to financial impacts. These formulas take the measures of user behavior as inputs and produce an implied financial impact. This financial impact will allow the team to compare the value of changes in user behaviors against one another. The value model also enables the product owner to establish a consistent benefit calculation, through which the ROI of future solutions can be assessed. 

Step three: Identify root causes

Step three in our process is to identify the drivers of the user behaviors we are trying to change. We call these behavioral drivers, root cause pain points.  

In the cart abandonment example we can start by conducting dedicated research through interviews and reviews of existing data to determine why customers abandon their carts. We will likely identify many pain points with varying degrees of significance. For this reason, we design our research and analysis protocols to sort root causes in order of priority. In this example, users might struggle to edit their order, access the “check out” page or enter payment information. By prioritizing these pain points in terms of impact on cart abandonment, we can prioritize the root causes to mitigate with solutions in the next step. 

Step four: Solutioning

Step four of our process is solutioning for the prioritized root causes. At this juncture, a design team receives a design brief which details:

1. What the solution is supposed to do: Reduce user cart abandonment.
2. How it is supposed to do it: Make it easier to edit an order, enter payment information, etc.
3. Applicable technical constraints: Functionality must be enabled for iOS and Android.

The team will select the root causes that they feel are the most readily solvable, and ideate solutions to those root causes. In our example, by reviewing the user’s pains with editing an order, the designers might re-create the editing experience to make it easier, faster and more intuitive. 

With a design drafted, it is time to validate. 

Step five: User testing

The fifth step of the process is to test our solution with users. We first create a testing protocol where we present users with the original pain point and ask them to describe and rate the pain quantitatively. We then walk through the new experience, asking questions to gauge ease, speed of use, intuitiveness and other measures relevant to our goal behavior. Finally, we ask the user to rate whether we resolved the pain quantitatively. If the output of our user testing indicates a high degree of resolution, we can prioritize the design for development. 

Detailed below is use testing conducted in the IBM Garage work with Frito-Lay. 

Step six: Development

At this stage, developers will be on the lookout for any adverse impacts of the prioritized design. The solution documentation includes the business goal, its intended impact on users and how the solution is meant to influence user behavior. For example, the business goal is to reduce cart abandonment by 25 percent and the solution is intended to generate a 5 percent reduction through simplified order-editing. If the developed solution produces an experience that might negatively impact the intended user behavior, such as slow load times, developers are empowered to engage the product owner and design team. 

Step seven: Monitor impact

Our final step is monitoring for the expected impact on user behavior using our measures of success. By plugging real-world data into our value model and assessing progress towards our goals, we can quickly calculate the incremental value realized so far and estimate the expected value of addressing the remaining root causes. 

Real world benefits of agile value methodology

The distinguishing feature of value orchestration is that user and business value are directly linked. Business value is a function of user behavior and user value is a means of changing that behavior. As we’ve shown through the process above, we can estimate, translate and measure user behaviors, allowing us to calculate and predict business value. 

This approach lends itself directly to agile delivery by incorporating value assessment into the product development lifecycle. Getting started only requires a goal expressed as a change in user behavior. With a root cause analysis of user behavior, product teams can pull new user pain points into the backlog while working towards the same business goal. This enables a feedback loop of experience improvements linked to business benefits, accelerating time to value.  

Learn more about IBM Garage