It is better to do the right problem the wrong way …

The most important thing I learned in Amazon is to find the right problem to solve. Amazon has a deep operational excellence and data driven decision making culture. Once a right problem is found, through iterations and fast feedback loops we tend to get the solution better and better over time. But why starting with the “wrong way”? If you look at any software products, deep inside, you will find things that were done in the “wrong way”. I used to think, “if only we knew better, we could have …” But gradually I realized, these “wrong ways” might be necessary in the journey. If you have a brilliant idea, getting it into a product to deliver customer value as soon as possible is the most important thing, making it into a MicroService is not important. In fact, some seasoned engineers even advocate building your first version NOT to scale. The KMS we launched 8 years ago could not scale as the KMS we use today. If we built KMS to support millions of transactions per second 8 years ago, we would never have launched KMS. We would still be working on fictitious “engineering problems”, that no customer really cares about. Do the right problem the “wrong way” allows us to get feedback from customers quickly, so we can start iterations quickly. But how do we find the “righ problem”? Amazon uses a working backwards process called Press Releare/Frequently Asked Questions (PR/FAQ). When we have an idea, we pretend the idea has been turned into a product already and we are writing a press release, where we need to articulate 1. Who would be delighted by this launch? 2. In what specific way? 3. Can we measure the difference? 4. What would the customers say specifically? We want quotes from very concrete personas, not abstract “customers“, but real person’s comments about how the launch improved their life. You may say “yeah I know PR/FAQ, product managers write that a lot”. But in KMS, we also ask engineers to write PR/FAQ. Their projects’ customers may not be end users of AWS. The project might be an operation automation to reduce on-call workload. So on-call engineers are the customers. Regardless who are the customers, a PR/FAQ helps us articulate what result of the project will benefit at least one customer. It is easy to love human race, a lot harder to delight “one concrete customer”. PR/FAQ forces the writer to practice empathy: the ability to understand and share the feelings of a customer. Once we convince ourselves we are solving the right problem, we use a one-way-door-two-way-door mental model to call out 1. things we need to slow down and get it right at the beginning - these are one way door, we’d better think it through. For example, encrypting your PII data is a one way door decision. 2. things we should be biased for action, fail fast and iterate - the two way doors. Are you solving the right problems? Maybe you should write a PR/FAQ.