Amazon, Day One, Working Backwards
最近讀了些跟 Amazon 有關的書。首先是《Invent and Wander》這本整理了A 社每年股東信跟 Jeff Bezos 某些演講內容的書。股東信以及演講都是公開資訊，有些要點或哲學也多散見於各種地方，但一次讀完還是讓人印象更為加深。有兩點是最有趣的： Day…
最近讀了些跟 Amazon 有關的書。首先是《Invent and Wander》這本整理了A 社每年股東信跟 Jeff Bezos 某些演講內容的書。股東信以及演講都是公開資訊，有些要點或哲學也多散見於各種地方，但一次讀完還是讓人印象更為加深。有兩點是最有趣的： Day One 文化、以終為始。
Day One
從第二封信起，Bezos 每年會附上第一年的股東信，藉以取信股東 Amazon 的信仰從未改變。除了這件事外，每封信的最後一句也必然告訴股東「我們仍在第一天」。若僅是宣稱自己不忘初心，其實與廢話也相去不遠，而後來的某封信他又解釋了那份「初心」指的還包含哪些、以及他認為可以怎樣防止公司進入 Day 2。
Such a question can’t have a simple answer. There will be many elements, multiple paths, and many traps. I don’t know the whole answer, but I may know bits of it.
我自己還挺喜歡這種態度，至少我是講過類似的話。畢竟，世間的真理我們怎麼可能詳盡參透呢？了解一點夠用了，半部論語都能治天下。另一方面這也提醒自己：必然還有事情我沒有看透。
已經有別人整理好還翻譯完了信件內容，在此就不多談，有興趣的夥伴可以參考之。切記：詮釋在個人。
以終為始
A 社以終為始的產品企劃手法算是挺有名的，我後來才知道他們把這稱為「Working Backwards」。表象上，這個手法先從新聞稿著手，琢磨出產品誘人之處後，再進行細部的規劃與開發。
看起來好像很容易淪為嘴砲？我相信對某些人來說也許是的。但既然大家都是認真的產品經理，應該還不至於如此。那麼如果認真對待，要產出這套方法所求的合格「新聞稿」其實也沒那麼簡單。我覺得比較麻煩的包括：
- 必須簡要地以普羅大眾能懂的話語，說明這個產品的價值所在；當中包括使用者現在遇到的問題，以及該產品怎麼解決問題。要真的寫好這段，大概產品願景什麼的也都已經有點雛形。
- 模擬客戶證言。要寫好這段，應該是腦中已經模擬過一些狀況，搭配對使用者的了解，才比較能寫出言之有物、連自己都相信的模擬證言。
上網搜尋了一下已經很多人談過這套方法，我另外還找到日本 Amazon 前公關負責人所撰寫的《Amazon 故事公關行銷學》，就去借了。不過很可惜，也許因為我已經對於大部分的東西都略有所聞，這本書對我來說的價值不是很高，且各種要點也有點雜亂… 似乎並沒有滿足其書名所打算提供的價值 :/ 個人覺得如果你也看過了 Amazon 股東信，那網路上找找 Working Backwards 這套方法，了解一番也不差太多了。
但無論如何，我稍稍整理了書裡（跟我所看過的其他資料中）關於那份新聞稿的要點，圖片節錄如後。其中「附錄」其實可能包含了 mockup 等產品開發上的詳細資料，我只是一筆帶過，另附上一些連結給你參考。
Working Backwards，以終為始。我一直覺得世界上很多道理是相通的，只是換上不同名字、在不同情境下而有不同面貌。你說以終為始的想法是否跟以使用者為中心設計、User Story Mapping、測試驅動開發等等的理念有相融之處呢？
我覺得是的，我也一直這樣看待這個世界。
其他參考資料
關於 Working Backwards，A 社 CTO 在 2006 年就開示過簡短的版本。即使這是最簡短的版本，其實已經可以看出抽象的核心。
A 社 Alexa 的前總監在 Quora 的答客問，比 CTO 的版本更詳細些
也有人做過中文的介紹
另一方面，參考在 Amazon 工作的朋友證言，我相信這套手法認真推行一定有其優點。不講別的，連 Amazon 離職員工都還按照這種手法寫了一篇平行世界裡 AWS 成為獨立公司的新聞稿
留言
留言透過 giscus 存在 GitHub，用 GitHub 帳號登入就能留言。