你的產品是為了實現自己而做，還是為了成就用戶？－《使用者故事對照》

2022 / 09 / 09

藉由一頁閱讀的機會，我用最小努力原則想看之前看過的書，老書新看也蠻有趣的～

這本《使用者故事對照》應該是在 2018 年買的，看了覺得驚為天人，是奠定產品開發觀念的重要工具書。雖然裡面都是談軟體開發，可是用語一點都不艱深和抽象，超級口語而且比喻很生動、實際案例也很多，文科生也能輕易踏進來。推薦任何工作跟產品有相關的朋友，家裡一定要有這本書。

這本書所推崇的產品開發策略就是從最小 MVP 開始，作者的定義是「最小可行產品是你能夠建立來證實你的假設為真或假的最小產品釋出。」作者用建造一台交通工具當例子，認為錯誤的產品開發策略是先交付一顆輪子、再交付四顆輪子和底盤、再交付四顆輪子底盤和坐墊，最後交付出一台完整的汽車；也不是推出一個差強人意的劣質產品。

而是先交付一個滑板、再交付一個滑板車、再交付出一台腳踏車或摩托車，最後交付出一台完整的汽車。

為什麼？

作者認為每個釋出的版本都應該當作一次「實驗」，在每一次的釋出都要設定「假設」，因為可行的產品才有機會被消費者所採用，有推出市場才可以實際去驗證產品的目標客戶、使用體驗，從一次一次的驗證中獲得使用者的洞察，在下一次的交付時再把學習到的想法融入下一次的交付。

這樣的好處是，每一次交付的產品都有解決某些使用者的問題（也與我們設定的假設相符），有解決問題的完整能力，才可以稱之為產品。

另外，對於產品開發的時間和風險也相對可控，尤其是那種尚未經過市場驗證的新型態產品，特別需要不斷在批評與指教中迭代成長，而無法直接從構想躍進到產品，一來可能時間太長，二來難以預測上市後的評價，對公司可能會有致命的危機。

我發現是「專案」與「產品」兩種很不一樣的思維，若用執行專案的方式來做產品，會有極大的落差。因為專案思維比較關注流程和交期，通常已經是相對成熟的概念或是已經被驗證過的想法，可以用專案管理的方式把它實現出來，將專案內容切割成許多不同職能的模組，彼此分工合作，每個人在設定的時間內交出成果，最後等專案上線，專案也差不多到收尾階段；而產品思維更關注使用者所要解決的問題，通常在產品上線之後，往往才是挑戰的開始，因為永遠沒有最完美的產品，只有不斷在變化的使用者，為了讓產品能長銷，產品經理會需要投入很多精力研究使用者的回饋和行為。

產品思維會灌注很多產品經理的精神，專業項目涉及的面向也很廣泛，基本上從開發到用戶，一條龍什麼都要懂一些，才能生出有血有肉有靈魂的好產品。

P.59「先針對整個佈局繪製草圖其實是比較好的做法，藉此方式，我能夠把比例弄正確，並且調整動物的姿態，甚至可能重新構思我要畫什麼。」

一個可交付的產品，我認為最重要的成敗關鍵，是產品經理所設定的「假設」，就是這項產品到底要解決什麼問題？所以釐清問題本質的能力是一個產品人的核心。

我目前在公司也是在做數位學習內容，但是同時要滿足給客戶、又要滿足給全球經銷商、又要滿足內部員工，所以在釐清每一段的問題時有點複雜。

給客戶的偏重商務關係，我們希望客戶買我們的設備，同時又希望他們買我們的數位課程學習設備知識和技術，內容要能讓他們看懂會操作，但又不能透露到太深入的 know-how，且各國客戶的環境因素又不同，深度、廣度和差異性的拿捏很重要；

而給經銷商的偏重服務品質，因為經銷商的能力直接影響到公司的成長，所以內容要及時且完整，同時又要尊重每一個經銷商內部的流程與文化，給予訓練只能談大原則和方向，所以服務態度要兼顧；

最後是內部員工，希望做到訓練完就能上手工作，所以一堆繁複的流程、工具和職務細項都要理解，但又要評估這些流程會不會常常變動？這些工具會延續使用多久？這是個人應該自帶的專業？還是需要公司教育的範圍？規範太細會不會侷限人員的新創意？太粗會不會太抽象不夠具體？不擔心同仁不學（因為公司規定），但要怎麼達成學完可衡量提升了工作績效？

最可怕的是，同一套內容要想盡辦法最大化使用者範圍，也就是適用不同客群、不同國度和不同的目的。可想而知，這樣會是效益最高的內容產品（標準化），可是當中各種因素的權衡利弊，真的難到爆炸。

而且，當我以為我懂了的時候，又會出現新的商務合作模式，我要重新思考這種類型的對象該怎麼解決他的問題。

總而言之，問題只會不斷地變多，但是沒辦法等我全部想清楚再推出產品，所以就很需要這種產品策略的幫忙。

P.60「我們永遠能夠精益求精，然而，在某個時間點，我們必須交付產品，而達文西和許多其他藝術家的作品都是很好的例子，我們（欣賞作品的人）根本不知道它被放棄了，對我們來說，它看起來就是完成的作品。」

內容產品真的很像藝術品，無法被工業化模式標準製造，只能仰賴每個藝術家（產品經理）持續擴充自己的想像和內在能量，把自己作為一個工具，才能源源不斷地生產、提煉出更棒的產品。

思想萌芽時刻：

1. 不只是軟體開發，做任何事情都應該套用最小 MVP 思維，關注使用者體驗和風險控管。
2. 釐清提供給使用者的項目之目的，和解決之問題，就可以事半功倍，因為或許只要提供最小 MVP！

• 書籍：使用者故事對照：User Story Mapping
• 作者：Jeff Patton
• 出版社：歐萊禮

【 每天一頁閱讀 // One Page A Day Challenge 】

隨手翻開一本書中的一頁（封面、目錄、資訊頁不算，序文、內文都可以！），針對裡面的內容詳讀和思考，然後用隨筆的方式紀錄下自己的心得，不限字數，心得可以只有狀聲詞和顏文字 XD

1. 文中 #一頁閱讀
2. 公開貼文不強求，但公開的話可以讓參加的朋友互相交流！
3. 附上書封和那一頁的照片
4. 為什麼今天選了這本書？
5. 寫下隨筆心得
6. 重要：每天一頁！