Someone once asked Jeff Bezos, “Is the Working Backwards process optional? It sounds great, but it seems like a lot of work.” His answer was,” Done correctly, it is a huge amount of work. But it saves you even more work later. It isn’t designed to be easy; it’s designed to save huge amounts of work on the backend and to make sure that we’re actually building the right thing.”
Basically, Jeff’s answer was “Yes, that’s the point.” The Working Backwards process may be a lot of work upfront. Still, the investment pales in comparison to the months or years and the money spent building, producing, and marketing a product that doesn’t solve a meaningful customer problem.
The Working Backwards process is time-consuming because writing PR FAQs, conducting meetings, iterating, collaborating, and researching answers to challenging questions all require significant time and effort for teams and executives.
Many people wonder why they should do all of that work instead of just building with agile methodologies. In fact, many people think that agile methodologies advocate as little upfront work as possible so that you can build, launch, get feedback, and iterate as quickly as possible.
However, this is not the case. In theory, the agile process requires you first to determine your MVP (minimum viable product). The ‘v’ in MVP is a loaded word. It means the product will lead to a viable, successful business.
In my experience, many companies focus on speed to build the “minimum product” and spend very little time documenting, iterating, or even conducting a cursory review of the plan for the product with CXOs. There is little to no process for researching, debating, and evaluating the product’s viability.
The Working Backwards process is a method for evaluating and determining the minimum viable product without skipping the “viable” part.
The process is not a prescription for how you should build the product described (lean/agile, waterfall, prototype, etc.); it is a process for evaluating many new product ideas and deciding which to build. But the process insists upon a level of fidelity, detail, iteration, and CXO review that yields high-quality decisions.
In other words, the PR FAQ process and the lean-agile approach can be used together with great success. One is not a replacement for the other. At Amazon, we employed various methods in software development, ranging from lean and agile to waterfall, depending on the type of product being developed.
The upfront time spent in the Working Backwards process will help identify the MVP, and then an array of different methodologies will help build it.
(cont. in comments)
