真正的產(chǎn)品，是滿足用戶需求痛點(diǎn)、給用戶創(chuàng)造快感，或者成本節(jié)約帶來的感受。這種感受既可感知，也有可能不可直接感知。

產(chǎn)品經(jīng)理到底要不要懂技術(shù)，是否技術(shù)出身的產(chǎn)品經(jīng)理一定更有優(yōu)勢呢？

對于這個(gè)問題的探討，相信各位都能在各個(gè)產(chǎn)品論壇上看到，不少產(chǎn)品經(jīng)理估計(jì)也參與爭辯過。筆者自己曾是技術(shù)出身，且剛畢業(yè)時(shí)做全棧開發(fā)若干年，也有過技術(shù)架構(gòu)經(jīng)驗(yàn)，所以對于產(chǎn)品經(jīng)理要不要懂開發(fā)，筆者認(rèn)為懂總比不懂的好，不過之前所帶過的產(chǎn)品團(tuán)隊(duì)中也有不少不怎么懂技術(shù)，但卻挺優(yōu)秀的產(chǎn)品經(jīng)理。

筆者認(rèn)為，無論是否懂開發(fā)，總會有你不懂的新技術(shù)或未接觸過的領(lǐng)域，而對于產(chǎn)品經(jīng)理而言，最關(guān)鍵的不是把功能開發(fā)出來，而是要把需求價(jià)值開發(fā)出來，要把產(chǎn)品最有價(jià)值的能力不斷挖掘，服務(wù)于用戶，才是產(chǎn)品經(jīng)理的“正事”。

那么，當(dāng)一個(gè)產(chǎn)品經(jīng)理遇到一些技術(shù)性很強(qiáng)的產(chǎn)品需求，而靠自己過往的經(jīng)驗(yàn)又很難把控的時(shí)候，又該怎么將這些需求開發(fā)出來呢？

無論是技術(shù)型需求還是業(yè)務(wù)型需求，對產(chǎn)品經(jīng)理而言，在拿到一個(gè)自己不懂或未接觸過領(lǐng)域的產(chǎn)品或模塊時(shí)，先不要慌，也不要認(rèn)為技術(shù)性需求純粹是架構(gòu)師們的事，跟自己無關(guān)。任何技術(shù)都是服務(wù)于產(chǎn)品，是為產(chǎn)品價(jià)值的輸出。

假設(shè)我們現(xiàn)在需要開發(fā)一個(gè)系統(tǒng)服務(wù)運(yùn)行健康監(jiān)控功能，這對于很多一直從事2C產(chǎn)品的同學(xué)來說，基本上都是很陌生的領(lǐng)域。當(dāng)我們拿到這樣的需求后，很可能一時(shí)間不知道該怎么辦，甚至?xí)堰@種需求直接踢給架構(gòu)師，或者研發(fā)經(jīng)理，讓他們先按自己的想法做一個(gè)出來，然后再慢慢理解后改吧改吧。

如果按此方式推進(jìn)，那必然會造成最后開發(fā)出來的功能很難用，或者浪費(fèi)很多的成本。我們一直講，產(chǎn)品經(jīng)理要有成本意識，所以是絕不能容忍上述情況的發(fā)生。

本文主要是希望所有的產(chǎn)品經(jīng)理都能按價(jià)值維的思考模型去對待任何一個(gè)需求點(diǎn)，不管是業(yè)務(wù)型還是技術(shù)型需求。

如何理解價(jià)值維呢？

“真正的產(chǎn)品，是滿足用戶需求痛點(diǎn)、給用戶創(chuàng)造快感，或者成本節(jié)約帶來的感受。這種感受既可感知，也有可能不可直接感知。”這是筆者比較認(rèn)可的“產(chǎn)品定義”，其中寫的感受，其實(shí)就是產(chǎn)品的價(jià)值。

產(chǎn)品經(jīng)理在設(shè)計(jì)任何產(chǎn)品功能時(shí)，一定要以價(jià)值作為功能設(shè)計(jì)的驅(qū)動力，這樣所設(shè)計(jì)出來的功能才是“活”的。同時(shí)，對于我們的用戶而言，使用產(chǎn)品時(shí)首先想到的是產(chǎn)品價(jià)值到底符不符合自己的真實(shí)所需，所以我們的用戶在使用產(chǎn)品時(shí)，潛意識里也是由價(jià)值來驅(qū)動對產(chǎn)品功能的使用。

我們再回到本文的主題，對于產(chǎn)品經(jīng)理拿到技術(shù)性需求時(shí)，照樣符合上面所講的價(jià)值維思考模型。那么我們從哪些方面來把握住這個(gè)價(jià)值維，或者說來處理好這個(gè)價(jià)值維，并實(shí)現(xiàn)需求落地呢？

對這個(gè)問題，筆者認(rèn)為從以下幾方面，就可以比較好地去滿足價(jià)值實(shí)現(xiàn)。

（1）聆聽用戶意圖

按照價(jià)值維思考模型，我們應(yīng)該找到使用該功能的“用戶”，去了解分析用戶為什么需要這個(gè)，能帶來什么能力，盡管一開始我們拿到的是一個(gè)偏技術(shù)的需求。如果與用戶的溝通是有效的，那么產(chǎn)品經(jīng)理就可以從很容易地勾勒出功能價(jià)值，甚至你還可以沿著價(jià)值維，尋找更有效的幫助研發(fā)找到技術(shù)實(shí)現(xiàn)路徑。

通過對功能價(jià)值的勾勒，將非常有助你去了解“技術(shù)”背后所隱藏的商業(yè)意義，這時(shí)候你會發(fā)現(xiàn)，原來這么技術(shù)性的需求，也可以通過用戶視角、業(yè)務(wù)視角、交互視角去分析，甚至還可以挖掘出更多具有商業(yè)價(jià)值的功能點(diǎn)。

（2）競品調(diào)研分析

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

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

如果你發(fā)現(xiàn)很難去找到類似的競品時(shí)，那我們又該怎么辦呢？辦法還是有的，我們可以在網(wǎng)絡(luò)中通過尋找論文、尋找文章的方式，幫助我們從不同的視角去理解、去分析手頭的case，最終的目標(biāo)還是在幫助我們分析功能的價(jià)值。

（3）構(gòu)建PRTD文檔

通過與用戶的溝通、競品的調(diào)研分析，相信作為優(yōu)秀產(chǎn)品經(jīng)理的你，一定已經(jīng)能很好地構(gòu)建出自己的實(shí)現(xiàn)思路了，甚至可以寫好了對應(yīng)的PRD。但筆者這里要友情提醒一下，如果是偏技術(shù)性的需求，如果按照一般功能需求的方式，編寫完P(guān)RD就去推進(jìn)的話，很容易出問題。假設(shè)這樣就能很好地落地，這只能說明這個(gè)并不是什么技術(shù)性需求，要么就是你們產(chǎn)品開發(fā)團(tuán)隊(duì)中有頂級產(chǎn)品和架構(gòu)師。

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

筆者認(rèn)為，產(chǎn)品經(jīng)理在完成價(jià)值分析后，就要跟架構(gòu)師一同探討，把你分析的結(jié)果毫無保留地傳遞給架構(gòu)師和核心開發(fā)人員，與他們一起構(gòu)建功能的設(shè)計(jì)，并輸出PRTD文檔，這里面的T就是指技術(shù)。

PRTD文檔應(yīng)該包括價(jià)值、用例、功能設(shè)計(jì)、原型設(shè)計(jì)、架構(gòu)分析、技術(shù)方案等內(nèi)容。輸出后，項(xiàng)目組應(yīng)該可以根據(jù)該文檔進(jìn)行功能開發(fā)，一方面可以有效控制技術(shù)風(fēng)險(xiǎn)（一般技術(shù)性需求會對技術(shù)路線有一定影響），另一方面這樣完整的輸出，可有效避免后續(xù)的返工。

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

寫在最后：

價(jià)值維思考模型是筆者多年來一直遵從的思考方案，不光用在具體的產(chǎn)品需求管理，在其他事務(wù)的處理上也是屢試不爽。在瞬息萬變的商業(yè)環(huán)境下，只有價(jià)值是永恒不變，本文的輸出就是從價(jià)值維來考慮，讓大家以后可以有更多的思考模式，開發(fā)出優(yōu)秀的產(chǎn)品。

本文由 @jiongoogle 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash ，基于 CC0 協(xié)議