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.