起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識萬字分享：談談我的B端產品方法論
編輯導讀：產品經理是一個快速成長的崗位，接觸的工作越多，總結的經驗越多。本文作者從一位小白成長為B端產品經理，根據自己的工作經歷，總結了一套產品經驗，希望對你有幫助。
一、首語
假設一名產品經理需要在一小時內完成一個任務，那么前五十分鐘應該花在需求的分析上，而方案輸出應該只需要最后的十分鐘。
距離上次發文已經有一年多時間，在此期間經歷了暑期實習、秋招、畢業典禮等多個節點，在疫情的影響下仿佛一切都打上了獨特的烙印，既感慨自己終于成為一名產品人，也感慨時間飛逝。
目前我在一家B端saas企業做產品，至今大大小小產出并上線了上百個需求，出于個人習慣，想總結一套方法論方便后續需求設計，減少重復工作量的同時也能讓自己有所沉淀，夯實基礎能力。
引用的這句話是我最近在《締造企鵝》中讀到，結合自身的工作內容深有感觸所以分享給大家，也作為本篇文章的主題?；谧陨硖幚硇枨蟮娜鞒蹋覍⑵洳鸱譃槿缦鹿濣c，本文內容主要為需求前期方法論。
- 前期——發現需求、提煉需求、辨別需求、管理需求
- 中期——設計需求、把控進度
- 后期——上線后跟進
二、發現需求
發現需求這個命題比較主觀，我在工作的過程中就碰到了包括用戶調研、用戶反饋、PM自身思考、競品分析、體驗產品等多種渠道。個人覺得不需要糾結，每種渠道都有自己的優劣，或許“發現需求”可以理解為各種渠道相輔相成，例如PM進行思考后通過調研等方式驗證想法是否可行；也可能是通過調研等方式發現問題，轉而經過自己的思考去驗證問題是否存在。
“不管黑貓白貓，能抓到老鼠就是好貓”?？梢韵葟亩ㄆ谑占掠涗洝⑴c用戶簡單交流開始。重要是培養自己對于用戶、竟品、行業的敏銳度。
三、提煉需求
用戶A：我想要實現xxx功能
PM：噢，懂了，我覺得應該是這個意思，馬上出需求
——上線后——
數據極差，當時反饋的用戶也不買賬，不禁開始懷疑人生，為啥我做的功能沒人用？？
在PM日常工作中，我們會收到很多來自四面八方的需求信息，切記帶著有色眼鏡去處理信息，避免成為“自嗨型”產品經理。
了解清楚問題背景以及訴求，如果有必要可以多次求證（也需要一丟丟的換位思考能力，不要過于打擾別人hh），務必做到客觀、真實、清晰。例如用戶A跟你說希望在開車的時候也能用手機打電話：
- 場景：一個人在開車過程中，需要進行通信
- 用戶行為：一只手開車，另一只手操作手機
- 目標：快速且便捷的操作手機，最好是不需要分散太多注意力
- 效果：用戶打開應用之后，直接長按就可以實現語音操作
將繁雜的信息提煉為：用戶A在xx場景下，想通過xxx實現xxx訴求，以達到xxx的目的。
四、用戶需求≠產品需求
用戶需求并不等于產品需求，這是很多同學存在的誤區，想要將用戶需求上升為需求文檔級別，還需要經過市場與商業的考慮。
例如提煉出的某個用戶需求是“我想上傳的學習視頻能夠設置付費才能播放”，那么我們首先要問自己兩個關于市場的問題：
a.相同的訴求有多少量？（市場容量）
特定條件下，相同的用戶需求集合已達到一定量級，例如例子中的知識付費需求，我們跑數據看到產品內教育行業用戶占比巨大，且有30%的用戶希望視頻付費，那就意味著市場容量較大，可以繼續了解。
b.是否已有解決方案？（市場環境）
這個步驟主要是要了解兩個點，直接or間接競品有沒有實現知識付費功能、實現的方案是不是成熟？
那么怎么樣的需求能被稱為商業需求呢，商業需求是為實現商業目的，圍繞產品產生的運營或業務性需求，例如知識付費功能可以幫助商家打通線上獲客—轉化路徑，增加了產品售賣方式，滿足業務經營。又或者是幫助商家節省了人力成本跟時間成本，也屬于變相實現商業目的。
一個好的產品需求應該滿足用戶、市場，同時兼顧商業。
五、需求歸類&管理
過濾到這一步大概率是真需求，能夠將其放進個人需求池中，作用有兩個
- 隨著整理次數以及數量的增多，漸漸會在腦海中形成一張地圖，上面記錄著哪個部分比較多什么類型的問題，用戶關注什么？增加對產品的熟悉度
- 好記性不如爛筆頭，你甚至沒有辦法記起上周用戶調研時提到的問題，更不用說好幾個星期乃至一個月前了，養成記錄的習慣，對自己負責更是對產品負責
- 需求前期調研可以到池子中試著搜索下，能幫你補全場景或者發現該需求上游環節、下游環節存在的問題，提高需求產出質量
由于筆者是做b端saas產品，從一個垂類場景切入結合上企業業務需求，產品涉及的功能模塊較多，再加上踩過好幾次坑。目前采用如下圖所示字段對收集回來的需求進行整理歸類
- 類型：分為功能、樣式、運營、數量、體驗、tips六個屬性，該字段的目的是對需求進行粗分類，即需要新功能來滿足還是小需求fix掉，結合記錄時間甚至可以評估某個時間段內什么類型需求較多
- 所屬模塊：指的是產品哪部分的需求，最小粒度到具體功能模塊，該字段的目的是方便篩選哪個模塊需求出現頻次最高，集合“類型”字段甚至可以優化整個用戶路徑不局限在小功能點上
- 反饋場景：言簡意賅說明需求背后的場景，方便溯源時定位問題所在
- 優先級：目前這個字段我僅會在緊急需求例如風控、跨部門協作時備注，平時不做填寫。因為一開始在這個字段踩坑，會在記錄需求的當下進行主觀判斷高、中、低，但需求管理是一個長時間的過程，反而會疑惑當時定優先級的初衷，很少東西是一成不變的，導致沒有達到“管理需求”目的
- 記錄時間：何時記錄該需求，方便結合“類型”、“所屬模塊”做周期性的復盤以及整個用戶路徑的優化
- 上線時間：需求上線時間，由于需求進入規劃狀態會納入另一個表格管理，所以沒什么填寫的必要，后續考慮去掉該列降低干擾
- 備注：隨機應變，懂得都懂
- 任務進度：同“上線時間”?？紤]廢棄降低干擾
至于需求管理我是有兩份表格，上文提到的“個人需求池”以及“項目管理表”，前者記錄未規劃的需求，后者按不同的項目分sheet記錄已經在工作流程中的需求。兩份表格會在每周周一早上、周五下班前更新。
甚至我會在“項目管理表”中單獨開一個sheet記錄當前版本上線的需求，目的也是為了監控進度，保證需求按質按量上線。（遇到推不動的情況，也能提前向上反饋，避免撕逼）
六、需求如何策劃
目前我接手過的需求分為三大類
- 功能類：實現xx功能，相對來說需求調研、邏輯能力要求較高；
- 樣式類：通過xx功能去還原xx樣式，相對來說邏輯沒那么重，抽象歸納以及需求細節能力要求較高；
- 運營類：通過xx手段去達到xx目的，相對來說全局意識、數據思維、腦洞要求較高；
本篇文章會著重講功能類的需求如何策劃，樣式與運營類的會單獨開一篇文章說明
七、舊功能梳理
我負責的產品至今已有十一年，期間經過n個pm的手，記錄工作也做的比較差，經常會出現“貨不對版”或是“一句話需求”的情況。所以我在策劃每個需求的時候，都會主動花時間梳理舊邏輯。
無論是什么類型的功能需求，即使是全新的功能，我也非常建議大家去輸出對應功能模塊的兩種腦圖。“信息結構圖”和“功能結構圖”。
這兩種類型的腦圖在搜索引擎中已經有無數篇學習文章，還記得一開始學習產品知識，經常會弄混這兩種類型的圖，后續基于琢磨與實踐，也有了自己的理解，下面會簡單說說兩者的意義與區別。
1. 信息結構圖
信息結構圖指的是窮舉頁面/功能中每一個元素，最小粒度我一般用設置項。要做到事無巨細，防止遺漏。為了便于大家理解，我舉了個微信的例子，微信中「設置」-「我的」tag信息結構圖如下圖所示，大家可以對照著產品琢磨琢磨。
信息結構圖可以幫助我們了解舊模塊的“構造”，特定的選項下是否有個性化的設置，能夠高效的了解舊模塊/功能全貌。
2. 功能結構圖
百度百科：按照功能的從屬關系畫成的圖標，在該圖標中的每一個分支都被稱為一個功能模塊。功能模塊可以根據具體情況分得大一點或者小一點，分解最小功能模塊可以是一個程序中的每個處理過程，而較大的功能模塊則可能是完成某一個任務的一組程序
上面百度百科的定義有些繞，我自己理解功能結構圖指的是頁面中所有的功能，最小粒度是用戶可使用的功能。類似鳥瞰的視角。同理在微信中「設置」-「我的」功能結構圖如下圖所示，大家可以對照下，相比信息結構圖，兩者之間的區別是什么。
揭曉答案：功能結構圖與信息結構圖的區別是前者注重抽象信息，后者注重羅列信息。
通過信息結構圖與功能結構圖的梳理，可以幫助我們從縱向、橫向兩個維度了解當前功能模塊的“前世今生”，避免在策劃階段走彎路，提高工作效率。
當然，如果是一些邏輯非常復雜的功能模塊，也可以去公司研發管理平臺（我司是tapd）以功能模塊為關鍵詞去搜索下歷史需求，看看是否有AB測試或特殊的兼容邏輯。
產品經理梳理完成后，如果有條件可以讓有經驗的測試、開發同學幫你稍微看一眼，防止遺漏（開發過程中才發現的特殊兼容邏輯，導致方案部分推倒重來的經歷，真的太痛了）。
八、新功能拆解
8.1 需求調研
想要理解需求，永遠離不開用戶、場景、訴求。我會將這部分分為內、外兩個維度去介紹日常工作中如何進行需求調研工作。
8.1.1 內部
搜索工單&用戶反饋&建議：
工單常見于平臺型產品中，用戶可針對使用過程中的問題、未滿足的功能，通過文本、圖片、參考鏈接等元素直接與PM溝通，PM閱讀后會做出對應的回復，可以發起二次溝通，或者打上標簽完結本次溝通。一次溝通等于一條工單。
現階段我獲取需求最直接最有效的渠道就是工單反饋。用戶可以暢所欲言，甚至見過附上axure原型圖的，對于PM也更利于管理，你可以在固定時間如剛到公司的半小時、臨近下班的半小時集中精力處理。
在處理工單的過程中，大家可以猜一猜我回復頻次最高的一句話是什么
「已經收到您的反饋，想了解下您是在什么場景下需要xx功能/有xx訴求呢，可以詳細說說，若條件允許也可以附上對應的截圖或鏈接，方便我們了解問題所在」
是的，在需求調研過程中，最忌諱PM想當然，“噢用戶說的應該是這個問題，馬上需求排期跟進”的思維不可取，雖然這樣處理效率很高，但最后有很大可能你根本沒有解決用戶遇到的問題。
那要怎么做才能真正解決問題呢？
首先是了解用戶；
我從處理第一份工單至今一直保留著一個習慣，就是會抽樣去看工單歸屬用戶的實際使用情況，尤其是考慮排期的工單需求，通過抽樣我可以知道用戶所在的行業、使用產品的目的以及使用的情況。例如用戶提出了一個“非常緊急”的表單模塊訴求，實際抽樣中發現用戶已付費，且使用產品的主場景并不是獲客留客，也沒有使用表單模塊。那你就要留點心，這意味著這個訴求要么是必須型需求，已經影響到主流程無法使用，要么只是用戶心血來潮，你可以帶著疑問發起二次溝通。是不是了解用戶后，看問題的角度不同了呢。
其次是明確場景；場景是時間與空間的結合，代表某個人，在某個時間點某個地點，做了什么事（起因、經過、結果）。
什么模塊？哪個頁面？如果是優化類的工單要以能否復現作為標準，如果是新功能要以能否理解作為標準。其實產品經理的工作內容，就是去創造新的目標場景，或是優化已有場景，并在這些場景下滿足用戶的需求
最后是挖掘訴求：
人永遠是情感世界的產物，想要永遠客觀公正的做出判斷是不可能的。就好像上文提到的工單例子，如果用戶真的是心血來潮提出的訴求，我們花了很大成本去實現，那最后肯定是投入產出比較低的。
由于成本的限制，產品經理不可能無時無刻坐在用戶旁邊觀察他的行為。所以我們要用各種方法去挖掘用戶真實的訴求，在這里分享我經常用的「需求拆分法」給大家，例如：
“用戶/我想吃麥當勞
PM/為什么？
用戶/跑完步，有點餓（知道了場景和冬季）
PM/腸粉行不行（換了一個替代方案，看下能否滿足）
用戶/想吃麥辣雞翅（發現了更深一層的需求，麥辣雞翅是麥當勞的子集）
PM/麥辣雞腿行不行？（替換掉解決方案中的一個元素，看下能否滿足）
用戶/想吃雞翅（得到了更細節的需求）
PM/燒雞翅呢？（假設麥當勞并不售賣燒雞翅，所以找到了用戶的替換需求）
用戶/也可以”
….
ps：這個思路是之前在一篇關于需求調研的文章看到，覺得非常有意思便記錄下來，一直沿用至今
這種類似打破砂鍋問到底的方法，通過對用戶回答的層層拆解，最后找到用戶真實的需求，是比較有意思的。當然，上述內容只是方便大家理解挖掘的思路。在現實工作中幾乎不可能會遇到如此溫文爾雅的用戶會耐心回答你的每個問題（要是真的遇到了，可以好好跟他培養下感情哈哈哈），所以我們得從其他渠道，例如抽樣、瀏覽該用戶每條客服會話內容去補充細節。那么在產品設計階段，我們只需要去思考拆解到最后的問題即可。
總之在需求挖掘的過程中盡量做到”無我”，清空自己的主觀判斷，傾聽用戶的聲音，不要摻雜太多主觀意見、不要離開用戶群尤其是核心用戶群去判斷需求，不要脫離場景去想需求，從用戶提出的需求出發，去偽存真挖掘用戶內心真正的目標。
搜索客服會話：
如果說工單是問題抽象化的表現，那么客服會話就是問題具像化的表現
客服會話指的是用戶在使用產品時，通過不同的頁面入口發起跟我司客服同學的聊天窗口，用戶可以通過文字、圖片等元素去發起在線溝通。
因為客服會話工具的時效性，所以相對于工單會有更詳細的場景與訴求描述，方便PM獲取有用的信息。
也可以通過搜索關鍵字的方式，抽樣去看這個周期內有多少條會話與搜索關鍵詞相關，從而了解用戶與場景的共性，為挖掘真實需求提供燃料。
其他部門同事：
若需求內容與其他部門相關，或是其他部門同學提出，則需要主動發起詢問，了解清楚事情的背景和目的，這里更多涉及溝通技巧方面的知識，僅舉例接觸過的坑，不做展開
- ownship意識，即使發起方不是自己的業務，也要像自己產出的需求一樣對待它；
- 遇到問題，及時同步。（再小的問題也會造成連鎖反應，降低效率）；
- 不能隨便給同事承諾，尤其是銷售、客服等對外的角色，要學會讓他們做閱讀理解以及留多些空間給自己；
8.2.2 外部
競品調研：
可以毫不夸張的說，目前我們想實現的新功能，幾乎99%都能在市面上的產品中找到類似的影子，所以競品分析相對需求調研乃至整個產品工作流中都非常重要。
在我剛畢業的那段時間，還沒有瀏覽競品的意識，在做需求的時候偶爾看一看，直到有一次leader問我“xxx、xxx競品最近的動作是什么？”我啞口無言。這樣閉關鎖國的行為不可取，不僅會讓一個PM喪失對所在行業的敏感度，還容易陷入自我滿足的怪圈。
所以我之后做的第一件事，就是把幾個直接競品的功能更新渠道找出來，按橫軸-產品名稱、豎軸-時間軸的形式，如下圖所示。每周一早上抽十來分鐘填一填更新內容。隨著文檔的一次次被編輯，我對競品也越來越了解，知道它們這段時間都在拓哪個方面的需求，結合產品定位有更深入的思考；在做需求的時候也可以反應過來“噢，我記得xx上幾周貌似做了個類似的功能，去看看先”，提高競品調研的效率。
回到需求調研場景，如何通過競品進行需求調研環節？可以用一句話總結：同樣的需求或場景，別人的解決方案是什么，然后我們可以….
下面我會分成兩個步驟聊聊具體做法：
第一：你調研的目的是什么/想通過調研獲得哪方面的結論？
在這里先引用一個思維模型-黃金圈法則
黃金圈法則，又叫做why-how-what法則
- 外圈層：what圈層，是什么和做什么。指的是事情的表象；
- 中圈層：how圈層，怎么做，是實現目標的途徑和方法論；
- 內圈層：why圈層，是為什么做一件事，是做事的初衷和核心理念；
大部分人思考、行動和交流，都只是用到了最外層的what層，但是黃金圈法則的思考方式是從內向外，也就是why-how-what的方式進行思考。
在我們通過競品進行需求調研前，首先要花時間想清楚調研的目的是什么，我們希望通過競品獲得哪些維度的參考？是場景、用戶路徑還是交互以及文案。
舉一個真實的例子，我曾經想實現一個新樣式，于是去遍歷競品所有的功能更新文檔，去找對應的樣式預設效果有哪些，整理好后在策劃功能時又因為部分信息項不清晰，又回去找了一遍。效率很低不說，也有可能因為忽略了某方面的信息導致需求設計變形。
為什么會出現這樣的問題，根本原因在于我沒有弄清楚此次調研的目的是什么？也可以說對于目的的理解不夠深入
實現一個新樣式，表現層、框架層、結構層、范圍層的內容都是需要關注的。所以大家在執行競品調研工作時，不妨先花點時間想想自己要達到什么目的，需要關注哪方面的信息去達到這個目的，梳理出大致的框架，調研過程中也只是往框架中填充內容。
第二：找什么競品？
對于互聯網產品來說，基本所有的功能都能在市面上找到參考。但茫茫多的產品，我們如何有的放矢，增加調研的效率呢。在這里引入直接竟品、間接競品的概念：
- 直接競品：產品定位、用戶群、價格等元素差別不大的產品，例如可口可樂和百事可樂
- 間接競品：間接竟品是指產品形式不同，目標用戶群類似的產品，例如可口可樂和脈動
- 參照品：兩個產品不存在競爭關系，但是值得部分學習借鑒的產品，例如微博和推特
我一般關注直接竟品和參照品，因為直接竟品的用戶群與場景與自身高度重合，對方推出并迭代的產品肯定滿足了部分用戶的需求，所以參考意義較大。
相比與C端產品，B端體驗成本較高，尤其是付費使用模式的產品，想要完成的體驗用戶使用流程是非常困難的，這時候我會把目光放到專注于某個功能的垂直產品中，也就是提到的「參照品」
例如tapd（組內的敏捷協作平臺）需要優化編輯器模塊，那么對標其他組內敏捷協作平臺固然是個好方法，同時我們也要把格局打開，如果只聚焦編輯器（編輯）場景，那么垂類工具例如騰訊文檔、飛書甚至wps、office有沒有參考價值呢，肯定是有的，在某些場景可能它們更加聚焦，同時體驗成本也較低，那么這個時候「參照品」也可以作為竟品維度之一去選擇。
在對比「參照品」的時候，要牢記自己的調研目的，切勿照搬照抄。因為兩個產品不存在競爭關系，所以解決的并不是同一類問題，我們不能全盤吸收，而是要回到自身產品中取舍。
客群調研：
目前我觸達客群的方式有以下幾種：QQ（群聊為主）、微信（群聊為主）、企微（私聊為主）
對于B端產品來說，用戶溝通成本較高，原因是實際使用者跟管理者大概率不是一個人，且用戶對產品的情感價值不高，更多認為是一筆買賣，所以會導致溝通變形。
每次我通過工單、社群幫助用戶解決問題后，都會嘗試附上我的企微二維碼，引導用戶添加好友，成功率70-80%吧，在“成功解決問題后，嘗試轉化”這個場景引流過來的用戶質量還是蠻高的。添加為好友后，可以隨時發起溝通。目前我的企微已經有幾十號用戶了，再給上對應的備注，例如“xx版本-id-反饋的功能模塊”更方便我們后續識別。
出于個人隱私的考慮，我不建議大家在個人聊天軟件上添加過多的用戶，工作相關的還是盡量引流到工作軟件中去。
產出功能清單：
功能清單是調研結束后的重要產出之一，按照用戶主流程/分支流程，將功能結構圖中的每個點拆解出來作為維度，進行備注，同時基于已有的信息賦予所有功能點優先級。
對于PM來說，提供了一個類似全局的視角去“鳥瞰”整個功能，涉及什么功能點，哪些比較重要需要一期完成，哪些相對沒那么重要可以拆分到二期或數據驅動的。
對于開發等角色來說，幫助其了解需求內容的同時，也提供了兜底作用，增加需求的可拓展性。
拿我最近做的一個需求-功能清單舉例，我常用的分類維度以及評估標準有：
- 工單&客服反饋數量：指的是[2.1 對內]中提到的工單、客服會話渠道反饋內容，這里轉化成具體的數量，指的是反饋中直接match到功能點的數量。這里有個坑是產品經理一定要去看反饋內容并理解背后的訴求，不能想當然的只看標題或某幾個關鍵字就關聯上；
- x競品支持：有多少個直接競品支持該功能，數量越多越能說明這是一個通用類的功能，但也要注意結合自身產品定位和差異化打法思考；
- 是否必須：該功能點是否在用戶使用主路徑上，若不支持斷路的影響有多大；
- 開發成本：該功能點的開發成本如何，是否有組件支持、是否已實現類似功能，不確定的話可以問問關系較好的開發同學；
- 優先級：以需求目的、產品定位、差異化能力為主要思考方向，上述維度為輔助思考方向，對每個功能點標記優先級，并根據優先級對應后續處理方式；
九、交互設計
用戶需要通過這個功能達到什么樣的目的？我們如何幫助用戶更快更愉悅的達到這個目的？
至今仍記得年初職級晉升答辯，評委問過我的一個問題和答案“你覺得怎么去評判一個交互設計的好壞？”“搞明白這個交互想讓用戶達成的目的是什么，再去看它有沒有基于場景、用戶特點去做對應的適配”。交互設計是PM日常工作中比較基礎的環節，而兩者又與用戶體驗息息相關，適當的交互與頁面設計可以降低決策成本，從而更容易被轉化。
我覺得交互這塊要做好有以下幾個點：
- 了解清楚用戶發生行為的場景和我們預設的目的；
- 腦子里有足夠多的交互儲備（用哪種類型的輸入框？要不要收起、要不要給提示）；
- 換位思考能力；
分享一下我平時學習交互知識的秘訣：有效輸入+歸類整理+定時復盤，這里用到了與語雀-知識花園概念類似的個人體系學習方法，感興趣的小伙伴可以在評論區留言，這里不多贅述了。
十、檢查
1.首先根據用戶使用路徑，檢查是否有地方邏輯中斷，分支流程是否有考慮到；
2.按照「2.2」中的功能清單，核實邊界邏輯、兼容邏輯是否正常；
3.最后也是最重要的一點，找回需求調研的案例，代入進用戶角色與場景看能否滿足訴求，使用體驗能否再優化；
十一、評審
我理解的需求評審目的主要是大伙一起幫你找需求方案中是否還有遺漏的場景，那么在需求評審前，一定要做好準備。包括檢查原型能否正常預覽，一些文檔的跳轉是否正常。由于與會都是組長級別的同事，所以要注意認知差異，模擬對方是小白的情況下來組織話術，能夠準確描述場景與希望解決的問題，
需求評審中要學會抓大放小，感覺有坑的點要提前確認好，會議上直接拋結論與論據，小點可以一句話帶過，提高評審的效率；
需求評審后要做好會議紀要，評審中大家挑戰的點有哪些，怎么解決，ddl是多少，做好后續行動的同步；
十二、需求如何落地
千言萬語匯聚成十個字，事事有回應、事事有記錄
事事有回應指的是在需求流轉過程中，會遇到各種形形色色的問題，在做好時間管理的情況下，要認真思考并給出結論（下一步的行動）；
事事有記錄指的是，如果需求發生變更，要抽時間做紙質或口頭的記錄，建議大家在每個需求前面放一個變更記錄表，總結變更點后記錄下來，非常好用；
十三、需求如何推出去
需求跟進：
我的需求跟進手段有兩種，用戶反饋、功能埋點，后者也是非常重要的一個部分，想單拆一篇文章來說明。
用戶反饋是一個定性的跟進方式，上線前用戶的反饋在上線后能close多少、上線后跟這些用戶溝通的效果怎么樣，它能直接反應我們是否解決了問題
功能埋點是一個定量的跟進方式，上線后使用情況如何、是否符合設計預期，它能反應用戶的實際使用情況，目前我會以上線后一周/上線后一月/上線后三月的頻次來產出對應的數據分析文檔，數據驅動迭代是一件非常美妙的事情
功能包裝：
俞軍老師在《產品方法論》中有一個相關的名詞叫「擴大效用」，指的是產品是企業和用戶進行價值交換的媒介，用戶愿意進行交易是因為在用戶的預期中該產品的效用大于用戶的成本且大于其他產品的效用。
如果想提高用戶進行交易的幾率，我們可以通過擴大產品效用的方式，而功能包裝則是其中較常見的一種手段：選擇某個用戶群，利用banner、專題頁等方式，直截了當的告知用戶該功能的價值。
因為大部分用戶是不想去思考的，例如微信有一個功能叫圖片大爆炸，我在更新中看到這個名詞，沒看懂也不感興趣就直接劃走了，但實際它能幫助我們提取圖片中的信息，如果是個付費功能，在這個場景下我是需要的，但我流失了。功能包裝這個行為本質上就是告訴用戶“我能幫你做什么”，是站在用戶視角而不是產品視角。
1.在進行功能包裝時，要強調價值而不是手段，提供一個快速跳轉的功能入口并通過數據監測用戶行為，驅動優化。
2.在進行功能包裝時，不要局限在單點上，要去尋找點依附的那條線、線依附的那個面
十四、總結
時光飛逝，這份方法論文檔完稿于做產品的第一年，在這一年里我由懵懂的實習生成為越來越得心應手的“老油條”，離不開日常復盤、總結、思考的過程。畢業時自己定下的一年職業規劃目標是「建立個人B端產品方法論，持續打磨基礎能力」，現在看來雖然大體完成，但自身的學習效率與執行力還是要多加提升。
前幾天跟朋友聊天，他問我為什么要花時間去輸出這種方法論，當時我完全是從利他的角度出發，希望輸出方法論后能讓大家有復盤的意識，能少踩一些坑，能讓工作再高效一些，從而幫用戶解決更多的問題。
現在我要補充上利己的角度，因為輸出方法論真的是一件非常有意思的事情，它就像一條線，將過往的每個知識點串聯起來，讓我有一種溫故而知新的感覺。隨著工作年限的增長，有可能現在的框架會進行修改、有可能現在的想法會被推翻，但從大盤來看是正向的進化過程，緩慢而踏實的成長。
anyway，希望自己能永遠保持這份初心，也希望大家能踴躍地分享自己的意見和看法，不積跬步，無以至千里。
本文由 @sky0247 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
一年能總結出這么多內容，感覺很厲害。感覺博主學習能力很強成長很快，希望能向博主學習交互設計的方法！
作者很棒啊，文中交互設計內容中提到的語雀-知識花園概念類似的個人體系學習方法是啥呀？可以分享學習下嗎
交互的儲藏庫有嗎？
厲害
作者真的很棒，看了你的輸出我好慚愧，向你學習！另外作者學習交互設計的秘訣是什么？肥腸感興趣o(*^▽^*)┛
寫得好詳細，愛了愛了。
作為一個產品新人，很敬佩！
目前也在b端實習，學習啦！
作者可以分享交互學習的方法嗎，很感興趣
1年有這樣的沉淀很佩服
看完這篇長文我感受到了作者在這過程中的成長，將過往的每個知識點串聯起來再輸出，就成為了自己的東西。
不錯，點贊
您好，競品更新渠道一般要去哪找？
1.競品官網-底部或頂部導航-功能更新/幫助中心是最高效的途徑
2.對外的宣傳渠道，例如公眾號的歷史推文
3.百度
感謝！很厲害