Thread by @stevesi

"Working Backwards" is a very good book for product leaders to read. It builds on 6 core Amazon principles AND tells the story of 4 key amazon projects. Written by @cbryar (12+) and @BillCarr89 (15+ yrs) of Amazon. 1/ smile.amazon.com/Working-Backwa…

2/ My normal caveat is that I tend to like books that tell the story and tools a company used but don't try too hard to tell you that you should do what they did or "use these tools". I'm hardcore about this because I think context, domain, and people make all the difference.

3/ I've seen far too often business leaders adopt the low-friction/readily adoptable part of such expressed lessons, and then get frustrated things don't work. I've even seen this happen when one part of Microsoft tried to lift parts of what another team did.

4/ This is especially the case when there are specific "artifacts". I've seen this happen with my book "One Strategy". That should be a caution not a reason not to buy and enjoy this book.

5/ The 6 chapters of Part I go through some of the essential elements of "being Amazonian". I think each of these are the key aspects of any well-run org with solid descriptions of why/how/what. I walked away feeling they did a great job saying "do this, not that" so here you go:

6/ 1) Leadership principles written down >> Mission statements. Writing down "how" the company should operate is a great way to approach versus writing down the goals of the org. Amazon has expanded and iterated a bit which is discussed.

7/ 2) Bar raising >> hiring manager. No surprise given common ancestry but the idea of having a core dedicated group that owns hiring decisions versus relying on a hiring manager (with the opening) is superior. Microsoft called this "As Appropriate" and is discussed.

8/ 3) Single Threaded Leadership >> generalists. What I really appreciated about this book is how it is a bit of history "myth busters". This chapter busted the "two pizza" meme. It was an idea, but it had problems and didn't scale and led to "STL" & "no one uses term anymore".

9/ That leads to basically Functional Org >> Unit org, which is also confirmation bias. The ability to scale common services used across a company requires more than 2 pizzas and requires collaboration not isolation. BTW, I was often accused of being single-threaded so ❤❤

10/ The role APIs play is very interesting and the "re-wiring" of Amazon this way is a great lesson shared. They talk about APIs as tech and as a culture. It takes a longer time dimension to see this play out which will be interesting in years.

11/ 4) Word >> PowerPoint. Sure I'm happy they are using either one but of course I love this point. It is interesting how much Tufte influenced them and a well-known article that triggers me to this day. This is an artifact ripe for misunderstanding though so see caveat.

12/ Many people I know at Amazon talk about how this process has evolved and like anything, it has definitely evolved. For me, lessons about how a process evolved are as interesting as the process itself since everything has "problems".

13/ 5) working backwards >> starting at the beginning or with intermediate goals. Chapter explains the PR/FAQ (press release, freq asked quest) process. I love love this. Strong confirmation bias since we used press releases going back to Office 97 (so did xbox).

14/ Every product release should be built this way. There's no doubt about it. There's also a lot to how to do this right/well so it is not just copying an artifact. Interesting was so much up front work but not a "did we build it" so PR/FAQ crossed with experimentation. 🤔

15/ 6) Inputs >> Outputs when it comes to metrics. I love love this. Again there's confirmation bias in this one for me as I definitely used this and it created many tensions. Managers should focus on what they can control.

16/ Lots of good discussions about how confused and difficult so many things get when people are measured on things they are not actually able to impact. There's a dismissal of "competitive" v customer thinking which is interesting in context of Kindle, PrimeVideo, later on.

17/ Part II tells the story of Kindle, Prime, Prime Video, AWS. My favorite kind of business writing is when those who experienced a product delivery write their first hand experiences and this does not disappoint.

18/ Each of these products was innovative and/or transformative in their own way and first hand accounts are the best way to understand what was going on.

19/ Also be prepared for the fact that these accounts are so accurate that they show the 6 main principles aren't exactly the process that got used. That is ok, in fact great. It really shows that the company wasn't a slave to a process for innovation.

20/ My favorite "myth busting" was of course the AWS story which is normally told as "Amazon needed to scale so it built AWS". Rather some folks loved XML and released it and "wow" (I wrote a DVD library bar code scanner in VBA Excel)

21/ And then started building out a data center so more people could do those kinds of tools without buying servers and so on. The PR/FAQ process here showed diving into issues of pricing which was equally innovative.

22/ Super fun stories and each can be taken on their own as worthwhile. In many ways I would have appreciated more depth on these stories as I tend to think lessons come from the journey of products more than the artifacts of process. That's me though :-)

23/ Something I think all books from big companies should explore more is "how did existence of crazy strong Product Market Fit impact decisions"? Where would Kindle have gone without attach to existing book biz (eg Sony)? PrimeVideo absent Prime is discussed.

24/ Like Google, Amazon could build out many products loosely connected to a wildly strong core business. (Oppty) Cost of developing/releasing is low & material cost of failure low. That reality drives lots of process/choices. Not every company can do this nor can a core product.

25/ I think product leaders could easily use this book as a springboard for discussion about evolving processes within a team. It provides a solid foundation with lessons derived from first-hand experiences (in creating and using processes). 👍👍// END