How to Build Strong Product Teams
如何打造強效產品開發團隊？團隊的十項關鍵原則、組成與職責
「INSPIRED — How to Create Tech Products Customers Love」讀書筆記（2）
這本書第二部分作者來談談設計團隊的組成、運作原則、以及其個別職務內容。
Principles of Strong Product Teams
- 充滿熱誠：團隊有兩種類型，一種是聽命行事。一種則是擁有使命感，真心相信公司願景，並努力解決顧客的問題。
- 團隊組成：主要有一位產品經理、一位設計師、二到十位工程師。另外可能還會有產品行銷經理、自動測試工程師、使用者研究員和資料分析師。有些更大的公司，還會有交付經理（Delivery manager）。
- 團隊授權與責任感：給予明確的目標，然後讓團隊自己決定達成這個目標的做法，亦讓他們自己為最終結果負責。
- 團隊人數：以八到十二人，兩個比薩可以餵飽團隊為原則。
- 團隊報告架構：設計師、工程師、產品經理各自還是跟各自部門的主管報告。記住一點，產品經理並不是團隊的上司主管。
- 團隊合作：不應有階層關係，大家就是很單純聚集在一起，想要共同解決一個很難的商業問題。
- 團隊工作地點：最好可以坐在附近，自然而然就會有比較親近的關係，可能會一起吃午餐等，比較容易建立團隊感情。
- 團隊的工作範疇：每個團隊應該負責什麼可以由兩個面向決定，一個是工作類型（專案、功能、修 Bug、效能運作、最佳化、改內容），另一個則是工作範疇（每個團隊負責一個比較小但有意義的產品經驗，例如：臉書的話可能就是分成動態牆、好友…），新創公司還很好分，但大企業就複雜多了。也還有其他切分的方式，用可以用不同顧客、裝置、顧客旅程分，但作者指出，沒有一個完美的切分方式，哪一個對你比較重要，你就怎麼分。
- 團隊持久性：團隊可能合作好幾個月到好幾年都有可能。只要團隊更認識彼此，在一起合作久了，工作就會越順暢。而且有些議題，就是需要時間累積足夠的專業，才能迸發創新。
- 團隊自主：讓團隊有最大限度的自主權，以他們認為適合的方式工作，去解決問題。
The Product Manager
作者指出，通常產品經理有三種工作方式，而只有第三種才是成功關鍵。
- 產品經理可以把問題上報給 CEO，讓 CEO 做決策。產品經理在這個情況下，變成只在管開發庫存清單（Backlog）的人。
- 產品經理可以開會，廣邀各部門的利害關係人來開會，在會議上讓他們互相辯論、然後做決定。這個狀況下，產品經理只是 Roadmap 的管理者。
- 產品經理做他真正該做的事。
作者認為，產品經理應該是公司裡面最厲害，有最強才賦的人，他必須身兼多項技能與強項，才能領導團隊成功。產品會成功，歸功於團隊中每個人做了自己該做的事，而當產品失敗時，就會是產品經理的缺失。產品經理需要評估和決定要做的產品和開發庫存清單，建立開發清單很簡單，但找出真正值得開發的清單才是最困難的，往往需要一些證據佐證。
產品經理真正的關鍵職責：
- 產品經理必須深度理解顧客：知道他們的問題、痛點、渴望還有他們如何思考、怎樣決定購買產品等，理解他們行為背後的原因。
- 深度理解數據資料：產品經理除了質化技能，也需數據分析的量化技能，包含會使用分析工具，看銷售分析、使用分析、或是看得懂 A/B tests 的結果。
- 深度理解公司商業：知道公司內利害關係人的想法與他們的限制，包含管理、銷售、行銷、財務、法務、商業發展和客服。
- 深度理解該市場和產業：知道競爭者、科技趨勢、顧客行為和期待、相關產業分析、社群媒體對你的市場和顧客扮演的角色。而有些更為特定的產業，會需要一些特殊的專業知識，產品經理最好同時是這些領域的專家。
產品經理需要的特質：
- 聰明：必須有足夠的好奇心，能快速學習並運用新科技，幫助顧客解決問題，同時能吸引新顧客，或是可以開創新的商業模式。
- 創造力：能跳脫思考框架，不被產品功能束縛，想出解決商業問題的方法。
- 持久力：即使遭遇抵抗，仍努力把公司推出舒適圈，藉由取得關鍵證據、持續溝通、建立跨功能團隊的橋樑。
總結產品經理的需具備的能力與職責
- 一開始，必須深知你的使用者和顧客，知道他們各樣質化和量化的數據，並勇於分享你對這群人的理解，無論是好是壞。
- 和公司其他利害關係人及商業夥伴建立強健的關係：說服他們你理解他們需在某些限制下做事，而你帶給他們的解決方案，不會違反這些限制。
- 成為你的產品或是該業界的無庸置疑的專家，並且樂於分享你的知識。
- 最後，辛勤工作，和你的產品團隊建立成熟且強健的合作關係。
所以其實產品經理和 CEO 的角色非常近似，差別只在於產品經理不是任何人的老闆。
The Product Designer
身為產品設計師的職責包含：
- 產品前期探索：會和產品經理一起探索產品。而且衡量設計師成功與否的關鍵，也不在他們的設計產出，而是產品是否成功。
- 全面性的使用者體驗設計：不單單只有介面設計，而是更全面地思考整個使用者與產品和公司的互動，包含不同時機點會接觸到的各種服務。
- 原型製作：好的產品設計師會利用原型工具和內部和外部人員溝通。
- 使用者測試：產品設計師也應該常常測試他們的點子，看看他們真實的使用者和顧客的反應。使用者測試比易用性測試定義更廣，包含使用者如何評價產品點子、他們是否願意購買等。
- 互動和視覺設計：互動設計著重於使用者的基本的心理概念模型、任務流程和控制元件的排版等。而視覺設計則是視覺元件組成、字體選用和視覺品牌表達。
如果公司沒有產品設計師，會發生什麼事？
- 產品經理要自己跳下來做設計，但未受過設計訓練，也可能多數時候，只提供線框圖，工程師自己補視覺設計。
- 或是提供使用者故事給工程師而已，不提供設計，工程師自己想辦法。
- 產品經理僅提供互動設計的線框圖，然後找個視覺設計或平面設計師提供視覺設計。
這三個結果很少有好的產出。蘋果公司對設計很注重是公認的，另外谷歌和臉書以工程技術出眾聞名，但他們其實都會投資在設計的比重也不少。
特別是商用軟體，通常設計都很可怕，因為購買者往往不是使用者。我們需要設計，不僅僅只是把我們的產品變得漂亮，更重要的是可以幫助我們探索對的產品。
產品經理要如何和設計師合作呢？
- 無論你需要做什麼，設計師都應該在旁邊。
- 你開始在初期構思產品時，設計師就應該加入。
- 盡可能讓你的設計師和使用者及顧客接觸，你們要一起認識你們的使用者和顧客。
- 抵擋自己提供設計的衝動，讓設計師盡可能有足夠空間可以靠自己解決設計挑戰。
- 鼓勵你的設計師一開始多多嘗試不同的版本，一開始不要就進入設計細節，而是多探索可以解決問題的不同概念。
The Engineers
產品經理和工程師合作融洽、工作關係密切是非常重要的。身為產品經理，自己要先做好功課，才能給團隊帶了產品管理的知識和技能。而且工程師通常都非常聰明，你別想呼弄他們。
建議產品經理應該有些程式語言能力或是電腦科學的知識，這樣比較能理解工程師複雜的工作。學這個不是要告訴工程師要怎麼寫程式，而是你會比較容易和工程師合作，比較能理解他們，也能知道科技的可能性和侷限性。
產品經理和工程師的每日例行出現的討論，不外乎兩種：
- 對自己正在發想的產品，徵求工程師的意見和想法
- 工程師對目前正在進行的工作，想釐清一些問題。
產品經理有程式技能很好，但不要越俎代庖，應該讓工程師可以自己發揮，給他們足夠的空間，讓他們自己想出最佳解決辦法。
還有一點很重要的事，產品經理的工作之一，就是要確保工程師自己能有熱誠主動積極，而不是被動聽命行事。
Product Marketing Managers
產品行銷經理不像產品團隊裡面的成員，整天會待在一起，但並不表示他們就不重要。產品行銷在產品發想、交付和最終進入市場都扮演著關鍵角色。
一個成功的產品，不僅要能幫助使用者解決問題，同時也要符合商業需求。所以我們要確定這個產品是不是真的有市場，我們要與確認其他競爭者作出區隔，有效能地獲得新顧客，讓他們持續使用產品，並找到通路，有能力把產品教到顧客手中。
產品行銷經理會幫助產品團隊擬定產品定位、訊息傳達，還有如何進入市場的計畫，他們和銷售通路很常來往，知道他們的能力、限制和現在競爭者的問題。
所以產品經理和行銷經理應該要有良好的工作關係，因為產品團隊需要有足夠的廣資訊大概知道市場的樣貌，比較好做產品。同樣的，行銷經理也需要大概知道產品早期可能的樣子，才能擬定進入市場的策略。
The Supporting Roles
其他支援角色包含使用者研究人員、資料分析師、自動測試工程師。
使用者研究員
研究人員除了可以幫助我們釐清需要解決的問題外，還會幫忙評估我們的解決方案好不好。研究人員執行質化研究居多，可以幫助團隊分析出幾種使用者、或是要做哪種研究才能找到想要的答案，幫助團隊理解使用者或顧客的行為。
資料分析師
而資料分析師偏重研究數據資料，幫助團隊搜集正確的資料、管理資料隱私限制、分析資料、計畫實際數據測試，並且能解讀這些資料。
自動測試工程師
現在工程師會寫自動化測試程式，讓程式自己跑測試，已經大量取代過去傳統手動測試的方式。測試工程師確保軟體和我們原先預設的結果一樣，在交到顧客手上前有足夠穩定可信賴的品質。
當公司成長時，除了需要聘用新的員工以外，領導階層的管理方式、有很多產品團隊時，如何掌握宏觀的產品視野、如何讓團隊自主、怎樣讓員工有責任心等問題，也是在該階段重要的議題。接下來這本書的作者開始談公司成長後，領導層要做的事。
The Role of Leadership
當公司成長後，面臨的最大挑戰即是我們如何知道產品的全貌，因為有很多不同的產品團隊開發產品，或是這些產品如何互相關聯，我們要怎樣把這些點接起來，有個比較宏觀的視野。
產品管理主管
確保整個系統在宏觀的角度上和公司的產品願景、策略、功能、商業規則、商業邏輯等吻合，我們需要產品管理主管或是比較資深的產品經理來幫忙。
這個角色需要定期幫忙檢視每個產品經理和產品團隊的工作，然後指出哪邊有問題，並幫忙解決中間的衝突點。產品經理、產品設計師、工程師和自動測試人員，都可能尋求他的協助。
產品設計主管
這個角色負責整體的使用者體驗，確保整個系統的一致性與可用性。產品設計內會有許多互動和緊密相依性，需要很多關於商業、使用者、顧個旅程等知識。必須要有至少一個人，可以檢視這些使用者會接觸到的地方。
技術部門主管
這個角色則是對系統建造要有宏觀的視野，必須檢視軟體架構和系統設計，不管這個系統是內部自己設計的，還是買來的。同時對於技術債，也要有清楚的應對策略。
以上講的比較是成長型公司時會有的領導層，如果公司成長到企業規模，這些人就會是中階主管。書中另外提到產品相關部門的高階主管該做的事和挑戰，我這邊就簡單帶過，有興趣的可以找書來看。
產品副總
需要有四種能力，負責以下四點。
- 團隊發展：培育產品經理，打造強健的產品經理團隊。打造產品和幫助人發展是很不同的能力，所以即使是對產品很在行的經理，也不一定就有能力培育新人。通常公司找人的時候，希望該職務有帶人的實務經驗為佳。
- 產品願景和策略：這個部分其實需要跟 CEO 和 Co-Funder 互相配合，作者列舉出不同情境與挑戰。如果 CEO 對產品和願景非常強勢有主見，然後 VP Product 也是，就很容易有衝突，VP Product 不會久待。如果 CEO 和 VP Product 對產品願景都不擅長，那做出來的產品可能就會缺乏創新。作者認為適合公司的 VP Product，能力應該要和 CEO 互補。
- 執行：不管願景有多美，如果沒人去執行，一樣只是空想，所以 VP Product 應該要知道怎麼完成任務，把東西做出來，讓團隊執行快速且有效率。有辦法規劃產品計畫、產品探索、產品發展流程，也知道依據公司規模，調整團隊工作方式，以達效率。
- 產品文化：必須讓產品團隊知道持續性且快速的測試和學習是極為重要的。也知道唯有順暢的團隊合作，才能帶來好產品，所以都會蠻尊重設計師和工程師。
技術長
技術長主要有六項職責：
- 組織：和強健的管理團隊一同建立極佳的公司組織，幫忙員工可以發展他們的能力。會透過員工的個人發展規劃、留職率、對經理的評估和公司整體的產品和技術部門的評估，去評估組織績效。
- 領導：在科技面，提供公司策略方向和領導，並和其他執行公司建立夥伴、客戶關係。
- 交付 (Delivery)：確保組織可以快速、可靠、重複地遞交具品質的產品到市場上。這個部分最大的障礙，就是技術債。
- 架構 (Architecture)：確保軟體架構可以傳遞功能、可以擴增、可靠地、有安全性並具效能。
- 探索：確保工程師在產品探索階段，會主動貢獻自己的能力，不應該只專注在寫程式上面，確保工程師也可以參與創新。
- 佈道：技術長作為工程團隊的代言人，須向工程師、公司夥伴和公司顧客展現領導力。
交付經理
這個職位在大公司裡比較會出現。這個角色主要分擔產品經理的部分業務，讓產品經理不用一直花時間在專案管理上，而沒有時間做他們真正的產品職責：確保產品值得開發。所以交付經理的職責比較像是在盯進度，確定在一些時間點，可以把東西交出來，也確保各跨團隊間的合作順暢，移除一些障礙。
Principles of Structuring Product Teams
當產品部門大了之後，遇到一個最困難的問題就是，如何將你的產品拆解成不同部分，讓不同的產品團隊負責，同時讓他們感到被授權、有責任感，知道自己對整個願景的貢獻。
作者認爲沒有任何一個團隊劃分方式可以通吃所有情況，都還是要看公司狀況，加以調整，以下是幾種常見劃分原則，可以依情況做比例調整：
- 配合投資策略劃分：看公司想要把資源投注在哪些功能或產品上，團隊結構可以依照公司的投資策略做調整。
- 將互相影響的程度降至最低：讓個團隊工作進度較為快速，也比較多自主權。
- 強調負責與自主管理：記得讓團隊覺得有使命感，願自動自發、有熱誠做事，而非只是單方面聽命行事，必須授權團隊，讓他們對產品負責的地方有責任感。
- 用最少資源發揮最大效用 (Maximize Leverage)：當組織壯大時，我們常會發現共用服務 (Shared Services) 是大家的需求，也變得越來越重要。我們為了速度和可靠性，不希望每個團隊重工。但是另一方面，這會增加團隊間的依賴，並削弱自主性。
- 考慮產品願景和策略：產品願景決定組織想要走的方向，而產品策略則是我們要怎麼走到那裡，會訂出幾個里程碑。在規劃團隊時，可以想想團隊要怎麼幫助產品願景和策略。
- 團隊規模：一個產品團隊最少要有一個產品經理和兩個工程師，如果產品和使用者有關，則還需要一個產品設計師。但最多工程師不要超過 10–12 個，因為一個產品經理很難掌握那麼多人。
- 配合軟體架構劃分：實務上，很多公司就是依軟體架構，去建構產品團隊。很多可能先從產品院際開始，最後使用結構性方式去實現那個願景，然後再依這個架構去設計團隊。有些更大的公司，會組成一些共用服務（核心服務或平台）團隊可以提供共用服務給起他團隊。
- 配合使用者或顧客劃分：有些公司提供平台給兩端供需市場（例如：買家和賣家，租客和屋主），可以從這邊劃分。需求方可能還可以再細分成不同行為的消費者。
- 配合事業單位劃分：比較大的公司，可能常常有不同事業線，但往往都在同一個基礎上，不同的事業單位可能顧客都是一樣的。如果每個事業線的科技都是獨立不同的，會把他們都視為獨立的公司，產品團隊可能就會完全獨立的，但這情況較為少見。
- 組織結構會不斷變動：為了讓產品組織未來越好，目標會不停變動，組織的需求會一直隨著時間改變，所以每隔幾個月或每年就應該要檢視一下團隊結構。
心得
這幾章比較有感覺的地方有兩點：一個是產品經理如何跟設計師合作，另一個則是怎麼帶動團隊文化。
如何和設計師合作，提到了產品經理應該要抵擋自己提供設計的衝動，讓我想到很多時候，無論是業主，或是公司合作同事（如產品經理），有時候他們就會跳下來，或是在螢幕後方，指使設計師該怎麼做設計，這不僅不尊重設計專業，也會讓設計師一把火在內心燃燒。而有些人，則是自己跳下來設計，用簡單的方式表達理念，然後要設計師完成。設計師僅變成執行者的角色，也容易讓設計師失去工作熱誠。
我想不管是哪種職業，大家或許或多或少都希望獲得工作的成就感。就像書裡面提的，怎麼讓團隊擁有「熱誠」是不容易的事。比較聰明一點的領導人或是專案經理，會用提點的方式，讓設計師往自己想要的方向邁進，又不過度干預。讓工作夥伴覺得這個東西是自己想出來的，則是最高境界，而自己退到後面微笑著，達成目標。這讓我想到在以前學校的女同學曾提過：如果我有喜歡的男生，我不會去追他，而是用一些小心機，讓他心動，自己主動過來追我，大概是同樣等級的策略吧 (?)。
成就感會驅動工作熱誠，而且一定的團隊自主，絕對是大加分。過去的自己，曾經有過帶領公司後進的經驗。現在想起，覺得自己過去的不成熟而感到有些懊悔。剖析自己的個性，對自己的高標準往往也會不小心套用在別人身上，再來就是看到成果和自己所想的方向不同時，會立馬覺得不滿意，卻忘記停下來換個角度思考。我想過去的自己，可能也剝奪了別人的工作熱誠（內心覺得罪惡）。不過我後來也發現自己的缺失，開始發現，即使和自己原先設想不同，但有時候這些想法，並不完全是壞的。要做的，應該是請對方想一下，這個方案有什麼利害得失，讓他們自己先思考分析過。
這也是書中有提到過的，有時候雖然有做產品的能力，但並不代表你有帶人的能力。這兩者能力差異其實很大。
書中另外也提及設計師一開始多嘗試不同的版本，不要一開始就設計細節，而是多探索不同的概念。回想自己工作的方式，通常都自己會提出三四種不同的方案，然後列出個方案的優劣點，然後再針對自己比較喜歡的方案，要怎麼再減少他的缺點，然後去不斷演化設計，辛苦卻是有趣的過程。
另外設計師常會遇到的另一個問題是，老闆的記憶力都不怎麼好。老闆上週說設計要採用這個，下週可能就推翻自己的結論，或是前一天說這個，隔天又有相法的想法。然後讓自己覺得有些無所適從，設計熱誠也會下降，這是我踩過的坑。
後來想想，其實老闆蠻會反面思考和試探的。他會提出他喜歡的原因，然後再提出另一種思考試著去反駁自己，或者是過一陣子，讓思緒消化完之後，發現有盲點。我覺得自己也是容易有盲點的人，提出一個設計之後，可能過了兩三天，才自己發現這個設計有缺失的地方，當初沒想到。我想說這可能是人之常情。第二點，身為設計師，你有沒有站出來為自己的設計辯護？還是只是聽上面的人怎麼說。設計師應該要提出自己的想法，表達立場，但這不代表設計就一定要採用你的想法，因為本來設計就是權衡各方的意見，身為設計師，你也自然該有你的意見，從設計的立場發聲。如果有研究員的研究佐證，那就可以為使用者發聲。
好像稍微離題了一點。
本書的這部分，還是以產品經理的立場，希望產品經理能做好他的工作，確保產品值得開發，然後還有一些溝通軟實力，讓設計師和工程師等團隊成員，可以合作順利，並在產品探索過程，提供不同面向的想法。本書也提出了在團隊過程中會發生的問題，值得討論。
如果你（妳）喜歡這篇文章，請給予鼓勵
拍手👏10下代表你喜歡這篇文章
拍手👏20下代表這篇文章對你非常有幫助
拍手👏50下代表這篇文章實在太棒了！！！有任何問題，也歡迎留言給我：）
