While business sponsors bet on business outcomes, they expect a good return on their investment (ROI). This investment was to build the most impactful product experience. Cost is a factor when evaluating the ROI, but it does not have to be a deciding factor.

Our capacity to deliver, drives the trade-offs we make. We need to the set the bar on product experience outcomes high enough, but at the same time, set ourselves up for success. Now we have to figure out how to succeed without burning all our resources (or running out of money). There is cost involved in building (people, skills, resources, support, and so on). There is also risk and we will incur risk by not building something today. It is important to have insights on missed opportunity, the cost of a rework, the cost of a repair, and so on. Once we identify our risks, we can choose to invest more to mitigate them or choose to live with the risks:

To find the smartest way to create a product experience, product teams need to consider the following:

At this point, we have an idea about the functionality we need for meeting ArtGalore's Key Business Outcomes. We already have the high-level user story map defined:

We also have prioritized the features that we need to build in order to meet the business outcomes:

We have success criteria for each feature:

The next step is to detail the user journeys for each feature. For this, we need to keep in mind the success criteria we're aiming for. These success criteria need to get woven into the product experience. We also need a way to measure and validate the success metrics.

Let's take a look at the feature that marketplace visitors can sign up to receive a monthly art catalog:

The activity "subscribers should be able to read newsletters through mobile or desktop" has captured the success metrics, but signing up is not enough. Receiving the actual newsletter, and then having an option to unsubscribe, are necessary to completing the end-to-end functionality.

We do know now that the success metric is defined by the ease of signing up. At this point, we would do well to explore if we should ask the user to sign up on the website and receive the newsletter through postal mail even! We could also explore if the option to unsubscribe is legally mandated. The important aspect here is to define the user journey. For instance, if a feature is not mandated by legal compliance, then that is a negotiable card for us now. It also depends on the target segment. So, we could still choose to not build a feature now and decide to manage the risk. The risk is not just because of legal noncompliance but also about how the brand can be perceived. There is a cost of risk associated with this, which will be captured in subsequent steps.

This negotiation is possible only where our success has no direct correlation with the functionality. At this stage, we want to elaborate all possible journeys for a user to meet their goal. There are many journeys to offering this product experience. For instance, any of the following is possible:

So, our Impact Driven Product for this feature is the one that offers the best possible user experience including the functionality that meets the success criteria, plus metrics to measure the success criteria. Before we decide the costs of building this, we need to map the value.

When creating a product experience, technology can play two roles. Firstly, technology can be a business enabler, where business operations or some parts of the core business, are complemented by digital solutions. Secondly, technology can be a differentiator. Here, software technology/digital solutions drive the core business.

It is important to internalize the difference between the two roles that technology plays in our business. Business enablers can bring a great deal of value to the business, but they play only a supporting role. Businesses can still exist without a digital enabler, although they may not thrive or scale, whereas, a differentiator is the core product itself. If the digital product doesn't exist, then there is no business to run. This is where the IP (intellectual property, which is the intangible value created from patents, copyright, or creativity) of a product is created.

So, business outcomes can be driven by digital solutions that are either enablers or differentiators. It is crucial to know if the feature that we are evaluating is a differentiator or an enabler. In the case of our newsletter, the content of the newsletter (our curated artworks and so on) forms our differentiators. However, the process to receive the newsletters isn't our differentiator. So, we can choose to build the simplest digital solution or leverage what already exists. At this point, let's say that to evaluate these four journeys is our best bet for creating an Impact Driven Product experience:

We don't need to start coding every feature into the digital solution. During the early stages of product development, we must assess where to spend our capacity and resources. Often, both business sponsors and engineers get carried away by the possibilities that a digital solution can offer. Since we have now methodically established the business outcomes, the most important product features, and the success metrics to achieve, we need to find the right fitment of solutions.

Once we have established a differentiator or an enabler, we need to explore the possible options available to us. The first step is to decide if there is even any value in building the feature. We could also look for solutions outside (off-the-shelf products) or use an open source tool or outsource (to a noncore product development team). If our feature is an enabler and if our success metrics can be achieved by an off-the-shelf tool, then we should just proceed with finding the optimal tool.

In our example from the preceding story map, our feature is to ship out a newsletter. We need to assess how the content of the newsletter will be created. The value of the newsletter is in the content it offers to the art buyer. This is the differentiator, and hence we might do well to invest heavily in content building, rather than in the process. In this context, if we assess sending newsletters by postal mail versus sending them by email, then email seems to be the lightweight option.

Now, we can also explore the best way to allow users to sign up. Sending an email seems simple enough for users, but for them to discover our email address, they're likely to be already on the website. Also, it takes additional effort for someone to sort through the email requests and maintain this list. In this context, building a simple sign-in section on the existing website and mailing to the subscribed list, might be efficient. So, we might arrive at the following journey as the most valuable experience:

We need to have a way to track the success metrics. So, this also forms our digital solution. This tracking will be not just for the metrics related to signing up, but also for us to track how many of the users who signed up converted to enquiries or sales. Again, this is an assessment about an enabler/differentiator. While the data itself is privy to us, the process of capturing the metrics may not be our differentiator. So, there is an opportunity for us to explore off-the-shelf tools that can help us to capture and report metrics.

We get to this step only if we have established whether a feature is a differentiator or an enabler, but with no options or suboptimal options, for ready-made solutions. We need to assess if we can build this functionality in the time frame that we have (refer to Chapter 6, Managing the Scope of an Impact-Drive Product).

This will help us to arrive at the costs that include (but are not limited to) the following:

Now we can drill down to the specifics of cost numbers. A quick-and-dirty solution might require higher maintenance. Compromise on user experience might require higher training investment. In some cases, pricing for hosting, an off-the-shelf solution needs to be worked out. However, our cost assessments can also be relative. So, we can box our feature costs into small, medium, or large buckets, or even rank them on a scale of 1-10 in terms of complexity (determined based on the preceding aspects).

In some cases, we may end up not meeting some functionality, because the cost of building is too high. Yet not building something might have a negative effect on the product experience. For instance, providing an unsubscribe option in a user's profile might involve higher development effort. This might increase the rank of this card from three to five (on a scale of ten). So, we decide that this is not the most critical functionality to build at the moment. The success criteria are not dependent on the ability to unsubscribe, but compliance requires us to offer the option. So, we are incurring a risk by not providing this option. We have to agree to invest in the cost of building this option the perfect way, or decide to incur the risk, or find a simpler way to do this. We further refine our journey as the most valuable experience, as shown here:

Risks are the items that can meet all success criteria needed today, but may incur a future cost. This could be due to any of the following reasons:

This is not to be confused with a scope negotiation. This risk is an indication of the compromises we are making today, in the context of current internal and external constraints, in order to meet the Key Business Outcomes and success metrics. It would help to capture these risks as trackable cards in our risk backlog. We can revisit these risks later.

The items on the risk potential list should be reviewed, based on the impact they could have on the business outcomes. We can then choose to factor them into our cost of building or continue to keep them as open risks.

What if our costs are too high if we have to meet all success metrics? Should we attempt to deprioritize any success metric? This is a business decision to make. If the ratio of cost to impact isn't acceptable to the business, then we need to explore what is increasing our costs. Is it a technical approach we have taken, or are the goals so ambitious that we cannot achieve them? This means that the business needs to see so much value in the feature, in order to justify our costs. This then feeds back to the defining success metrics phase. We need to always set up and plan for success. It's all or nothing.

Estimates form a small part of this activity. Effort involved in building this feature will also add to the cost, but there is no reason for us to get precise numbers of the exact number of hours we would spend on building this, and compare them with past feature building and so on. This aspect about estimates and staying lean about our development processes is discussed in the third part of this book.

The cost -impact matrix can help us visualize the trade-offs and advantages we get by investing in a product feature. This can help us prioritize and prune our product backlog.

Based on the cost and previously determined business value scores, we now have a clear view of our prioritization matrix. The features in quadrant one are the quick wins (low cost / high value). Anything in quadrant four should not be picked up. Risk backlog, which exists outside of the quadrant, should include functionality or tasks that haven't been picked up now, but are likely to have an impact later. Also, this gives a clear view to the business sponsors of the costs they will incur when we need to build this functionality in the future.

All the analysis involved in defining the Impact Driven Product experience and ensuring that all business functions are aligned toward meeting the same Key Business Outcomes, as well as a view of costs, comes together in the Cost Impact matrix. The Cost Impact matrix offers a visually compelling view of how a feature's value compares to the cost of building it. This can enable decision-making around which feature ideas to pursue for immediate benefits and which ones to invest in, for longer-term strategic benefit. It also helps in analyzing trade-offs and functional scope, and therefore in determining whether a feature idea can be trimmed down or whether it's worth investing in a feature idea even though the costs are higher. Once the cost-impact comparison is done, the feature ideas can make it to the product backlog.

Now, we have our backlog ready, so let's go and build our product in the next chapter!