"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
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Why were word processors $500+ in 1980s (~$1300 2021)? Aside from "seemed right" the packaging and contents were expensive. Here's a leading WP MultiMate. It came with several books, reference cards, keyboard templates, backup disks... The box is a fancy cloth storage box. 1/
2/ Companies were not just teaching their product but had to explain how a PC worked. The "Beginner's Guide" literally explained how a PC worked? Why, because often people were buying a PC to run one software product. How do floppies work?
3/ Products were enormously complex to use. It often took weeks to become kind of proficient. Mostly because usage meant learning essentially arbitrary keyboard "chords". MultiMate was famous for *stickers* you'd put on your keys (talk about commitment). (tough to find these!)
2/ From the earliest days the company was uniquely focused on a breadth product line, and only on software. Those were both unique compared to single-product companies or to the vertically integrated likes of IBM captured by this classic video (c. 1981).
3/ As technical assistant I was there to help with product reviews and serve as a form of connective tissue or glue between product groups executing on Bill's vision. In 1993 Microsoft just launched the 'year of Office' and had started the pivot from apps to the suite.
A topic I end up talking about quite a bit is how org structures evolve. In today's "Hardcore Software" I discuss origins of Microsoft's two main cultures--Systems and Apps. "018. Microsoft’s Two Bountiful Gardens" in Hardcore Software on @SubstackInc…rdcoresoftware.learningbyshipping.com/p/018-microsof… 1/
2/ Mike Maples Sr (then head of all World Wide Products) explained the origin of each culture using a folksy story about "two bountiful" gardens at Microsoft. Apps was 58% of revenue but Systems was top of the food chain, so to speak.
3/ Many are familiar with this image of different tech company org charts. It always drove me bonkers because I felt it did little to understand how or why companies are structured like they are and presumes it is just lunacy. Yes, I get it was to be funny.
Climate of 'fear' prevents experts fro questioning the handling of the pandemic. express.co.uk/news/uk/141589… // this is super interesting and not at all obvious for a true pandemic in a democracy. 1/
2/ WHO has studied pandemics and worked tirelessly for decades in many countries. They serve in an advisory capacity with varying degrees of involvement depending on country. Lots of history going way back, smallpox, HIV, flu, ebola, SARS, etc.
3/ In 2008 a few years after SARS they published an updated Outbreak Communication and Planning Guide. apps.who.int/iris/bitstream…
016. Filling the Void Left by IBM …rdcoresoftware.learningbyshipping.com/p/016-filling-… // Over 5000 have signed up. Please join in, it is great fun. Many stories--history & strategy. Microsoft is transitioning to enterprise products and building "Chicago", oh and the internet.
Also, my first exec offsite.
2/ The offsite was the first time I was at a meeting with a bunch of executives from across the company. There were 9 execs out of the 25 or so worldwide at the company at the time. Attending scored us a wonderful acrylic block. Microsoft loved acrylic blocks.
3/3 Our breakout had to come up with an answer to "Filling the Void Left by the Demise of IBM" which was days away from insolvency and will appoint a new CEO the following week. This was the earliest days of Microsoft's transition to selling enterprise as discussed. Weird slide🤣
Just posted "Every Group Is Screwed Up" in _Hardcore Software_. This is my interview with billg to become his technical assistant. 👇that's the old fountain you could see outside from our office windows. 1/ …rdcoresoftware.learningbyshipping.com/p/015-every-gr…
2/ Check out the post for the adventure (including me humiliating myself). The most interesting thing though was how the previous technical assistant warned me about the job.
Also, he told me to start looking for my next job right away!
3/ He told me that every group is "screwed up" and that becomes readily apparent as you cycle through meeting after meeting. Projects are late, buggy, missing features, and more. I was intrigued by the idea everything was messed up.