真正的產品，是滿足用戶需求痛點、給用戶創造快感，或者成本節約帶來的感受。這種感受既可感知，也有可能不可直接感知。

產品經理到底要不要懂技術，是否技術出身的產品經理一定更有優勢呢？

對於這個問題的探討，相信各位都能在各個產品論壇上看到，不少產品經理估計也參與爭辯過。筆者自己曾是技術出身，且剛畢業時做全棧開發若干年，也有過技術架構經驗，所以對於產品經理要不要懂開發，筆者認為懂總比不懂的好，不過之前所帶過的產品團隊中也有不少不怎麼懂技術，但卻挺優秀的產品經理。

筆者認為，無論是否懂開發，總會有你不懂的新技術或未接觸過的領域，而對於產品經理而言，最關鍵的不是把功能開發出來，而是要把需求價值開發出來，要把產品最有價值的能力不斷挖掘，服務於用戶，才是產品經理的“正事”。

那麼，當一個產品經理遇到一些技術性很強的產品需求，而靠自己過往的經驗又很難把控的時候，又該怎麼將這些需求開發出來呢？

無論是技術型需求還是業務型需求，對產品經理而言，在拿到一個自己不懂或未接觸過領域的產品或模塊時，先不要慌，也不要認為技術性需求純粹是架構師們的事，跟自己無關。任何技術都是服務於產品，是為產品價值的輸出。

假設我們現在需要開發一個系統服務運行健康監控功能，這對於很多一直從事2C產品的同學來說，基本上都是很陌生的領域。當我們拿到這樣的需求後，很可能一時間不知道該怎麼辦，甚至會把這種需求直接踢給架構師，或者研發經理，讓他們先按自己的想法做一個出來，然後再慢慢理解後改吧改吧。

如果按此方式推進，那必然會造成最後開發出來的功能很難用，或者浪費很多的成本。我們一直講，產品經理要有成本意識，所以是絕不能容忍上述情況的發生。

本文主要是希望所有的產品經理都能按價值維的思考模型去對待任何一個需求點，不管是業務型還是技術型需求。

如何理解價值維呢？

“真正的產品，是滿足用戶需求痛點、給用戶創造快感，或者成本節約帶來的感受。這種感受既可感知，也有可能不可直接感知。”這是筆者比較認可的“產品定義”，其中寫的感受，其實就是產品的價值。

產品經理在設計任何產品功能時，一定要以價值作為功能設計的驅動力，這樣所設計出來的功能才是“活”的。同時，對於我們的用戶而言，使用產品時首先想到的是產品價值到底符不符合自己的真實所需，所以我們的用戶在使用產品時，潛意識里也是由價值來驅動對產品功能的使用。

我們再回到本文的主題，對於產品經理拿到技術性需求時，照樣符合上面所講的價值維思考模型。那麼我們從哪些方面來把握住這個價值維，或者說來處理好這個價值維，並實現需求落地呢？

對這個問題，筆者認為從以下幾方面，就可以比較好地去滿足價值實現。

（1）聆聽用戶意圖

按照價值維思考模型，我們應該找到使用該功能的“用戶”，去瞭解分析用戶為什麼需要這個，能帶來什麼能力，儘管一開始我們拿到的是一個偏技術的需求。如果與用戶的溝通是有效的，那麼產品經理就可以從很容易地勾勒出功能價值，甚至你還可以沿著價值維，尋找更有效的幫助研發找到技術實現路徑。

通過對功能價值的勾勒，將非常有助你去瞭解“技術”背後所隱藏的商業意義，這時候你會發現，原來這麼技術性的需求，也可以通過用戶視角、業務視角、交互視角去分析，甚至還可以挖掘出更多具有商業價值的功能點。

（2）競品調研分析

除了去跟你的用戶進行有效溝通外，產品經理一定要記得去尋找對應的競品。經常做競品分析的同學應該知道，有時自己想破腦袋的問題，竟然可以在競品那裡很容易地get到方案，更有趣的是從交互、功能邏輯等方面都幫你設計好了，相當於有人幫你做了一套解決方案。

不過作為一名優秀的產品經理，絕對不會是拿來主義者，筆者對這樣的做法也很不屑，但作為一種參考，幫助我們更好地去設計自己的需求，這還是沒任何問題的。

如果你發現很難去找到類似的競品時，那我們又該怎麼辦呢？辦法還是有的，我們可以在網絡中通過尋找論文、尋找文章的方式，幫助我們從不同的視角去理解、去分析手頭的case，最終的目標還是在幫助我們分析功能的價值。

（3）構建PRTD文檔

通過與用戶的溝通、競品的調研分析，相信作為優秀產品經理的你，一定已經能很好地構建出自己的實現思路了，甚至可以寫好了對應的PRD。但筆者這裡要友情提醒一下，如果是偏技術性的需求，如果按照一般功能需求的方式，編寫完PRD就去推進的話，很容易出問題。假設這樣就能很好地落地，這隻能說明這個並不是什麼技術性需求，要麼就是你們產品開發團隊中有頂級產品和架構師。

那我們還要做什麼事，才能確保需求的軟著陸呢？

筆者認為，產品經理在完成價值分析後，就要跟架構師一同探討，把你分析的結果毫無保留地傳遞給架構師和核心開發人員，與他們一起構建功能的設計，並輸出PRTD文檔，這裡面的T就是指技術。

PRTD文檔應該包括價值、用例、功能設計、原型設計、架構分析、技術方案等內容。輸出後，項目組應該可以根據該文檔進行功能開發，一方面可以有效控制技術風險（一般技術性需求會對技術路線有一定影響），另一方面這樣完整的輸出，可有效避免後續的返工。

或許你會說，那這樣就不敏捷了，像瀑布。筆者的經歷告訴你，方法是死的，人是活的，李雲龍打仗就是虛實結合，不按套路，這樣才能有意外收穫。我們要的是有效、快速地落地，而不是糾結敏捷不敏捷。

寫在最後：

價值維思考模型是筆者多年來一直遵從的思考方案，不光用在具體的產品需求管理，在其他事務的處理上也是屢試不爽。在瞬息萬變的商業環境下，只有價值是永恆不變，本文的輸出就是從價值維來考慮，讓大家以後可以有更多的思考模式，開發出優秀的產品。

本文由 @jiongoogle 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash ，基於 CC0 協議