Working Backwards to Move Forwards
Agile is a highly effective tool for product development, especially software-driven offerings. But as companies expand its use into new areas (budgeting, talent management), agile is too often used an excuse to avoid careful planning and preparation.
The idea of “agile” thinking or innovation, along with its close cousin “lean,” has spread far beyond its product development and manufacturing roots. It’s not uncommon now to hear about the agile approach to budgeting, talent management, or even running a family meeting.
Agile is a powerful process for product development, but are organizations are taking it too far?
How Agile Companies Get Ahead of Themselves
Agile might seem perfectly suited for when a company is developing a product or service that doesn’t exist and is looking to move quickly. In these cases, it’s difficult to simply interview customers or watch them in action, because they can’t respond to a hypothetical product.
The solution is to develop a prototype, or minimum viable product. Through a series of sprints, a team puts together something that’s good enough to show customers and get their reaction. If the idea bombs, well at least the team got that information quickly and with only a small investment — and maybe they’ll uncover a better idea in the process. If it gets traction, then the team can quickly iterate to create an even better product.
Speed Isn’t Everything
The fundamental problem with agile, as many companies use it, is its relentless pace. How is that a problem? Often, they want to get out a minimum viable product in only a few weeks, so they skimp on scoping out just what the product should accomplish. Or worse, they compromise by curtailing their ambitions on the product. Instead of a major breakthrough, they tend toward only incremental improvements on existing offerings. The developers haven’t had time to do their homework and prepare something that’s truly valuable.
The team tells itself that whatever information they get from the MVP is still valuable toward some future breakthrough product. But that future rarely comes. Too often, the process of delivering an MVP becomes the main thing, and the team never gets the time and space to step back and obsess over what is needed to truly delight customers. Teams think in bite-sized chunks and there’s no time for the careful thinking that breakthroughs require.
The new approach
Contrast that with the working backwards approach, which is all about planning. Working backwards emerged in 2004: Amazon’s e-commerce strategies had proven successful, and the company was aggressively seeking new opportunities with a large potential market. Where should it look?
Rather than jumping into developing a plausible product — what an agile mindset might encourage — the company preached going slow to go fast. The focus became preventing teams from moving quickly into coding without clearly defining the customer problem and an elegant product solution.
The working backwards approach requires a fully realized vision of a proposed product, embodied in a written press release for the product’s launch. This felt wrong, even unnatural, to software developers and product managers who wanted to get going on coding already. Teams typically spent weeks, if not months, hashing out this press release — along with an FAQ that explained to colleagues, customers, and senior management how they could create this wonderful offering at an affordable yet profitable price. Only when the executives were satisfied with these documents could anyone start writing code and actually assemble the product.
To this day Amazon works backwards from what it thinks will delight customers, even if it currently lacks the capabilities to make that product.
Agile proponents worry that a working backwards approach takes the authority and urgency away from teams to launch new products, get feedback from customers, and iterate rapidly. But speed isn’t everything, especially when it comes to breakthrough products. Continually releasing an iteration of a product doesn’t necessarily mean you are making progress. By working backwards, you can actually get a successful product to market faster.
How to Make Agile Work Better
I am not arguing that companies should throw agile out the window. It’s still a highly effective tool for product development and even business management. Many of its principles and processes have been used successfully by Amazon and other companies. After all, most product development involves only incremental changes. You don’t need a lot of thought around these improvements. Just put together two rough alternatives and try them out in the real world, where you’ll get vital feedback.
Teams with breakthrough products can benefit from agile as well, once they’ve done the kind of advance work involved with the working backwards approach. When you’re in the coding and product construction phase, you want to move quickly and avoid getting bogged down. Sprints keep you on track and ensure that you actually get something to market.
The best solution, then, is to combine agile with something like working backwards. Amazon, for example, has learned to use the working backwards process for idea development, but then follow agile to build and ship the product. If a giant like Amazon can switch course like that, then even start-up companies can follow suit.
For more information on this topic, read Working Backwards: Insights, Stories, and Secrets from Inside Amazon by Colin Bryar and Bill Carr
