Why Value Is Made Up and Dates Don't Matter

Over-budget. Under-estimated. Late. 

In the digital age, investment in software is mandatory. Yet, the return is unreliable due to the difficulty in predicting both the effort and the impact of a software release. How do you drive your organization to success with so much uncertainty?

What is really happening

You may not see it directly, but it is likely that decisions are being made by managers, directors or other company leaders and not by the people doing the work. By the time the project is distilled to the delivery team, so many decisions and accidental commitments have been made that they are told what to build, how to build it and when it needs to be done. 

If the team is lucky, those decisions were made in coordination with them, but even then they are committing to scope and dates when the project has the most unknowns. The decision-makers are betting that the product value, which is an educated guess at best, is well-worth the time, money and resources invested. Consequently, success is measured by how close the team delivered against a target date, which is when they expect to reap the value of the release.

The problem

The issue with a delivery date-driven approach is that actual success is a positive impact to your business, which can only be assessed after the software is delivered to the user, well-after the investment has been made and sometimes not at all. Often success has little to do with whether a release was delivered on-time.

The solution

The lopsided focus on dates occurs when businesses place too much emphasis on what is being built rather than why they are building it. The business has passively made the choice to invest in best guesses and perceived value rather than in achieving business outcomes and actual value. 

To shift this focus, the product needs to be aligned on and measured against the business objectives. An outcome-driven product roadmap can be an effective tool to change the conversation.

The largest difference you will see in an outcome-driven roadmap, as opposed to other roadmaps and plans, is that product features, software designs and architecture are subservient to achieving business outcomes. When done well, the only commitments made are around what the business outcome is, how to measure progress towards it and dates for when specific progress should be made. User needs and desires, in the form of features, are then loosely mapped to the business outcomes. 

The approach to satisfy those user needs is the responsibility of the Product Owner or Product Manager who works as part of the delivery team. The delivery team is incentivized to maximize their resources to achieve the desired results and provide proof, through the measurement of key performance indicators, that progress is being made. 

In this case, the dates hold the team accountable to outcomes rather than releases. In fact, the team may feel like multiple releases are needed to ensure the outcome can be realized.

This is not to say that architecture and technology improvements cannot be central to the plan. However, their purpose is to achieve  a greater business goal beyond themselves by accelerating the release of user value or enabling a grander user need or desire to be fulfilled.

After all, satisfied users drive business outcomes.

The result: Business agility

Outcome-driven product roadmaps take advantage of the knowledge diversity in your organization by allowing the delivery team to determine how best to achieve results with the resources available. This method allows for the freedom to innovate, both in product and in approach, and avoids placing too much emphasis on the delivery of specific features. 

Since it incentivizes achieving actual business outcomes, the implementation of outcome-driven roadmaps leads to other productive changes within the organization, like data-driven decisions, incremental releases and more effective user testing. The result is a higher return on investment, a better product and more control over your success.