產(chǎn)品經(jīng)理的最大作用是將需求轉(zhuǎn)化為產(chǎn)品或者功能，從需求到功能，會經(jīng)歷哪些過程？本文總結(jié)了從需求到功能的轉(zhuǎn)化過程，希望對你進一步了解有所幫助。

“大部分的產(chǎn)品經(jīng)理特別是數(shù)字化產(chǎn)品經(jīng)理其核心價值就是如何去解決如何把需求轉(zhuǎn)化為用戶可使用、易使用、愛使用的并能夠解決業(yè)務(wù)實際問題的功能或產(chǎn)品?！?/p>

01 概述

產(chǎn)品經(jīng)理最大的作用就是把需求轉(zhuǎn)化為產(chǎn)品（由很多功能組成的系統(tǒng)，如果放在實物領(lǐng)域就是能夠滿足人們某些特定需求的載體），看了很多產(chǎn)品經(jīng)理的工作方式，這10多年也和很多產(chǎn)品經(jīng)理有合作過也了解他們的工作方式，發(fā)現(xiàn)從需求轉(zhuǎn)化為產(chǎn)品其實是一件很麻煩、很難的事。

一般來說從需求到產(chǎn)品大概可分為這幾個階段：用戶調(diào)研、市場分析、產(chǎn)品規(guī)劃、需求收集、需求分析、代碼開發(fā)測試、試運行、上線、迭代升級。

一般的產(chǎn)品經(jīng)理很難負責(zé)所有的環(huán)節(jié)，只有是某一個產(chǎn)品的負責(zé)人才會對整個過程負責(zé)，大部分的產(chǎn)品經(jīng)理都是在產(chǎn)品規(guī)劃到代碼開發(fā)測試 這部分環(huán)節(jié)開展工作，而這個階段也是把需求轉(zhuǎn)化為功能的關(guān)鍵階段，解決的是做什么的問題。

在這個階段之前都是處于規(guī)劃、設(shè)計階段，更多的是論證可行性，在這個階段之后只是把已經(jīng)確定的系統(tǒng)實現(xiàn)出來更多的是資源、時間、進度的問題，而只有這個階段會決定用戶使用你產(chǎn)品的體驗會如何，產(chǎn)品功能是如何能夠讓用戶獲得價值的。

很多產(chǎn)品經(jīng)理忽視了這個階段最本質(zhì)的價值輸出，陷入了一種解決問題的天性中了，用戶的需求即是他所面對的問題或者是體驗很差，產(chǎn)品經(jīng)理在撲捉到用戶的需求后立即想的是如何去解決這個問題，缺少對真實訴求的分析，也缺少從系統(tǒng)設(shè)計的整體性層面去進行需求分析。

02 從需求到功能

大部分的產(chǎn)品經(jīng)理特別是數(shù)字化產(chǎn)品經(jīng)理其核心價值就是如何去解決如何把需求轉(zhuǎn)化為用戶可使用、易使用、愛使用的并能夠解決業(yè)務(wù)實際問題的功能或產(chǎn)品。

想要體現(xiàn)這個核心價值，產(chǎn)品經(jīng)理不能成為用戶的傳話筒，一定要能夠透過現(xiàn)象看到用戶的真實訴求、底層需求，要看到情緒層面、價值層面的邏輯；也需要考慮系統(tǒng)整體架構(gòu)的合理性，能夠從業(yè)務(wù)、應(yīng)用、數(shù)據(jù)、體驗等不同維度去思考如何進行設(shè)計。

我舉幾個例子，看看大家在日常工作中有沒有遇到啊。

故事一：有一次在評審活動類型的產(chǎn)品需求時，只看到了前臺商城上面的頁面，并沒有對應(yīng)活動配置的頁面，問產(chǎn)品活動時間如何控制、活動價格如何控制、活動庫存如何控制皆無法回答，和其討論時來了一句用戶只提了這些需求，產(chǎn)品不是業(yè)務(wù)的傳話筒和原型設(shè)計人員，我們是產(chǎn)品經(jīng)理，我們需要搞清楚產(chǎn)品功能上每個字段、每個交互后面的邏輯、含義。

故事二：在幾年前，我們做過一個電商重構(gòu)的項目，當(dāng)時我負責(zé)商品、交易相關(guān)的功能模塊，在設(shè)計商品模塊時由于自己經(jīng)驗也有限，只能從過往比較粗淺的經(jīng)驗以及在網(wǎng)上找到的一些資料出發(fā)去進行功能設(shè)計。看到了一個完整的電商商品的功能結(jié)構(gòu)-SPU+SKU的體系，當(dāng)時把這個體系抄過來后還洋洋得意，感覺自己能夠?qū)崿F(xiàn)如此復(fù)雜的功能模塊也是蠻厲害的，但上線之后發(fā)現(xiàn)很多問題，在電商的商品模型里面缺少供應(yīng)鏈所需的業(yè)務(wù)邏輯，更多的是站在如何對商品進行售賣的角度出發(fā)，但商品的庫存如何管理、采購環(huán)節(jié)需要什么關(guān)鍵信息、財務(wù)對商品又有一些什么需求并沒有在模型中進行提現(xiàn)，導(dǎo)致后期在上線后各方使用商品數(shù)據(jù)時還是比較混亂、無序。

故事三：設(shè)計一個移動端代客下單的功能，在產(chǎn)品經(jīng)理和用戶進行詳細的需求調(diào)研、分析后，設(shè)計的整體用戶操作路徑為：訂單列表頁-新增訂單頁-選擇商品頁-填寫商品下單信息-回到新增頁-循環(huán)以上步驟，只支持單個單個商品操作，在選擇商品的頁面提供了搜索框和篩選條件，支持按商品名稱、編碼、規(guī)格搜索，支持按品牌、規(guī)格以及其它屬性進行篩選。從邏輯上面看這個功能設(shè)計的完全沒有問題，但在上線后，卻成為了員工們吐槽最多的功能。為什么呢？我們?nèi)フ{(diào)研了吐槽的實際使用人員，主要以下原因：

• 操作步驟太繁瑣，在一些訂單中經(jīng)常會有超過5個以上的商品，用戶一次只能選擇一個商品操作，意味著下這個單需要至少操作25個動作；
• 在選擇并填寫好一個商品后，該商品顯示在了列表最后，但選擇完以后還需要用戶填寫一些內(nèi)容，讓大家還需要增加一個下滑的操作；
• 在選擇商品的業(yè)務(wù)雖然支持了搜索和篩選，但是在搜索結(jié)果的排列上出現(xiàn)了問題，系統(tǒng)中有大量的很少使用的商品會排在列表中，影響大家快速找到自己想要的商品，等等在這一個功能上還有很多用戶吐槽的點。

以上的一些故事，相信大家可能也有遇到過類似的情況，而這些都是一個產(chǎn)品經(jīng)理不夠成熟的表現(xiàn)，一個成熟的產(chǎn)品經(jīng)理是能夠具備良好的從需求轉(zhuǎn)化成功能的能力，而不是簡單的去實現(xiàn)功能。要做好這種轉(zhuǎn)化工作需要產(chǎn)品經(jīng)理具備一些專業(yè)的知識。

所有的系統(tǒng)功能都應(yīng)該是為了業(yè)務(wù)落地的，業(yè)務(wù)在網(wǎng)絡(luò)空間的一種映射，比如說：庫存管理中有出入庫單，對應(yīng)的就是實際業(yè)務(wù)中的出入庫操作；商品管理中有上下架功能，對應(yīng)的其實就是現(xiàn)實業(yè)務(wù)中上下架商品的業(yè)務(wù)；在比如交易過程中有加入購物車、下單、支付等功能，其實也是對應(yīng)我們現(xiàn)實購物場景中的實際操作。

我們要想做好需求轉(zhuǎn)化為功能的過程，第一步就是能夠?qū)I(yè)務(wù)進行抽象建模，我們需要梳理清楚業(yè)務(wù)流程是從哪到哪，每一個環(huán)節(jié)涉及的角色、操作、處理邏輯有哪些，是怎么樣的，也需要明白這個業(yè)務(wù)流程最終給哪些用戶輸出了什么樣的價值。我們在做產(chǎn)品策劃的過程中腦子里面時刻要記住系統(tǒng)是業(yè)務(wù)在網(wǎng)絡(luò)空間的映射，脫離了業(yè)務(wù)流程、業(yè)務(wù)場景去設(shè)計功能都是閉門造車。

業(yè)務(wù)流程分析：

對業(yè)務(wù)進行梳理后，我們真正進入了需求分析的過程中，很多同學(xué)到這個階段不知道如何去開展工作，只能簡單的從需求中提煉一些表面的信息，直接去進行產(chǎn)品原型的設(shè)計，以為原型出來產(chǎn)品策劃的工作就基本完成了，這是打錯特錯的，你這樣做之后大部分的情況會陷入我們上面講的三個故事一樣的境地。

系統(tǒng)是業(yè)務(wù)在網(wǎng)絡(luò)空間的映射，在網(wǎng)絡(luò)空間中建設(shè)系統(tǒng)至少要在這幾個維度上去進行設(shè)計：數(shù)據(jù)結(jié)構(gòu)、代碼邏輯、頁面交互，當(dāng)然還需要在物理環(huán)境、網(wǎng)絡(luò)環(huán)境層面進行設(shè)計，但這些與產(chǎn)品的工作關(guān)聯(lián)性不大。

軟件系統(tǒng)說的簡單點就是使用角色對系統(tǒng)進行輸出，系統(tǒng)更具代碼邏輯做出必要的反應(yīng)，給出輸出。

在前面業(yè)務(wù)分析的過程中我們梳理出來了角色、操作、處理邏輯以及每個節(jié)點的輸入和輸出，這些內(nèi)容是我們做需求分析最核心的輸入，我們需要把這種業(yè)務(wù)語言轉(zhuǎn)換成軟件語言，我們可以從這些內(nèi)容中提煉出關(guān)鍵的名詞、動詞以及一些限定詞匯，關(guān)鍵的名詞往往是我們功能操作的主要對象，我們也可以稱之為實體或?qū)ο?，為了表達它們我們需要對這些概念進行定義，并通過主要的屬性以及生命周期去把定義顯性化，不同概念的差別也主要提現(xiàn)在了這些地方。

提煉出實體后，我們還需要去梳理各個實體之間的關(guān)系，能夠明晰哪些實體的變化會對其它實體有影響，影響是什么。這部分的分析結(jié)論，不是一蹴而就的，也是需要反復(fù)推敲琢磨的。能夠有類似以下的一些輸出物：

實體模型：

狀態(tài)機：

狀態(tài)描述：

以上的過程我們更多是在數(shù)據(jù)結(jié)構(gòu)層面進行梳理，在這個過程之后我們還需要對業(yè)務(wù)邏輯進行抽象分析，我們需要能夠詳細定義如何去獲取或者接受輸入信息，輸入的信息有哪些內(nèi)容，傳輸?shù)姆绞绞鞘裁礃拥?，頻率如何，如果發(fā)生了極端情況我們?nèi)绾翁幚怼?/p>

然后我們需要對每個節(jié)點的業(yè)務(wù)邏輯進行分析，形成結(jié)構(gòu)化的語言去進行描述，在系統(tǒng)中大部分的業(yè)務(wù)邏輯都是需要通過操作或者是系統(tǒng)自動的方式去觸發(fā)它，而具體的操作也是我們?nèi)ミM行業(yè)務(wù)邏輯結(jié)構(gòu)化描述的起始點，從這里開始我們逐步分析這個操作對哪些實體有影響，影響了實體的哪些屬性的變化，這些影響是怎么樣去生效的，在系統(tǒng)中業(yè)務(wù)邏輯說到底就是用戶的操作對數(shù)據(jù)產(chǎn)生變化或者是能夠?qū)τ脩糨敵鎏囟ǖ囊恍┬畔⒌囊?guī)則、步驟，我們在描述這些規(guī)則、步驟的時候一定要互相獨立、完全窮盡，做到不遺漏、不重復(fù)。

最后我們還需要分析清楚當(dāng)前的這個環(huán)節(jié)對后續(xù)那個流程節(jié)點或者是角色有影響，我們需要定義用何種方式去對影響他們，是通過實體屬性的變化產(chǎn)生了影響，還是通過下游環(huán)節(jié)輸入的形式，亦或者只是需要提醒或通知到某些角色即可。

通過以上幾個環(huán)節(jié)，我們把產(chǎn)品功能設(shè)計中最為抽象的部分做完了，但在產(chǎn)品功能設(shè)計的工作中還有具象化的部分的工作，那就是如何把信息呈現(xiàn)并與用戶產(chǎn)生互動，這兩步的內(nèi)容我們可以參考用戶體驗要素的模型中最上面三層：結(jié)構(gòu)層、框架層和表現(xiàn)層。

1. 結(jié)構(gòu)層。關(guān)注產(chǎn)品的信息架構(gòu)和交互設(shè)計，信息架構(gòu)涉及如何組織和呈現(xiàn)內(nèi)容元素，以促進用戶理解，交互設(shè)計涉及用戶如何與產(chǎn)品互動，包括點擊、填寫表單等操作。
2. 框架層。關(guān)注產(chǎn)品的頁面布局和導(dǎo)航結(jié)構(gòu)，包括banner的位置、按鈕的位置等，確保產(chǎn)品易于導(dǎo)航和使用。
3. 表現(xiàn)層。關(guān)注產(chǎn)品的視覺傳達，包括色彩、字體、圖像等視覺元素，這些元素應(yīng)與產(chǎn)品的整體目標(biāo)和結(jié)構(gòu)相協(xié)調(diào)。

此處不做過多的方法論的說明，需要的同學(xué)推薦可以去看一下《用戶體驗要素》這本書。輸出物一般為功能結(jié)構(gòu)圖、用戶使用路徑圖、產(chǎn)品原型、設(shè)計稿等。

更想說的是，交互、視覺、用戶體驗這些內(nèi)容很多時候是被大部分的產(chǎn)品不太重視的，總認為邏輯正確、模式正確那產(chǎn)品一定會成功，但我想說的是大部分的用戶他們不關(guān)心或者說首先關(guān)心的不是邏輯正確、模式正確，他們首先能夠感受到的是交互、視覺、體驗，好不好用、容不容易使用是他們首先能夠感受到的，只有他對產(chǎn)品功能的印象是正面的他們才有可能繼續(xù)使用或者是能夠“友好”使用你的產(chǎn)品。

我們做產(chǎn)品設(shè)計時既要能夠“從下往上看”（從數(shù)據(jù)-邏輯-應(yīng)用-體驗），也能夠“從上往下看”以用戶視角去看自己設(shè)計的產(chǎn)品。

03 總結(jié)

以上是近期重新開始做具體產(chǎn)品設(shè)計工作的一些感悟、總結(jié)，也算是對自己這些年經(jīng)歷的不同產(chǎn)品階段工作中可能遇到的一些問題以及如何去解決的一些思考，希望對在成長過程有相似困惑的產(chǎn)品經(jīng)理有所幫助，也歡迎大家一起留言討論。