TCC 推薦：大家好，這裡是 TCC 翻譯情報局，我是李澤慧。眾多產品管理者或許會遇到各種困境：在眼前利益和長遠理想中徘徊、害怕項目失敗、受人員管理問題所牽絆、在產出為上的循環中心焦力卒等等。本文作者通過列舉產品管理的七項原則，覆蓋了目標設定、團隊管理、心態認知心態調節等諸多方面，讓從業者們在迷茫中有志可明、有跡可循。
產品管理是一門相對較新，且在不斷快速發展的學科。每周都會有一些行業領導者關注的產品開發最佳實踐的新文章出現。紛雜泛濫的信息可能使人們迷茫於遵循哪些實踐指南，以及如何在自己的工作和團隊中尋找改進機會。
此外，這種不停息的更迭意味着今天被認為是最佳實踐案例的東西明天可能就會過時。例如，今年早些時候，有消息稱 Spotify 不再遵循着「Spotify 模式」了，即便它曾一度被譽為貫徹靈活和精益原則的大型產品開發組織的模範。那麼，在這些最佳實踐中有可以被淺顯應用的嗎？
不過，這個困境有一個解決方案。與其追求對最佳實踐的不斷改變的理解，不如揭示這些實踐案例背後的原則。這些原則比實踐本身更深層次，而且在時光變遷中更穩定。然後，您可以以適應特定背景的方式為自己、團隊及更大型組織實踐這些「最佳原則」，而不是直接運用最佳實踐案例。
在本文中，我將分享產品管理和領導力的七項原則以及它們的一些含義：
1.從問「為什麼」開始
2.理解問題
3.持續聚焦
4.授權團隊
5.擁抱不確定性
6.平衡投入、產出、結果和學習
7.迭代，迭代，迭代
着眼於原則而不是實踐的美妙之處在於，這些原則可以沿用於組織的任意層級。無論您是團隊中的產品經理、團隊負責人、CPO 還是初創公司 CEO，您都將能夠找到在自己職權範圍內應用這些原則的方法，以及改進工作與組織的方式。
1. 從問「為什麼」開始
1. Start With Why
第一條原則，「從問為什麼開始」（「Start With Why」）；也是西蒙·辛克的 TED 演講的題目（還有本同名書）。從「為什麼」開始思考，意味着在討論「做什麼」和「怎麼做」的細節之前，討論應該先圍繞「為什麼」展開：我們工作的更深層次目的是什麼？我們想實現什麼目標？我們對未來有什麼願景？
約翰·多爾指出了 理想驅動者和利益驅動者 之間的區別 —— 理想驅動者受自身的激情指引去實現更深層級的目標，而受利益驅動者則力圖抓住所有當前出現的機會。但偉大的公司和好的產品往往是由理想驅動者建立的。與利益驅動者相比，理想驅動者往往表現出更大的內在動機（ 因為他們致力於一個對他們來說很重要的目標 ），面對困難時更有毅力，更注重細節。建立理想驅動的團隊需要從問 「為什麼」開始。只有擁有共同的信念，才能讓他人成為為公司和產品未來願景努力的理想驅動者。
從問「為什麼」開始在各個層面都是可能的。顯然，公司和產品領導者的主要職責之一是為產品設定方向，其中包括作為產品戰略和發展曲線的基礎的理想願景。因此，對於一個理想驅動的組織的領導來說，確保這個願景被廣泛傳播，並被團隊作為他們存在的理由而接受是至關重要的。
甚至這個原則的運用，在獨立的產品團隊中也是如此。你可能不會對你所做的每一件事都有一個宏偉的願景，但將產品團隊的所有工作與產品願景和公司使命聯繫起來仍然是至關重要的。此外，即使是獨立性工作，你也可以在團隊中討論你為什么正在做這個事：這不僅僅是實現整體願景的一小塊拼圖，還包括這個功能將如何改善你客戶的生活 （和/或有助於公司的成功）。
總之，無論你是一個產品領導者、產品經理，甚至僅僅是一個產品團隊成員，你都可以遵循從問為什麼開始的原則，在日常工作和宏偉理想之間不斷建立聯繫。
2. 理解問題2. Understand the Problem
第二個產品管理原則是真正、深刻地理解你正在解決的問題。乍一看，這個原則聽起來很明顯，甚至微不足道。你怎麼會去解決自己不懂的問題呢？
然而，在實踐中，我們常常只追求有特色的點子，而沒有花時間去真正理解這將解決的問題，我們當前和潛在的客戶中有誰確實有這個問題，以及他們是否足夠關心這個問題來為解決方案買單。
因此，遵循這一原則，首先且最需要關鍵的產品管理技能是同理心，這意味着能夠設身處地為他人着想，從他們的角度看問題。如果你不了解你的客戶是如何看待這個世界的，你就很難試圖為他們解決問題。但是，你也不能目光短淺地只從客戶的角度出發，否則你也不會比他們更好地解決這些問題。因此，真正理解問題需要從不同的角度來看待問題，這需要產品團隊思維的多樣性。
理解問題還意味着要在試圖解決問題之前先定義問題。然而，這也意味着了解到問題和解決方案往往是相互依賴的，特別是在技術支持的產品中。例如，當新興技術開啟了可能改變我們對問題理解的新可能性時，我們也必須回過頭來調整問題的定義。這就是「雙鑽石」設計過程在數字產品中往往存在根本性缺陷的原因 —— 將產品設計或產品改進的過程劃分為獨立的階段，分別針對問題和解決方案進行發散和總結。一個更好的比喻是「設計草稿」，它表現了一種對混亂的探尋，然後隨着時間的推移而逐漸清晰。
當然，有時你所做的工作幾乎完全集中在產品問題上。畢竟，你想要的是建立一個企業，而不僅僅只是解決人們的困難。例如，盈利功能或轉換機制的改進主要是為了商業利益，而不是用戶利益 ( 除非你想直接免費提供那些內容 )。然而，平衡是很重要的。為了讓業務獲得價值，你必須首先為客戶創造價值，而這需要你解決他們的問題。所以，首先要理解並解決客戶的問題，然後專注於為你的業務提取價值。
3. 持續聚焦3. Focus Relentlessly
當你開始思考「為什麼」並真正理解你想要解決的問題時，是時候心無旁騖了。持續聚焦意味着做比設想中更少的事情，但是要做到極致。
持續聚焦意味着要明白，一個偉大的產品並不是僅僅以還可以的方式做了很多事情。一個偉大的產品意味着真正搞定一些事情。這意味着把更少的事情做得更好。
持續聚焦原則意味着 80:20 的方法可能在產品開發中被誤導。80:20 方法意味着用 20% 的努力可以實現的 80% 的價值，然後只交付這80%的價值。然而，事實是，這種差異化通常是通過最後的 20% 來實現的，因為它們需要更多的努力。如果剩下的 20% 的價值很容易達成，那麼每個人都會這麼做。通過多走一段路，你的產品對那些重視剩餘 20% 價值的客戶更具吸引力，而這是很難複製的。
因此 持續聚焦 意味着你不能通過遵循框架或計算 ROI 來對產品的工作進行優先排序。首先，這些框架忽視了創新產品開發背後的根本的不確定性。不過，更重要的是，這些框架永遠不會告訴你需要將重點放在難以構建的差異化特性上，也不會告訴你要關注顧客的愉悅感，因為回報幾乎不會立竿見影。與遵循框架不同，您需要基於願景、戰略和對客戶及其問題的深刻理解來確定優先級。
最後，這個原則需要明確：不存在單一的優先級排序過程。相反，有很多層級的優先級，在每個層級上，需要刪減的遠遠多於需要集中的。製作產品願景是最高優先級的，因為任何產品願景之外的東西都是不應該被關注的。產品戰略、產品路線圖主題的選擇、該主題中的問題領域和解決方案想法是更深層次的優先級別，每一個級別都需要持續聚焦。換言之，這個原則同樣適用於從領導者到個人貢獻者的各個層面。
4. 授權團隊4. Empower the Team
第四個產品管理原則是通過授權團隊、產品開發中涉及的所有學科之間的跨功能協作（ 至少包含產品管理、設計和研發之間的協作 ），來解決客戶問題 （ 以業務服務的方式 ）。授權團隊不同於專題小組或交付小組，因為他們被賦予了要解決問題的目標，而不是要交付的功能項目。
被授權的團隊在 工作動機、以客戶為至上、響應速度和創新能力方面有很多優勢。他們更有動力，因為他們有更高的自主性和使命感。他們更以客戶為中心，因為他們可以在與客戶的密切接觸中了解到最佳解決方案，而不是基於高級管理層的決策。他們有更快的速度，因為反饋循環在團隊內部，不必在管理鏈上上下波動。它們具有更高的創新能力，因為跨職能的性質，即對用戶、技術和業務的理解結合在一起。
對於這一原則，需要注意的是，真正的團隊授權需要高級管理層的支持（ 畢竟，團隊需要以問題的形式給出他們的目標，而不是以特性路線圖的形式 ）。然而，即使作為一個單獨的產品經理，你也可以盡最大努力授權給團隊的其他成員。許多第一次做產品經理的人認為他們的工作就是知道所有的答案，擁有所有的想法，但事實上，沒有什麼比這更離譜了。你可以利用團隊的集體知識，通過更加多樣化的思維，確保整個團隊從流程的一開始就參與進來，從而產生更好的結果。這尤其意味着工程師應該參與發現階段，甚至在解決方案想法形成之前。
當然，並不是每個團隊成員在整個過程中的參與程度都是相同的。在發現階段，設計和產品管理的工作量仍然較大，在交付階段，工程師的工作量也較大。然而，讓工程師更早地參與到這個過程中，可以幫助他們把自己的觀點展現出來（ 例如，強調技術帶來的潛在新穎方法 ），將他們的工作與更大的目標聯繫起來，並確保每個人都認同所選方法。
一起開始，一起發現解決方案，也會讓每個人都對所選的解決方案投入更多的精力，這意味着更加注重細節和工藝，從而獲得更好的產品。
5. 擁抱不確定性5. Embrace Uncertainty
授權給產品團隊尤其重要，因為它順應了第五個原則：擁抱不確定性。產品開發從根本上來說是一項有風險的工作。這種風險不僅僅在於你的想法能被執行得多好。它遠不止於此：不管你最初對產品創意的信心如何，大多數創意都無法實現你所希望的虛擬價值（ 對客戶、對企業 ）。此外，除非你投入了大量的精力去探索，否則你將無法識別那些壞主意。這就是產品管理的不確定性公理。
如果不接受這種根本的不確定性，你就永遠不會推出一個偉大的產品。接受這種不確定性意味着接受失敗，承認理論上聽起來很棒的想法無法保證任何實際價值的實現。這意味着你要一次又一次地放棄所愛。這也意味着你有時可能會有一連串的壞主意，會一個又一個地失敗。接受這一點可能很難。沒有人喜歡一直失敗。因此，重要的是要理解這是產品開發的基本屬性，沒有什麼可羞愧的。相反，每一個沒有實現假設價值的想法都應該被理解為一個學習的機會。
因此，遵循這個原則意味着驗證所有想法。這表示任何想法，即使是來自高級利益相關者或客戶的想法，都不是神聖不可侵犯的 —— 一切事物都需要自證其與眾不同的地方。這種驗證需要儘可能早地進行 —— 交付後才發現它並沒有產生設想的價值，這意味着巨大的資源浪費。比起將一些已經發行但卻未能傳達價值的內容留在產品中（ 因為不斷增加的複雜性 ），我們更願意將其扼殺掉，但是如果能夠通過原型去驗證想法 並意識到它並不可行的話便會更好。
有許多驗證實踐都遵循着擁抱不確定性的原則。當評估它們是否適用時，要理解真正可以信任的唯一信號是人們「用腳和錢包投票」很重要。僅僅問某人是否有某個問題或想要更好的解決方案，很可能得到肯定的回答。然而言不由衷。如果你真的想知道問題是否足夠重要，或者你的解決方案是否對客戶有效，你必須讓他們投入他們的時間和/或金錢 —— 開始使用你的解決方案，或者更好，為之付費。這可以是原型或最小可行產品（ MVP ）的形式，但沒有行動的語言不應該被理解為驗證想法的有力證據。
6. 平衡投入、產出、結果和學習6. Balance Inputs, Outputs, Outcomes, and Learning
繼前一個原則之後，下一個重要的原則是平衡輸入、輸出、結果和學習。傳統的軟件開發過程管理常常目光短淺地集中在輸出上：我們產出了多少新功能?然而，從產品開發的不確定性公理來看，並不能保證推出越來越多的功能對客戶（ 或企業 ）完全有利。因此，現代方法已經意識到關注結果（ 對於客戶和業務 ）是重要的。然而，即使只關注結果，也有它的挑戰。相反，您還需要考慮輸入（ 用於做出產品決策和決策過程的信息質量 ）以及學習（ 如何將已獲得的結果反饋到產品開發過程中 ）。
與團隊授權一樣，你只能在高級管理人員的支持下完全遵循這一原則。如果團隊是通過產出來衡量的，那麼團隊就很難關注其他方面。然而，確保結果、投入和學習不被完全忽視，這是甚至單個團隊成員都可以關注的事情。
這種平衡的需求在確認你確實在解決想要解決的問題時尤為重要。過於關注短期結果的組織可能會陷入「A/B 測試陷阱」，即每個產品變更都要在 A/B 測試中針對產品的當前版本進行測試。當然，A/B 測試是科學地衡量變化影響的好工具，但它也可能扼殺真正的創新，只為了優化。
這一原則能夠在單個團隊中實現的另一個重要方法，便是確保足夠重視學習的反饋循環。學習、從所取得的成果中提取發現，並將其反饋到過程中的挑戰是：今天的工作只會在遙遠的將來獲得回報，甚至造福於不同的人（ 當產品團隊的當前成員早已離開時 ）。然而，為了產品的長期成功，重要的是收集經驗教訓，記錄並以某種形式共享。
7. 迭代，迭代，迭代7. Iterate, Iterate, Iterate
最後一個產品管理的原則是迭代、迭代、再迭代。這一原則不僅包括通過 Scrum 或其他敏捷軟件交付實踐交付軟件的迭代，還包括產品發現、交付和改進產品的整個過程的迭代。
這始於產品發現和被誤解的 MVP。許多人認為 MVP 應該是你發布的新產品或新功能的第一個版本，範圍應該儘可能小，這樣你仍然可以驗證或推翻核心價值假設。理解 MVP 概念的更好方法是：它是一個驗證當前最具風險的猜想或假設的工具。這意味着兩件事：首先，MVP 不一定是產品。事實上，通常情況下，一個原型或概念驗證通常不會比一個完整的、可擴展的產品生產和驗證成本更低。其次，一旦風險最大的假設得到驗證，另一個假設就成為了下一個風險最大的假設。這意味着你現在可以迭代並創造出另一個 MVP 去驗證下一個假設，直到剩下的假設承擔足夠小的風險，你才有信心創造出真正的產品。真正產品的第一個版本不必再是一個有很多「捷徑」的最有價值產品—— 因為你已經降低了風險，你可以構建一個用戶將樂於使用的產品，而不是一個蹩腳的半生不生的體驗。換句話說:應該有一系列 MVP，然後是一個不是 MVP 的 v1 產品。
在許多迭代軟件開發實踐中，迭代交付幾乎是一個給定的概念。我在上面已經提到了一個特別重要的方面：確保包括工程師在內的整個團隊不僅參與到交付過程中，還參與到發現迭代中。這樣你就可以確保發現和交付之間沒有困難的「移交」過程，這將使迭代過程成為一個更加線性的流暢過程。
最後，迭代的原則還包括產品發布後發生的事情。太多的團隊試圖儘快擺脫他們已經成功發布的功能:「這工作得很好，參數已經改進了。讓我們開始下一個待辦事項吧!」 不過，按照持續聚焦的原則，通常最好是加倍關注有效的東西，並將其從優秀提升到卓越。再說一次，一個偉大的產品是一個真正能搞定一些事情的產品。所以，當你發現一個功能可以為你的客戶帶來價值時，為什麼不讓它脫穎而出呢?
所有這些原則都只是指導思想。根據上下文、文化、流程和產品的不同，您可以通過多種方式在自身組織內實現這些原則。無論如何，我希望這些原則能夠對研究您現在所遵循的實踐以及如何改進它們有所幫助。
原文：https://jefago.medium.com/seven-product-management-principles-55f4909cd9a2
作者：Jens-Fabian Goetzmann
譯者：李琳菲
審校：徐曼鷺、李澤慧、張聿彤
編輯：李莉好
本文翻譯已獲得作者的正式授權（授權截圖如下）
往期精選文章：
留言列表