區(qū)別于產(chǎn)品經(jīng)理，“產(chǎn)品功能經(jīng)理”往往是指剛?cè)胄械男氯?，他們所在的職位正在做的事情一般是完成上級領(lǐng)導傳達的一個個功能指令，而不會獨立地負責某一模塊。

背景介紹

什么是產(chǎn)品功能經(jīng)理？區(qū)別于大家理想中的PM，剛?cè)胄械耐瑢W往往只是產(chǎn)品功能經(jīng)理。不會獨立承擔一個模塊，大部分需求都來自于自己leader直接傳遞，加個頁面？改下交互？增加個字段？

這種模式試用于各個大小公司，PM都是從一個個功能成長起來的，脫離功能層面去理解需求才能快速從功能進階為模塊。

雖然和大家理想中調(diào)研市場，引領(lǐng)大家開創(chuàng)一個全新業(yè)務(wù)的工作有點區(qū)別，但是如何做好一個功能經(jīng)理也是需要大家不斷總結(jié)的。下面從整個業(yè)務(wù)流程簡單概述下如何從一個新人過度為一個合格的PM：

一、理解需求

逆向推倒，從用戶需求到用戶目標

需求來源也許只有l(wèi)eader的一句話，也許只是一封郵件，甚至可能只是一條qq消息。但是往往話越少，需要做的也就更多。

首先得明確需求和目標絕對不是一碼事。

需求的正常描述語句是：我需要增加/修改某個功能/頁面；例子，領(lǐng)導給你說，小王，把我的桌子收拾一下。

目標的描述語句是：我希望獲得某種收益；例子，領(lǐng)導告訴你，小王，我希望能夠及時找到自己想要的文件。

區(qū)別在哪里？做需求，你只用把桌子的東西擺整齊，筆記本和文件擺在一起，桌子擦一遍就可以了；實現(xiàn)目標，你需要把每種文件分類，草稿紙堆一邊，合同堆一遍，筆記本又得堆一遍。

領(lǐng)導只有一句話，我怎么才能知道目標呢？逆向推到，從結(jié)論到原因，從現(xiàn)象到本質(zhì)。一個功能一般只有一個目標，一個目標可以對應(yīng)多個功能，這也是敏捷開發(fā)中強調(diào)的用戶故事。

《用戶體驗要素》對需求劃分了五層，大多數(shù)人只會在框架層和表現(xiàn)層思考問題。拿到需求就想著該怎么設(shè)計交互，這個按鈕放在哪里，那個表單應(yīng)該怎么排列。越表層的東西越應(yīng)該放在最后去思考，拔高自己的層次。思考用戶為什么會有這樣的需求，學會思考，多多在生活中嘗試這樣的逆向思考，為什么火車站的餐飲口味都非常一般？為什么現(xiàn)在的大學生都要自學編程？透過現(xiàn)象看到本質(zhì)是你從功能經(jīng)理到PM的第一步。

回溯需求，場景化功能

理解用戶真正的使用目標后還是需要回溯到需求，從需求適用的場景去思考如何設(shè)計一個完備的功能。

為什么需要落實到某一個具體的場景？最大的好處是帶入用戶的體驗感，其次是遍歷所有的可能性，避免設(shè)計方案有所遺漏。

需求是用戶目標的落地方案，一個目標一定可以通過多個需求來滿足，如何選擇最優(yōu)的體驗以及在資源有限的情況下選擇效益最高的功能是PM最核心的技能。

如何場景化？

根據(jù)《交互設(shè)計精髓4》的介紹，應(yīng)該是用戶調(diào)研。從市場調(diào)研到persona的建立，是場景化的前提。很遺憾的是，大多數(shù)功能經(jīng)理以及產(chǎn)品經(jīng)理都很很少有機會去做一次專業(yè)的用戶調(diào)研。

那么，比較折中的方案就是自己去使用產(chǎn)品或則在產(chǎn)品沒交付前去試用原型。當然，人都難以避免會帶入主觀性，所以得及時剎車，避免過度設(shè)計和滿足不存在的需求。

市面上有一套比較成熟的方案，5W2H法可以協(xié)助我們及時矯正。

場景化本身并不是一件多困難的事情，但是大多數(shù)產(chǎn)品往往會習慣性忽視這一步，這也是為什么我們的PRD會經(jīng)常被開發(fā)挑戰(zhàn)的原因。

不能落實到用戶具體的使用場景就會出現(xiàn)設(shè)計遺漏，舉一個經(jīng)典的例子，某個導航類的app一個核心流程就是幫助用戶換乘地鐵，app此時會在界面上標識換乘地鐵的終點站，只有帶入用戶場景才知道，在匆忙換乘的期間，你第一眼看到的一定是下一站的幾個大字。

如何快速讓你知道換乘地鐵的方向？Where？When？兩個核心指標可以快速帶入用戶的場景。

二、方案設(shè)計

不急于頁面設(shè)計

新人產(chǎn)品最大的誤區(qū)就是以為產(chǎn)品的職責就是交互，提供一個可用的界面給用戶。這樣的設(shè)計思路弊端實在太多，基于此類思想的設(shè)計方案往往靈活性不夠，也不能滿足用戶的真實目標，最終的結(jié)果往往是推到從來。

下面著重介紹新人往往會忽略的兩點：
（1）優(yōu)先梳理流程

理解客戶的需求后，第一步應(yīng)該是梳理業(yè)務(wù)流程，把整個方案形成閉環(huán)，從trigger到action，以及各種失敗的異常情況都應(yīng)該包含在整個流程中。

流程過于復雜時可以逐層細化，從用戶目標逐層拆解到產(chǎn)品功能，需要注意的是頂層到底層一定是一對多的關(guān)系。

梳理流程時需要根據(jù)實際需求選擇流程圖還是泳道圖，一般來說當整個交互過程設(shè)計到多個用戶角色時用泳道圖更為合適，也方便開發(fā)同學理解業(yè)務(wù)之間的耦合關(guān)系。

注意流程圖的撰寫規(guī)范，圓角的矩形表示狀態(tài)，平角的矩形表示動作，菱形表示判斷，以及更為多線框的矩形表示子流程。

如何畫一幅完美的流程圖？

1. 首先明確用戶的輸入和期待的輸出，將中間的交互過程想象成一個黑匣子，只關(guān)心用戶最初始的操作和期待最終的結(jié)果。用注冊這個功能舉例，用戶最初始的操作就是請求注冊，期待最終的結(jié)果就是注冊成功獲得賬號。那么在流程圖這個階段，表單有哪些字段，對應(yīng)的交互策略是不重要的，只用假設(shè)現(xiàn)在你的表單一定的完美的交互形態(tài)就行。
2. 將中間流程拆分。這個時候就需要將流程細化到每一個步驟，最理想的狀態(tài)每一個步驟都對應(yīng)后端的一個接口調(diào)用。還是以注冊功能為例，提交表單就是一個步驟，如果使用注冊賬號就顯得有些含糊不清了，因為對于后臺而言，提交表單和生成User是兩件事情。
3. 補充子流程。這個時候就是展現(xiàn)你產(chǎn)品功力的時候了，對于異常事件的遍歷是給開發(fā)同學最好的幫助，網(wǎng)上有很多現(xiàn)成的功能自查表，當然流程圖不用細致到交互層面，總結(jié)出主干以及支線的流程就可以了

（2）建立數(shù)據(jù)字典

為什么需要數(shù)據(jù)字典？這個問題其實和網(wǎng)上爭論很久的產(chǎn)品經(jīng)理需不需要懂技術(shù)有很大的關(guān)聯(lián)性。我的觀點是，產(chǎn)品經(jīng)理是一定需要懂技術(shù)的，當然不需要像開發(fā)同學那樣能寫實現(xiàn)的代碼，但是邏輯層面的數(shù)據(jù)流轉(zhuǎn)，PM是必須要懂的，至少在開發(fā)同學設(shè)計庫表時能夠參與進來，從業(yè)務(wù)發(fā)展的角度上給予一定幫助。

為什么產(chǎn)品要提前建立數(shù)據(jù)字典？看起來和產(chǎn)品沒有多大關(guān)系的事情，其實是我們PM的核心能力。無論是優(yōu)化現(xiàn)有功能還是新增一個功能，對于背后涉及的字段我們必須提前想清楚。

1. 從業(yè)務(wù)層面去理解數(shù)據(jù)字典。產(chǎn)品的每一個功能都不是孤立的，我們在構(gòu)想數(shù)據(jù)字典時得提前考慮功能之間的耦合關(guān)系，這樣我們才能定義好每個功能的輸入以及輸出。產(chǎn)品不會是表單設(shè)計的最終決定人，但一定是表單框架的直接影響人。以評論這個功能為例，我們在設(shè)計頁面時得提前列出所有的信息元素，評論人，評論時間，品論內(nèi)容，評價分值……其實這些信息元素就是后臺的數(shù)據(jù)字典了。
2. 從界面的角度去理解數(shù)據(jù)字典。比如注冊功能的表單，我們得提前列出所有涉及以及新增的字段，反復推敲哪些字段是必須的，哪些是可以省略的，哪些是作為選填的。產(chǎn)品的職責就是簡化流程，對于表單類的產(chǎn)品就是減少客戶需要輸入的表單，能自動填寫的一定不用客戶去填，能有Suggestion提示的，一定要提示客戶自動補全。那么這些填充以及補全的字段，我們都得提前想清楚。

三、建立反饋

1. 建立數(shù)據(jù)指標

版本上線不代表就已經(jīng)交付成功了，產(chǎn)品方案設(shè)計完的第一件事就是建立數(shù)據(jù)指標。對于新人產(chǎn)品往往會存在以下幾個誤區(qū)：

1）數(shù)據(jù)不重要

大多數(shù)新人產(chǎn)品在剛踏入工作的時候，對于一個版本迭代其實沒有太大的監(jiān)控意識。版本Review可能更多是對Bug的回溯，不會主動去看線上數(shù)據(jù)的好壞。

對于所有的PM而言，沒有數(shù)據(jù)監(jiān)控的迭代就是蒙眼狂奔，累功能的結(jié)果就是大多數(shù)功能都沒客戶使用。所以即使是產(chǎn)品功能經(jīng)理也得有數(shù)據(jù)監(jiān)控的意識。

2）虛假繁榮指標

剛開始分析數(shù)據(jù)的時候容易找不對門路，建立監(jiān)控指標的時候往往只看到自己想看到的。比如我們?nèi)タ磾?shù)據(jù)的變化效果時，往往會忽略其他因素帶來的影響。這類例子也實在太多，比如一個廣告推薦位帶來的數(shù)據(jù)上漲不能反饋功能優(yōu)化的結(jié)果，短期的上漲無法告訴你這個迭代我們做對了。

3）指標過多

有了一定入坑經(jīng)歷后，我們往往會特別慎重起來，監(jiān)控一個功能會把所有能用的數(shù)據(jù)都查一遍，這樣的結(jié)果就是有漲有跌，最后還是拿不準該干什么。這個時候一定要記得，一個產(chǎn)品在不同的階段一定只有一個唯一的關(guān)鍵指標，所有的迭代效果都以這一個指標為準。比如你看注冊功能，最終的標準就是轉(zhuǎn)化率，表單填寫比率只是一項輔助指標，只有當你分析具體原因的時候才需要拆解更多的指標觀察。

2. 上線分析

結(jié)合指標和功能，分析數(shù)據(jù)指標產(chǎn)生差別的原因。所有的指標都是可以量化的，也就是說迭代的效果一定是好與不好，沒有其他的情況。先根據(jù)唯一的指標明確本次迭代的最終效果，然后再提出假設(shè)，逐層拆解指標去驗證假設(shè)。

3. 迭代計劃

達到了預期目標，可以總結(jié)產(chǎn)品經(jīng)驗應(yīng)用到其他功能。

沒有達到預期目標，需要深究用戶實際行為和預期行為產(chǎn)生差異的原因。為下一次的迭代做好理論支撐。

最后

產(chǎn)品功能經(jīng)理是我們成為真正PM的第一步，也許目前你還不是一個業(yè)務(wù)模塊的負責人，但是做好一個功能的PM也是值得我們深挖的事情。

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

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