Amazon.com, "Working Backwards" and the Benefits Dependency Network

Earlier this month I read a very nice article, written by two former Amazon executives, presenting a very balanced and pragmatic perspective of agile and its application. Titled “Have We Taken Agile Too Far?” and published as a digital article in Harvard Business Review, Colin Bryar and Bill Carr argue that while Agile can provide a powerful approach for product or service development, many organizations are using agile as an excuse to avoid careful planning and preparation. Essentially, what they suggest is that there is a time and place for agile. I can’t imagine anyone disagreeing with this?

In the piece, they present the idea of “working backwards” which, as they demonstrate, is all about planning. This concept emerged in Amazon in 2004, just as the company was aggressively seeking new opportunities on the back of its e-commerce success. The key question confronting the leadership team at the time was where should it look next? The authors note that “Rather than jumping into developing a plausible product — what an agile mindset might encourage — the company preached going slow to go fast.”

At Amazon, the working backwards approach requires a fully realized vision of a proposed product or service, embodied in a written press release for the product’s launch. Teams could spend weeks, even months, writing this press release — along with an FAQ that explained to colleagues, customers, and senior management how Amazon could create this wonderful offering at an affordable yet profitable price.

Seemingly this practice has stuck and continues to be used at Amazon. The company works backwards from what it thinks will delight customers, even if it currently lacks the capabilities to deliver the value proposition.

This got me thinking about some of the research work I did with colleagues many years around the realization of benefits from IT investments. Similar to the Amazon concept of “working backwards,” we also placed a strong emphasis on working back from business outcomes before beginning any project. To aid this process for IT investments, we developed a mapping tool called the Benefits Dependency Network or BDN for short.

The BDN seeks to map out what it will take for the proposed IT investment to be a success. This begins by understanding the key business drivers behind the proposed investment, the objectives being set for the investment, and the expected business benefits. Although articulating these might appear as an easy task to accomplish, my experience is that it can often be extremely difficult to get consensus on what might seem as something that should be obvious.  

From here, the next challenge is actually figuring out how each of the expected benefits will be achieved. This requirement is based on the premise that IT has no inherent value and just buying tech doesn’t automatically confer expected benefits. Benefits have to be unlocked and this is achieved through change (or “transformation” in today’s language). We advocate identifying precisely what these changes will entail and how the capability of technology will enable or shape them. If getting agreement on drivers and objectives is difficult, identifying required changes always takes much longer than expected. While the idea of identifying changes and mapping them is in no way intellectually challenging, it can be incredibly difficult to do.

But think of the alternative; if you are struggling to understand and map out what it is going to take for the benefits to manifest – and the investment deemed a success – how can you expect them to automatically happen once the systems goes live?

If you would like to know more about benefits management and the BDN, I wrote an article “A Tool to Map Your Next Digital Initiative” that was published by Harvard Business Review some years ago. The link is here: https://hbr.org/2016/06/a-tool-to-map-your-next-digital-initiative