如果您是產品經理，或者您自己可能正在扮演產品經理的角色，那麼在某些時候，您可能需要向不太熟悉該領域的人解釋您的工作…
正好，這裏有一個適合所有朋友的產品管理定義。
什麼是產品管理？定義
用最簡單的術語來說……
產品管理正在決定下一步要構建什麼。
產品的存在是爲了解決世界上的問題。這適用於實體產品，如滑板，以及數字產品，如微信、QQ。這些問題不只是漂浮在以太坊中。它們是現實中的人們所面臨的問題。因此，爲簡單起見，我們將它們稱爲用戶需求。
用戶需求包括功能需求，比如我需要準時上班，或者情感需求，比如我需要得到朋友的尊重。
實際上，滿足用戶需求的是產品的功能。滑板的輪子允許它運送它的主人。特斯拉的美麗而自信的輪廓讓擁有一個人感覺像是一種自我表達的形式。
數碼產品也不例外。奶奶有協調與孫子孫女聚會的功能需求，因此她屈服並註冊了微信。（經過 5 小時的培訓，她學會了讓添加好友，併成功發送了她的第一條文字消息。與此同時，她的孫子孫女有一種被同齡人接受的情感需求，可能會選擇通過在社交媒體產品上培養在線角色來實現這一目標，這些產品的功能是專門爲該任務量身定製的。
物理產品與軟件的主要區別在於，它們的功能必須在銷售之前很久就確定下來。軟件，尤其是網絡應用程序和移動應用程序，總是隨着新特性和功能的增加而不斷髮展，以供用戶使用。在這種情況下，特別公平地說，產品經理的工作是決定接下來添加哪些特性和功能。
所以下次當你向朋友解釋你的工作時，你可以說：“你知道抖音是如何把你的臉變成各種特效的嗎？只有當產品經理認爲這是一個好主意，並付出血汗和淚水帶領一羣人（即設計師和工程師）將其變爲現實時，纔有可能實現這一功能。”
當你剛被朋友插話說：“產品經理如何決定一個功能是否是一個好主意？”時，你甚至會知道該說什麼？
我回想起國外一本書中看到這樣對產品管理的定義：
“產品管理就是發現有價值、可用且可行的產品。”
好的，如果產品（及其包含的功能）有價值、可用且可行，那麼構建它們是一個好主意：
- 價值在於他們必須解決某人的需求
- 可用，因爲人們必須能夠在不放棄的情況下學習如何使用它們，並持續使用它們而不會感到沮喪
- 可行，因爲新功能不需要太多資源（時間、金錢、精力、物理材料），否則產品背後的公司將破產（或在市場上被更精明的競爭對手擊敗）
總而言之，產品經理決定下一步要構建什麼，他們通過確保他們構建的功能有價值、可用和可行來做到這一點。我們將在接下來的部分中探討其中的每一個。
產品經理決定下一步要構建什麼，他們通過確保他們構建的功能有價值、可用和可行來做到這一點。
我們還將研究產品經理的其他一些職責，這些職責使這個角色變得如此多面、如此容易被誤解、如此有趣。
瞭解用戶需要什麼
在產品經理決定下一步要構建什麼功能之前，他們通常首先考慮什麼對他們產品的用戶（和潛在用戶）最有價值。爲此，他們必須深入瞭解用戶的需求。請記住，需求可以是功能性的，也可以是情感性的，所以這比聽起來要難。
考慮到我們經常不瞭解自己的需求這一事實。我們爲從未使用過的訂閱和實際上並沒有讓我們變得更好的產品（你去年穿過的那件漂亮的毛衣）支付了大量的錢。與此同時，我們每天都在使用的一些新產品我們從來不知道需要什麼。
產品管理就是在問題（用戶需求）和解決方案之間架起橋樑。產品管理工作的核心職責是深入瞭解問題的一面，以決定最佳解決方案。幾乎總是有許多可能的解決方案，因爲解決方案有許多不同的形式。它們不僅僅是精美的拋光產品。有時它們是用戶爲自己設置的解決方案（例如手寫的購物清單）。如果您是開發智能購物清單應用程序的產品經理，它至少需要與自制解決方案一樣好。事實上，如果您希望人們不遺餘力地發現它、學習如何使用它、支付它並養成在計算機上使用它的習慣，它可能需要 2 倍、5 倍或 10 倍。定期。
產品管理就是在問題（用戶需求）和解決方案之間架起橋樑。
花點時間讓這個想法深入人心：對於每個問題或需要，都有一些解決方案，在開始嘗試解決之前確定您正在解決的問題很重要。這似乎很明顯，但這是大多數業餘產品經理（甚至許多有經驗的產品經理）迷失的第一種方式。我們人類傾向於關注解決方案（例如新的 PDF 導出功能），因爲它們非常具體。我們可以想象它們的樣子，以及它們將如何工作。它們比用戶 需要的模糊和抽象的概念更容易讓我們思考（比如需要與我的老闆共享數據）。但要注意過早地關注解決方案！即使用戶請求導出 PDF 以與他們的老闆共享數據，他們後來也可能同意將其作爲嵌入在電子郵件中的折線圖 PNG 發送會更好。只有正確分離問題和解決方案才能讓您有機會發現這一點。如果不這樣做，就有可能提供一個次優解決方案，或者一個最終根本不會被使用的解決方案——即使您完全按照用戶的要求構建了！考慮到您的團隊即使在開發最小的功能（更不用說可能需要數月的工作和數千工時的新界面）上付出的努力，當 PM 花時間仔細分析用戶需求時，每個人都會獲勝。
稍後我們將更多地討論 PM 在確定、設計和開發最佳解決方案的過程中的作用，但現在的關鍵問題是……
數字產品經理如何確定用戶真正需要什麼？
最好的產品經理經常從事以下所有活動：
- 設置系統和流程來收集傳入的用戶反饋：無論您的團隊使用QQ、微信、郵箱還是其他工具與潛在客戶和客戶溝通，他們都有可能以您的方式自願發送反饋。PM 負責建立系統以積極尋求這種反饋，並收集和分類功能請求、改進想法、錯誤報告、可用性投訴、問題、建議的黑客和解決方法，以及對現有功能的好評。關鍵是對用戶提供的這些黃金洞察進行分類，這樣他們就不會迷失在團隊中各個產品經理的電子表格、收件箱或印象筆記中。
- 從面向客戶的同事那裏收集見解：誰比在營銷、銷售和支持方面花費所有時間與他們一起工作的同事更瞭解您的用戶？鼓勵他們收集功能請求並提出探索性問題，以便他們可以報告用戶的潛在需求。通過這種方式，它們就像您的用戶研究團隊的延伸。
- 走出大樓：在自然環境中採訪用戶，觀察他們現有的解決方案，觀察他們的日常生活，並直接研究他們的痛點。
- 在用戶面前驗證你的想法：一旦你對用戶的需求有了一些瞭解，模擬簡單的解決方案——甚至草圖或紙上原型都可以——然後問“這能解決你的需求嗎？” 這裏的目標是使用潛在的解決方案來確定您是否正確理解用戶真正需要什麼。
- 採訪你失去的用戶：當用戶離開你的產品使用其他解決方案時，或者決定不首先成爲客戶時，問問他們爲什麼。他們更喜歡什麼解決方案？哪些特徵（或缺乏特徵）對他們的決定影響最大？您的產品中是否缺少某些破壞交易的東西？
好的，您已經收集了反饋、記錄了採訪、驗證了想法並進行了一些損失分析。您甚至發現了一些圍繞用戶真正需要的趨勢。但肯定有很多需求。這本身就存在問題......
數字產品經理如何跟蹤用戶需求？
可悲的是，許多人沒有。現狀是將此類信息保留在您的腦海中，儘管這幾乎不可能確定不同用戶所擁有的微妙而複雜的需求重疊。
更常見的情況是，產品經理在冗長的功能待辦事項列表中捕捉解決方案想法（將解決這些需求）——你有一天想要開發的功能列表——通常存儲在電子表格、任務管理工具（例如 Trello、Asana）中，或開發計劃工具（例如 JIRA、Pivotal Tracker）。如果您還沒有注意到這個問題，如果您所做的只是捕捉解決方案的想法，那麼您就有可能得出結論。很多時候，在你確定它應該解決什麼問題之前，你會專注於一個特定的解決方案想法。這就是爲什麼擁有一個適當的系統來記錄您希望解決的用戶需求以及在它們之下的相關解決方案想法（功能想法）如此重要的原因。
即使您開始捕捉功能創意，在這個階段保持高水平仍然是值得的。正如我們將在下面討論的那樣，用戶體驗設計師和工程師專注於爲您認爲最有價值的問題開發最佳解決方案。試圖爲他們做他們的工作並不能很好地利用你的時間和專業知識。它還可能會給您的團隊帶來不必要的壓力，並導致解決方案欠佳。
決定構建什麼（並計劃何時構建它）
到目前爲止，我們已經根據用戶的需求仔細研究了確定哪些功能最有價值的過程。現在我們將更多地瞭解產品經理的其他核心職責：確保功能可用且可行。
一旦您組織了您有興趣解決的用戶需求併產生了一些功能創意，您就需要開始決定構建什麼。此階段稱爲功能優先級。如果您考慮對數百個甚至數千個功能進行優先排序以決定下一步要構建哪些功能，這似乎非常令人生畏。這就是爲什麼優先排序最好隨着時間的推移而不是在單個會話中完成。
產品經理在確定構建內容的優先級時會考慮什麼？
以下是一些提示，可幫助您在確定下一步構建的優先級時爲成功做好準備：
定義您的目標用戶：大多數產品服務於許多不同類型的用戶，其需求和目標略有不同。提前決定你的目標用戶羣是誰——對你的產品的成功最重要的用戶羣。你不能讓他們都滿意！當迫在眉睫時，如果您能做出優先級決定會更好，因爲它們最適合您的目標用戶，即使這樣做意味着放棄其他人的需求。
專注於具體目標：除了功能如何滿足不同類型用戶的需求之外，構建某些功能也有戰略原因。也許新的入職流程不是很受歡迎，但這是推動產品購買的絕佳機會。或者，您可能決定將工程精力花在增長黑客上，以幫助現有用戶從他們的網絡中邀請其他人開始試用您的產品。提前決定您將使用什麼標準來評估功能創意。現在對您的產品和您的公司最重要的戰略是什麼？留住現有用戶？獲取新的？提升用戶體驗？提高平臺可靠性？您的目標可能會因季度而異，
分階段確定優先級：在初始階段，您可以根據用戶本季度最常請求的內容對您的功能創意進行排序。這可能會幫助您瞭解有多少想法與幫助用戶更快地掌握您的工具相關，這反過來可能會激發本季度改進入職培訓的舉措。反過來，這將幫助您將目光投向支持此目標的其他功能。
驗證你的假設：即使某些功能創意被優先考慮爲候選者——你正在考慮構建的重要功能——將它們直接發送給設計師和工程師開始工作也是不明智的。執行高保真設計和編寫生產代碼需要團隊中高技能成員的時間密集型工作。最好採用您正在考慮使用的功能並由客戶首先運行它們 - 特別是那些首先要求它們的人。他們還需要這些功能嗎？您是否正確理解他們的需求？他們是否設想了與您相同的最終解決方案？如果存在差異，是否表示誤解了潛在需求？在開始研究某個解決方案之前，嘗試回答所有這些問題。
冠軍 將 用戶的 需求：最終，產品經理和用戶體驗設計師（或‘交互設計師’）共享的深刻理解用戶需求的責任，並確保任何提議的解決方案將使用給定用戶的背景知識，技能，和經驗。這通常涉及用戶測試特定的解決方案想法，以確保用戶輕鬆瞭解他們的工作方式。這通常可以在編寫一行代碼之前在原型上完成。產品經理應儘可能參與此過程，因爲與工程和營銷方面的其他同事共享用戶上下文通常是您的責任。
知道何時將您的優先排序過程置於現實中：在深入瞭解您正在解決的問題之前，從工程團隊的代表那裏尋求特徵複雜性估計會適得其反，但是一旦您將它們縮減爲少數幾個以進一步研究（這個過程通常稱爲產品Discovery），您將準備好生成特定的解決方案想法。這意味着您團隊的技術成員將能夠評估每個人的開發難度。這並不總是非黑即白。經常會附帶一些意外情況。（例如工程師：“如果我們在開發此新功能時必須支持 Internet Explorer，則需要 2 個月。如果我們不支持，則需要 2 小時。”）關鍵是要明確權衡，以便您知道何時走捷徑，何時進取構建複雜功能，
熟悉流行的產品優先級框架：有許多不同的方法可以確定最重要的標準並使用它來評估要構建的功能。例如，RICE規定了一個特定的公式，用於根據預計的覆蓋範圍、影響、努力和置信度來判斷功能優先級。另一種思想流派支持Kano 模型，它將功能分爲滿足基本需求的功能（如果您的產品不提供這些功能，可能會破壞交易）與積極取悅用戶的功能。
與設計人員和開發人員清楚地交流上下文和約束：當產品經理準備將功能發送到開發中時，確保設計人員和開發人員瞭解他們正在構建的內容及其原因很重要。這意味着對於每個功能，產品經理必須傳達以下詳細信息：
- 戰略目標
- 需要解決核心用戶（和目標用戶羣）
- KPI（如果此功能成功，將移動什麼指標以及移動多少？）
- 功能啓用的用戶場景
- 約束、要求和其他成功標準
傳統上，此信息以功能規範（或“規範”）的形式呈現。值得補充的是，近年來這種方法受到了一些反對。太多的產品經理將規格視爲與團隊溝通的最終目的，即使他們缺乏幫助設計師和開發人員瞭解他們正在解決的真實用戶需求的關鍵背景——真正的原因在他們正在研究的功能背後。從產品到工程的“把規格扔在牆上”的過程也有一些不人道的東西——用幾十（甚至幾百）頁來詳細說明需求，而沒有讓工程師站在用戶面前，用他們自己的眼睛看到相關的需求。當然，工程師不可能採訪每個用戶，但有一個快樂的媒介，其中規範清晰詳細，但點綴了更多用戶上下文，所有團隊成員都花更多時間與最終用戶互動。
PM 如何計劃何時構建和啓動功能？
分階段發佈以最大程度地降低風險：有時可以自行構建功能併爲用戶提供很多價值。這可能是高度要求的特定功能的情況。其他時候，如果您要以更實質性的方式推進您的產品，則必須一起開發和發佈互補功能。例如，您可能會開發一個由許多功能組成的全新界面，以滿足管理員用戶角色的需求，他們需要能夠更好地管理組織中的用戶，以便他們成功使用您的產品。需要一個全新的管理控制檯來幫助他們在基本級別管理他們的產品。
在後一種情況下，我們已經超越了一次性功能優先級來評估整個計劃。這是一個棘手的領域，因爲它要求團隊在對用戶進行測試之前冒着投入大量精力開發許多功能的風險。始終嘗試通過開發和啓動儘可能小的功能組來最小化這種風險——即使這是更大計劃的一小部分。這樣，您將盡早開始收集用戶的反饋，並且如果您學到一些令人驚訝的東西（例如，管理員實際上並不需要審計日誌，如果有更好的版本控制，他們可以在沒有它的情況下工作）。您始終可以通過稍後發佈功能的後續階段來完成計劃。最小可行產品。它是精益方法的核心，適用於優先級和計劃的幾乎所有方面。
調整你的團隊
到目前爲止，我們已經回顧了產品經理如何負責確保產品有價值、對用戶有用和可行建立。雖然大部分工作都是預先進行的，但一旦將特性規範發送給工程部門，產品經理的工作就不會完成。開發一開始，圍繞基於用戶需求設計特定功能的最佳方式就會出現一系列問題。即使是有史以來最好的書面規範也無法涵蓋所有意外情況。產品經理的工作是在產品設計和交付過程的每一步都支持用戶的需求，確保成品滿足用戶的需求、按時發貨併成功推出。同樣，產品經理還必須清除不可預見的障礙和障礙，以便團隊在將新功能帶入生活的同時儘可能提高工作效率。
請注意，此執行階段與項目管理最相關，這門學科聽起來可能類似於產品管理，但實際上只是其中的一部分。畢竟，產品經理必須在管理交付過程之前瞭解用戶的需求並決定構建什麼。項目管理本身仍然可以是一個專業領域，一些組織聘請項目經理（專注於執行）與產品經理（專注於優先級）一起工作。但在大多數組織中，產品經理仍然負責從項目管理到功能發佈，並確保所有團隊成員都對構建該功能的原因保持一致。