2021年3月21日 星期日

讀書筆記| 產品經理必讀經典!INSPIRED : 產品專案管理全書

 


作者為著名的矽谷產品大師 Marty Cagan,擔任許多知名企業的產品教練與顧問。本書以產品經理的視角切入,來聊聊所有與如何打造出好的科技產品相關的議題。


這也是Peggy 第二次閱讀這本書了~還記得,初次閱讀時是 Project manager,第二次閱讀時,工作轉換為 Product manager。

然而,每次的閱讀都帶來一些新的體悟,果然是經典好書!!


誰適合閱讀本書?
  • 產品經理
  • 專案經理
  • RD
  • 任何想了解產品echo system 的人

全書分為五大章節,主要從這些不同的面向來探討與切入。
  • 從頂尖科技公司得到啟示
  • 適合的人才
  • 適合的產品
  • 適合的流程
  • 適合的文化     



/

本書內容蠻豐富實用的,Peggy特別摘錄其中有共鳴或覺得有意思的部分與您分享。

幾個關鍵概念

  • 「產品」:包含功能特色、技術、用戶體驗設計、營利、吸引用戶與顧客、離線體驗(含出貨體驗/退貨體驗等等...) 。

  • 持續的探索(discovery) 與交付 ( delivery) :PM 與設計師每天探索打造產品時,同時間,工程師也在努力交付優質的產品。很多時候,很棒的創新也是出自工程師,而PM 和設計師也會協助交付產品、協助釐清行為。
  • 產品探索需解答這四個重要問題: 用戶會買或用這個產品嗎?用戶清楚怎麼使用嗎?RD 做得出來嗎?Stakeholders也支持嗎?
  • Prototype :讓公司以低廉的成本快速學習與驗證假設
  • 努力追求 Product-Market fit 
  • 產品願景:產品的長期目標,產品組織打算如何達成公司的使命。


優秀團隊主要成員


優秀的產品無法單由產品經理獨立完成,需要一個優秀團隊合作而成!



卓越的產品經理有四大責任


  • 深入瞭解客戶:質化分析是為了瞭解用戶和顧客為什麼有那些行為; 量化學習是為了了解顧客在做什麼
  • 深入了解資料:含銷售分析、使用分析、A/B 測試的結果
  • 深入了解事業:此為最難產出的貢獻,要瞭解企業事業運作方式,了解各利害關係人是誰?以及他們面臨的限制與挑戰為何?
  • 深入了解市場和產業。


卓越的產品經理必須具備的特質:

  • 對產品有熱情
  • 有幫客戶解決問題的熱誠
  • 非常聰明:求知慾高、學得快
  • 創意:另類思考,解決商業問題
  • 毅力:以令人信服的證據、持續的溝通、銜接不同部門的意見衝突、推動公司跨出舒適圈


優秀的產品設計師之重要!


  • 用戶體驗 UX不是單指UI ,而是延伸到「客戶體驗」
  • 把顧客、產品、公司互動一起來整理思考。
  • 優秀的產品設計師以原型作為內外部溝通的媒介,不斷與用戶與客戶進行想法的測試,以評估此創意想法的價值。如客戶會想使用嗎?如果不會,那是因為?
  • 如何和設計師培養良好健康的關係
    • 讓設計師坐在身邊
    • 從一開始就把設計納入創意概念
    • 讓設計師一起了解用戶和客戶
    • 給設計師空間,且鼓勵反覆改進


工程師


  • 對成功的產品經理來說,最最重要的團隊關係就是與工程師團隊的關係了!
  • 產品經理需要先做功課,為團隊帶來深入的知識以及產品管理的技能。
  • 工程師通常都很聰明,且生性存疑。遇到不懂的,最好坦白承認,告訴他們你會儘快了解。
  • 產品經理要公開分享對客戶的了解,customer need/ feel exciting / pain point...
  • 盡量給工程師很多空間和自由,讓他們想出最好的解決方案。
  • 必須持續讓團隊知道自己思想開明、知道如何傾聽,而且想要、也很需要他們的協助來開發合適的產品。
  • 每天上班都需要和工程師直接交流。可能是你針對產品「探索」流程中提出的想法,徵詢工程師的看法和意見 ; 或是是工程師要求你針對正在開發以便「交付」的物件,釐清一些問題。

產品行銷經理


  • 代表著市場定位、傳遞給市場的資訊、上市計劃等等。
  • 他們深入參與銷售通路
  • 通常非團隊專屬成員,而通常按照產品、市場區隔、通路來區分。
  • 從與產品行銷團隊的互動中,可取得和市場相關的有價值訊號。

/

產品路徑圖( roadmap )


  • 典型的產品路徑圖都談產出,而優秀的團隊需要交付的是商業結果。
  • 產品路徑圖:公司要求團隊開發的功能特色與專案的優先順序清單。
  • 通常是每季更新,有些公司是從每個時點展望3個月,有些則是做年度規畫。


「產品的兩個麻煩真相」 


  • 至少有一半以上的創意行不通,原因可能為概念缺乏價值、缺乏易用性、缺乏實行性或商業可行性。
  • 即使某個創意想法證實有價值、簡單易用、開發得出來、商業上可行,通常仍需要經過多次iteration ,才能讓產品足以即時變現(time to money)
  • 優秀團隊成功關鍵在於-因應這些真相的方法。打造prototype,用花幾小時或幾天找用戶、客戶等相關的stakeholders 來測試創意概念,根據回饋進行調整。
  • 問題! 產品路徑圖上的清單都了變成承諾。應有 「高誠信的承諾」 (high-integrity commitment)
  • 路徑圖的2個需求
    • 管理高層希望確定產品團隊優先開發商業價值最高的
    • 管理高層是在經營事業,有些情況下需要給出日期承諾,路徑圖是他們追蹤這些承諾進度的地方。
  • 替代方案:結果導向的路徑圖(outcome-bard roadmap )把上面的項目改寫成「該解決的商業問題」 or OKR



產品經理推銷的十大建議

  • 運用原型
  • 體會痛苦
  • 分享願景
  • 大方分享學習心得
  • 大方分享功勞
  • 學習如何做出色的產品示範
  • 做足功課
  • 真心感到興奮
  • 學會展現熱情❤️
  • 多花時間跟團隊相處呢

/

關於產品探索


  • 精神:迅速實驗及探索
  • 產品探索是為了解決底下這些關鍵風險:
    • 顧客會購買或決定使用嗎?(價值風險)
    • 顧客知道如何使用嗎?(易用性風險)
    • 能打造出來嗎?(實行性風險)
    • 有助於事業發展嗎?(商業可行性)

  • 產品經理需要收集證據,而非憑印象。通常最難回答也需優先評估的是「價值」。

產品探索十大核心原則


  • 不能只依靠顧客、高管或利害關係人告訴你要打造什麼。客戶不見得知道,尤其科技產品,我們常等到東西出現,才真正知道自己想要什麼。
  • 創造必要價值,讓顧客決定購買或使用
  • 工程難、重要但良好的用戶體驗更難,是成敗的關鍵
  • 功能、設計、技術本質上是緊密相連的
  • 許多創意不成功,那些成功的概念通常需要反覆驗證
  • 必須找真正的用戶和顧客來驗證創意
  • 盡可能最快、最便宜的方式驗證概念
  • 先在產品探索流程中驗證概念的實行性,不是之後才做
  • 在探索流程中驗證概念的商業可性,不是之後才做
  • 共同學習很重要
  • 常見需求測試技術:Fake door demand test ,Landing page demand test
  • 量化測試告訴我們發生或沒發生什麼,但無法告訴我們為什麼,以及如何改正那種情況。

科技核心分析工具


  • 用戶行為分析(點擊路徑、參與)
  • 事業分析(活躍戶、轉換率、終身價值、留存率)
  • 財務分析(平均單價、出帳、結帳時間)
  • 性能(載入時間、正常執行時間)
  • 作業成本(儲存、主機託管)
  • 上市成本(收購成本、銷售成本、宣傳活動)
  • 情緒(淨推薦值、顧客滿意度,調查)

謹記在心:資料可以顯示發生什麼事,但無法說明為什麼。我們還是需要質化技術來說明量化結果。


創業圖技術: 創業圖(startup canvas)、商業模式圖(business model canvas) 和精實圖(lean canvas)  幫助凸顯新創事業或現有事業中重要新產品的關鍵假設及主要風險。

/

延伸閱讀>>


OKR

Fakedoor
商業模式圖(business model canvas) 
相關演講


希望以上的分享對需要的朋友們有那麼些幫助,也歡迎討論交流。


歡迎轉貼,禁止商業使用,請註明原文標題、連結以及作者。

2021年3月13日 星期六

讀書筆記 | 97%的輸入都是白費的? !從「最高學習法 The Power Of Input」來學習如何高效輸入,不再無效努力。

 



作者樺澤紫苑,被譽為「全日本輸出量最大的精神科醫師」。
輸出量有多驚人呢? 以下是他的一部分輸出~

  • 電子報:每日發行持續十四年
  • FB :每日更新,持續九年
  • YouTube:每日更新,持續六年
  • 寫作:每日三小時以上,持續十二年
  • 著作出版:每年平均二至三本,連續十一年
  • 新作講座:每個月兩場以上,連續十年

而其輸入相對而言是精簡的 (其實這閱讀量也是蠻多的 XD)

  • 閱讀(只有空檔時間) : 每個月二十至三十本書     
  • 手機使用時間 : 每天三十分鐘以下
  • 網路資訊收集 : 每天十五至二十分鐘 

如此大量的輸出專家,到底是怎樣進行有效輸入與學習呢?

作者在本書介紹包含閱讀術、聆聽方法、觀察技巧、記憶秘訣、說話技巧、資訊蒐集等80個以腦科學為根據基礎的輸入方法。幫助讀者在提升輸入效率,更省時間,進行更有效地學習。

另外本書每章節內都搭配著一些如下圖般輕鬆的插圖,以圖像加深讀者閱讀印象。




適合讀者群:

  • 困擾於難以學以致用
  • 想提高學習效率
  • 想要更有效提升輸出質量的人
  • 看得很多,但卻難以活用
  • 想提高記憶力


以下為Peggy針對其中幾個個特別覺得有意思的主題進行整理與摘要。

  1. INPUT的基本rules
  2. 如何靈活運用音樂有效提升輸入效率?
  3. 怎麼加深記憶力?



/
INPUT的基本 rules

  • 輸入的「質」勝於「量」:進行有意識且專注的聽、說、讀、寫,捨棄「放空地」聽說讀寫
  • 放棄「真正必要的資訊」以外的東西。透過四個方法可以「打開天線」— 列出自己感興趣的keyword(雞尾酒會效應)、確定自己的目的和課題、對自己發問以及以輸出為前提進行輸入。
  • 輸入前先設定「輸出的目標」和「期限」。如,看完電影後,三天內要寫出一篇心得文。閱讀書籍完,在當天要發表心得在自己的FB牆上。

  • 要怎麼閱讀可以幫助輸出? 選出書中的最佳名言閱讀完馬上寫下感想、最大發現,短短的也都很好。重點處做記號或貼上標籤隨手記下想法
  • 最適合輸入的是早上,另外一個好時段是「睡前15分鐘」。輸入後就直接睡覺,更容易幫助記憶。
  • 輸入不只有閱讀,「人、書、旅行」無庸置疑地也是很強大的輸入法。遇到有意思的朋友,何不當場和對方約定好下次的見面。另外,直接去找你/妳覺得「好厲害」的人學習,也會進步更快。
  • 一本書一行動。


如何靈活運用音樂有效提升輸入效率?

先來了解一下自己屬於哪派~


  • 「唸書前」聽比邊聽邊唸書好,快節奏或自己喜歡的音樂會提高幹勁。
  • 一邊閱讀/專心唸書/記憶資訊時,一邊聽音樂,對多數人是會效率變差的;然而,一邊聽音樂,一邊運動或做固定順序/步驟的生產線工作,除了讓心情振奮之外,效率也會上升。
  • 為自己安排各種不同情境的歌曲清單,用音樂控制自己的情緒。上台前、緊張、睡前,想放鬆可聽古典樂。傷心或被責罵時,聽喜歡的音樂可振奮精神。



怎麼加深記憶力

  • 運用大腦機制提高記憶力:伴隨著喜怒哀樂的事件才會留下深刻記憶。隨著喜怒哀樂的情緒,腎上腺素和正腎上腺素、多巴胺、腦內啡、催產素等大腦物質也會跟著分泌,這些都可以增強記憶的作用。
  • 如何刺激感受?
    • 善用故事(畫面、情節)。
    • 重視自己的好奇心,選擇學習讓自己躍躍欲試的東西。
    • 趁著有「好期待看這本書!」的心情時,快快閱讀剛購入的書。
    • 有「不懂」時馬上找答案。
    • 公開演講:藉由「緊張」、「興奮」的心情來增強記憶。
    • 透過電影和藝術欣賞激發「感動」和「學習」。
    • 從旅行(緊張、興奮、感動)中獲得學習。
  • 邊聽邊做筆記,輸入與輸出的黃金比例是7 : 3,紀錄重點就好。
  • 先戒掉「沒事滑手機」和「睡前滑手機」的習慣。
  • 「有氧運動」可有效提升記憶力,如健走、跑步、慢跑、騎自行車、游泳、有氧舞蹈。建議一週兩小時以上。
  • 改變場所可以刺激大腦主掌記憶海馬迴的place cell。作者自己每天早上、下午和晚上,分別在三個地方工作。
  • 七個精煉化記憶法: 
    • 附加:加上背景、意義、事先資料、追加資料
    • 關聯:和類似資訊做對照、比較
    • 換句話說:換成自己的說法
    • 故事化:轉化成有故事情節、有情境和畫面
    • 彙整:整理成筆記、圖表等。建立腦內情報圖書館(曼陀羅計劃表)
    • 視覺化:善用圖片、照片和插圖
    • 自問自答

/


一書一行動~
馬上挑選一兩個自己感興趣、需要或想要的practice來練習練習,相信連續21天後,一定會感受到改變的!

想養成新的好習慣但不知道如何開始,可以試試看「原子習慣」的做法~




歡迎轉貼,禁止商業使用,請註明原文標題、連結以及作者。

2021年3月6日 星期六

學習筆記 | Scrum系列:如何決定開發節奏?什麼是最適當的sprint 長度?

前陣子和朋友聊到敏捷開發與轉型的話題,聊到手邊有經歷過幾個帶全新專案團隊的經驗。

包含團隊一開始沒有跑scrum,到後來團隊很習慣scrum 步調。
這整個過程,回想起來很不容易又很容易。
不容易的是,在緊湊的開發時程中,極度仰賴整個團隊的緊密合作和共識。
容易的是,團隊很open mind,多數成員都願意直接提出問題和進行討論 (雙手合十)。

這段旅程中,也經歷了開發節奏的轉換和sprint 長度的調整,從沒有特意run scrum(POC / idea validation期)-> 5 Weeks --> 3 weeks -> 2 weeks。
趁著還記憶猶新,整理一下當初的背景和當時改變sprint 長度的主要思考決策點,提供給有需要的朋友參考,也歡迎交流討論。


/
以下是幾個sprint 節奏。
題外話,Peggy所使用配合run scrum 的tool 是 JIRA.  



Phase 1 : 5 weeks, 其中一週W0 是Plan & Design week

一開始的sprint 長度怎麼決定的?




在對整個團隊介紹Scrum 概念後,前幾件要決定的事情包含了第一個sprint 的長度。
當時有不少討論,最後關鍵決定點是想和主要合作團隊有一致的步調
因為雙方有不少dependency,在POC 階段其實時有卡卡的感覺。
透過和對方一致的開發步調,比較好抓到何時和對方談需求,大概何時對方可以delivery 給我們。
ex. 大概抓最遲對方Week 0 前,把feature request 和對方提清楚,除非urgent request,一般的需求大概抓五週後on production。
如果對方因為滿載需要晚一些才能給,大概抓十週。大概是這樣的感覺。

在這個階段,我們也定了版號:<Project Name>-<Major Version>-<Minor Version>


在期間每個sprint 結束,團隊都會進行retrospective ,以幫助改善。
以下是其中一次的整理。
很有意思的是,可以看到不同成員間有不同看法。
例如sync up meeting ,當初我們是先訂每週一、三、五。
有成員覺得這個很不錯,同時間也有同事覺得想少一點。



Phase 2 : 3 weeks, 其中前三天是Plan & Design days

在一兩個sprint 後的某次retrospective meeting中,團隊成員提到,五週一個sprint 的步調似乎不符所需。
五週太長了,無法應對中間的需求變動,release 要等五週也太久了。
Week 0 的Plan和設計可能很快就要調整,那預留這設計週就沒有那麼有意義了。
(此時專案尚未建置完整CI/CD flow, 原本是先訂 release 統一在sprint end 上,上之前要經過足夠的測試以確保上線品質)

這時候的討論以及mindset change
  • 討論: Change handling / change management
    • 做法一:sprint 變短 ( 見 action item)
    • 做法二:某些job點數被替換掉
  • Mindset change
    • More aggressive
    • Sync "Dev-Ops" understanding definition
    • "Service" mindset, not "Product" mindset
    • Drive solution by our own! convince yourself firstly

另外,也把sprint name調整成 <Project Name>-<Sprint No>-<Sprint Start Date>  ,以表達更明確的起始日


Phase 3 : 2 weeks, 預留一個下午給 plan & design. 

在Phase 2 原本三週的長度,相較原本的五週,團隊已經較能反應變動的需求。

此時,調整成兩週的主要考量是—協作團隊的步調一致性。

在此時,此專案除了原先合作密切的團隊A外,同時間也融入一個由更多不同的小團隊所組成的公司年度策略大專案之中。

由於在其中的組成團隊數已達兩位數,原本溝通複雜維度暴增,而溝通時程沒有接近的步調和語言又更增加困難度。

經由一陣子的磨合與討論,這達兩位數的團隊的leaders 一起決議,如果沒有特殊考量的話,可以的話,一起盡可能調整成兩週一個sprint ,且共用sprint 的format包含sprint no, sprint start date但還保留前面自己的專案名字。

<Project Name> - <Sprint No> - <Sprint Start Date>


其實一開始對於sprint 長度改成兩週,有點擔心太短,可能會花太多不必要的時間在頻繁的sprint plan/design/review/retrospective等meeting中。

把這個議題帶回團隊中和leaders 一起討論,也決議做一些微調整,迎接兩週的sprint步調。 共識是,先改成兩週讓大團隊間步調一致,成員們在過程中若覺得有不順的、有問題的部分,盡快提出來討論。

中間陸陸續續經歷一些微調整,維持兩週的sprint 步調維持至今。

/


最後聊聊幾個常見討論題⋯ 

FAQ 1: Software delivery 的步調和 sprint 長度有相關嗎? 

Ans: Yes! 正相關!  

FAQ 2 : 一般幾週好? 

Ans: 都好! 適合專案屬性和團隊即可,個人建議五週內。
想要快速一點的交付節奏,或應對快速的變動,可以從嘗試讓它短一點開始。
另外,您的專案和哪些團隊合作?合作團隊的步調為何,也是很重要的考量點。

FAQ 3為什麼會導入 scrum?開始的契機點?

為什麼Peggy會把scrum 導入團隊 daily work 中?
主要考量點是「團隊開發節奏」與「品質」。
之前在POC/validation 期,考量到團隊還在成型與磨合中,保持開放和彈性。很多時候,有idea就可以先 POC 一下。
到一段時間後,確認是對客戶有價值的,將會是公司正式的Service,Peggy就開始思考以下這些議題。

怎麼讓整個開發更有節奏?
如何R&R可以更清楚?
如何Delivery 更有品質?
...
這時候,導入scrum 就是一個好的時機點啦! 


以上為Peggy 的專案經驗和觀點,歡迎交流討論。


歡迎轉貼,禁止商業使用,請註明原文標題、連結以及作者。

Peggy的實驗空間| 小書庫 Index card ( 讀書筆記總目錄/書單 )

  一直很喜歡閱讀,也常從閱讀好書中與讀書會得到許多的力量與啟發,不管是在人生的低潮抑或是順遂的時候。在閱讀之路上,這幾年也保持一個習慣。當閱讀到喜歡的書籍,且那陣子時間允許,就會提醒自己閱讀完後整理出心得筆記。一方面藉機鍛鍊寫作肌肉與思路,方便之後的複習和查閱。另一方面,也可以...