Three complementary practices from Amazon to introduce to your agile product development process
This was the sixth edition of the Velocity Agile newsletter. If you like this article, subscribe to learn how to improve your agile delivery through examples from LEGO, Porsche, Amazon and many more, completely free. Click this link to subscribe.
Too many business books look at strategy, and too few study execution. The execution of a strategy separates the good companies from the great. Arguably the best company ever to exist in terms of execution of strategy is Amazon. This is why Working Backwards is an incredibly good read, given the level of detail Colin Bryar and Bill Carr give in how things get done — not just in theory, but with concrete examples to back it up.
The title of the book is a very simple idea — work backwards from the customer experience when creating a new product or service. But the three practical ways the authors provide that this is brought into the product development experience are fascinating, and I believe applicable to all Scrum teams. I hope you find them useful too.
The PR/FAQ lies at the centre of the product development process at Amazon. The format where new ideas are presented is an imagined press release launching the product. This needs to include everything about the product, including details such as quotes from customers and pricing. There must also be an FAQ section that captures key questions for both internal and external stakeholders. This PR/FAQ is approved by leadership before any development is undertaken to ensure there is a valuable customer proposition before money is invested in the project. This process of PR/FAQ refinement can often take many months.
This is a very anti-typical product development process in agile — often we start and figure out the customer value as we go. Amazon takes the opposite approach, separating defining the customer experience before development to allow development to progress extremely quickly. It’s something to consider for Scrum teams.
Single threaded leadership
A brilliant quote from Working Backwards is “the best way to fail at inventing something is by making it somebody’s part time job.” As Amazon grew, they often needed a mix of teams to get projects done. They tried to resolve this with better communication and planning to ensure dependencies were managed. They eventually realised that was not the solution — the solution was single-threaded leadership, meaning a single person with a team to execute the project independently. This required the painful process of removing all dependencies.
Amazon’s single threaded leader doesn’t exist as a role within the agile product development process. As teams own an area of the product, often coordinating projects across teams is a challenge — solved by scaling agile frameworks and interim TPM type roles. Amazon offers an alternative approach by aligning project and product structuring — albeit at great cost in terms of removing dependencies.
Metrics — leading not lagging indicators
A fascinating aspect of Amazon’s approach is their obsessive focus on leading, not lagging indicators. Working Backwards outlines that measurement of lagging indicators such as revenue or profit is easy, but finding the right leading indicators that drive those lagging indicators and are under your control is the challenging and valuable part. Given these are so hard to define, they are often more complex and therefore require better analytics capabilities to track.
For example, when looking to increase the range of products available at Amazon, the team began by simply tracking the number of items available. However, what’s the point if no one views them? Once they started tracking page views, the item also needed to be in stock! The team eventually settled on the leading indicator of the “percentage of detail page views where the products were in stock and immediately ready for two-day shipping”. This level of detail in leading indicators really sets Amazon apart from competitors.
How do you track leading indicators with your product development process? Whilst its common to do some tracking, Amazon’s obsession to find something controllable that affects customer behaviour is something all product development teams can focus on.
I’ve started to investigate adding these methods into my teams at Babylon, and this different way of thinking has already reaped rewards. Let me know if you use any of these techniques and find them useful.