編輯導(dǎo)讀：2020年的時間彷佛被人按了加速鍵一般，轉(zhuǎn)眼間就到了年底，很多人要開始寫年度總結(jié)報告了?；仡櫼荒甑墓ぷ鹘?jīng)歷其實并不簡單，簡單的羅列看起來太費力，在工作數(shù)據(jù)的基礎(chǔ)上進行總結(jié)分析才是一份合格的年度總結(jié)報告。本文作者從產(chǎn)品經(jīng)理日常工作出發(fā)，制作了幾張“數(shù)據(jù)總結(jié)”圖對自己的一年工作進行了總結(jié)，一起來看看~

俞軍老師曾說過：“面對需求合理性的取舍，往往能決定一個產(chǎn)品生與死，而這恰恰是產(chǎn)品經(jīng)理存在的原因”。

但殘酷的現(xiàn)實是大部分產(chǎn)品人在需求取舍的敏銳度上基本缺失，也沒有去挖掘需求的合理性。比如之前在Blues團隊對需求的挖掘和梳理有一套完備的機制。所以這些產(chǎn)品經(jīng)理在工作中放棄對“需求”這個最重要環(huán)節(jié)的掌控權(quán)，甘于成為“需求的搬運工”，所有力氣和才華花在了自認(rèn)為的“Do the things right”——生產(chǎn)環(huán)節(jié)：系統(tǒng)設(shè)計、交互、需求文檔、項目管理。

如果你心里永遠(yuǎn)有條業(yè)務(wù)線和一張不斷修正的產(chǎn)品藍圖。對于你自身來說，你將不會失敗。用一張圖來梳理下：

前面稍微聊的有點多。接下來John通過產(chǎn)品經(jīng)理日常工作制作了幾張戲謔的圖，來聊聊產(chǎn)品經(jīng)理年終報告：（踏實做好每一步，將每塊產(chǎn)品知識碎片拼湊起來，才能更好更快的成長。圖片純屬虛構(gòu)哈。如有雷同，你就太牛X了。）

01 關(guān)于業(yè)務(wù)需求

可能大部分產(chǎn)品經(jīng)理在梳理業(yè)務(wù)層模塊時，往往會被業(yè)務(wù)方牽著鼻子走。其中需要和業(yè)務(wù)同事進行有效溝通，主要分為三部分：

• 首先產(chǎn)品經(jīng)理需要對整個業(yè)務(wù)非常熟悉——現(xiàn)有業(yè)務(wù)（直接呈現(xiàn)給用戶的）和后續(xù)方向（業(yè)務(wù)規(guī)劃和競品梳理）；
• 和業(yè)務(wù)方溝通時，要有針對性追問業(yè)務(wù)同事提出方案的合理性。這不是抬杠，是說清楚做這個事情的意義和背后的目的。達成一致才能更高效做事；
• 背后的目的和當(dāng)前優(yōu)先級必須貼合當(dāng)前OKR。

“業(yè)務(wù)”和“需求”是產(chǎn)品經(jīng)理入行的必修課。業(yè)務(wù)的制定策略，可能產(chǎn)品經(jīng)理不太清晰，但是業(yè)務(wù)的實現(xiàn)邏輯以及業(yè)務(wù)規(guī)劃，產(chǎn)品經(jīng)理要非常明白。

02 關(guān)于用戶需求

大部分的用戶需求合理性一定是用戶在一段時間使用產(chǎn)品后反饋的需求，所以這就是為什么要時時刻刻跟蹤用戶，跟蹤用戶最好的方式是把用戶凝聚在一個群里互相溝通。這也就是搭建核心用戶群最好的辦法。John一般是這么做的：

• 適當(dāng)?shù)母＠右龑?dǎo)，尤其是新版本更新時，非常有必要去做；
• 比如在電商產(chǎn)品中，每天有效的做好任務(wù)引導(dǎo)（核心群設(shè)定對應(yīng)的任務(wù)環(huán)節(jié)），并做好優(yōu)惠+獎勵；
• 其他的，運營需要準(zhǔn)備對應(yīng)的方案。

需要注意的是：一定要有了完備的方案才考慮拉核心用戶群，且核心用戶群目的是為了用戶反饋需求。一定要圍繞這兩點出發(fā)才行。否則就變成營銷群。

03 關(guān)于數(shù)據(jù)需求

數(shù)據(jù)的重要性對于產(chǎn)品來說就不言而喻了吧。但是…但是…數(shù)據(jù)字段的定義是基礎(chǔ)點。如果數(shù)據(jù)定義都產(chǎn)生分歧or模糊不清，那再多的數(shù)據(jù)都是扯淡了。那么產(chǎn)品經(jīng)理和業(yè)務(wù)一定要盡可能有完備解釋每個數(shù)據(jù)的定義。比如：

• 新增用戶(7日平均):最近7日(不含今日)每日新增用戶的平均值
• 新用戶次日留存率(7日平均):最近7日(不含今日/昨日)新增用戶次日留存率的平均值
• 使用時長(7日平均):最近7日(不含今日)用戶每日使用時長的平均值
• 活躍用戶(7日平均):最近7日(不含今日)每日活躍用戶的平均值
• 7日總活躍用戶數(shù)(重) :最近7日(不含今日)活躍用戶的總數(shù)(去重)
• 30日總活躍用戶數(shù)(去重) :最近30日(不含今日)活躍用戶的總數(shù)(去重)
• 累計用戶數(shù):截止到當(dāng)前時間，啟動過應(yīng)用的所有獨立用戶(去重，以設(shè)備為判斷標(biāo)準(zhǔn))
• 總崩潰率:每日錯誤數(shù)/啟動次數(shù)

先定義好數(shù)據(jù)字段，在去梳理數(shù)據(jù)分析。

04 關(guān)于產(chǎn)品拆解

“如果你認(rèn)真拆解3款產(chǎn)品后，你真的會上癮?！比绻皇峭瓿扇蝿?wù)，你會越拆解越難受。所以試著去拆解下產(chǎn)品，真的賊有用。新讀友可以看看拆解的三步法：

• 產(chǎn)品架構(gòu)——梳理下產(chǎn)品功能清單（盡量無遺漏的寫出來）；
• 運營體系——結(jié)合該產(chǎn)品的歷史版本迭代記錄和結(jié)合市場分析做出運營體系梳理；
• 商業(yè)模式——梳理下該產(chǎn)品的盈利模式。

（還可以加上以下兩條：

• 核心流程梳理——把該產(chǎn)品的核心流程及其有關(guān)聯(lián)的流程全部梳理出來；
• 特色功能——特色功能的交互和頁面流程梳理有必要整理出來。）

建議產(chǎn)品小伙伴都去拆解下，哎喲……真的會上癮哦~

05 關(guān)于產(chǎn)品路線圖

對產(chǎn)品規(guī)劃和業(yè)務(wù)規(guī)劃非常清晰，并且對于競品有一定的認(rèn)知后，再來制作產(chǎn)品路線圖。且產(chǎn)品路線圖一定要落地……

所以路徑一般是這樣的：產(chǎn)品規(guī)劃藍圖→產(chǎn)品需求；業(yè)務(wù)OKR→業(yè)務(wù)需求；用戶核心群→用戶需求；數(shù)據(jù)分析→數(shù)據(jù)需求。把以上需求進行緊急優(yōu)先級梳理和排序，和各方小伙伴進行版本梳理。

制定了就需要推行落地，有調(diào)整就修改……

06 關(guān)于產(chǎn)品設(shè)計

產(chǎn)品設(shè)計處于基本功，清晰的產(chǎn)品原型展示是傳達給項目組的基礎(chǔ)。需要考量的點是：

• 產(chǎn)品設(shè)計的原則要和UI敘述清楚，讓UI能從產(chǎn)品原型中明白你的意思；
• 產(chǎn)品原型在技術(shù)眼中要清晰功能的重要優(yōu)先程度。

John一般針對于原型的設(shè)計是黑白灰的線框圖。給UI在設(shè)計的過程中，盡量不要造成配色上、布局上的歧義。在交互上，有條件的盡量可以完善交互和用文字表述清晰。

另外，有參考圖會更佳。核心點就是通過你的產(chǎn)品原型設(shè)計，能讓項目組明白布局、功能的優(yōu)先級。一定是梳理清晰了，最后進入原型階段。來來來，一個口訣：重要核心功能，原型展示粗大黑；邊緣輔助功能，原型上輕呈現(xiàn)，留入口。

上周天晚上發(fā)了一個朋友圈帖子——當(dāng)遇到一個已前端優(yōu)化為主又沒有思路的項目的時候，你可以：

• 看看哪些信息需要組織 ——— 對界面元素信息的重新歸類和劃分，劃分信息層級；
• 看看哪些信息需要展示 ——— 對界面元素重要程度的劃分，調(diào)整信息要素；
• 看看哪些信息需要隱藏 ——— 對界面不常使用的元素進行隱藏，增加界面的擴展；
• 看看哪些信息需要規(guī)范 ——— 對界面的可視化保持統(tǒng)一和復(fù)用，減少認(rèn)知和設(shè)計成本；

相信你對產(chǎn)品設(shè)計就有一定的認(rèn)知了。

07 關(guān)于產(chǎn)品邏輯

產(chǎn)品邏輯真的是要命，99%的產(chǎn)品經(jīng)理在邏輯上必定失手。主要體現(xiàn)在：

• 單獨的模塊的正向流程中的邏輯說明——能完成99%；
• 單獨模塊中的字段梳理和邊界值——能完成90%；
• 單獨模塊的異常流程（邊界值、空白頁、網(wǎng)絡(luò)環(huán)境、提示等）——能完成75%；
• 多模塊串聯(lián)的正常流程、異常流程、邊界值、歷史流程關(guān)聯(lián)——能完成50%。

你瞧瞧，技術(shù)能不崩潰么？John梳理的自查表只能解決80%（主要針對于單獨模塊），那多模塊串聯(lián)主要是要看歷史文檔和對用戶路徑和流程的敏銳度。所以為什么說梳理產(chǎn)品時一定要把用戶路徑整理出來呢？

業(yè)務(wù)流程和用戶多路徑并發(fā)，是梳理清楚產(chǎn)品邏輯的基礎(chǔ)。加上John梳理的自查清單，應(yīng)該能解決99%的問題。

08 關(guān)于產(chǎn)品評審

產(chǎn)品評審的過程貌似感覺是把產(chǎn)品經(jīng)理送上“審判臺”似的。每個項目組的同事都在看你的“洋相”。稍有不慎，這評審會必定變成需求討論會，無論多少次評審，肯定沒有終點。所以就需要產(chǎn)品經(jīng)理在評審前、中、后有效的組織。

評審前，一定要把相關(guān)的需求清單和原型知悉給參與項目的伙伴；

評審中，切勿針對需求做二次發(fā)散，每次發(fā)散都是需求的不確定性；

評審后，會議紀(jì)要和需求澄清說明。并在二次澄清會上給予需求排期。

09 關(guān)于項目協(xié)同開發(fā)

“小步快跑，快速迭代”是我一直在項目管理中實行的。尤其是多項目組并發(fā)時。但是有幾個前提條件：

• 梳理產(chǎn)品版本時，應(yīng)該盡可能的完善，無遺漏，給項目組傳達的內(nèi)容要足夠清晰；
• 落地且切合實際、成熟的項目協(xié)同流程，做到協(xié)同高效清晰；（可以公眾號回復(fù)關(guān)鍵詞：項目協(xié)同，查看John整理的項目協(xié)同流程。）
• 產(chǎn)品經(jīng)理和業(yè)務(wù)牽手齊步走，才不至于出現(xiàn)“產(chǎn)品經(jīng)理催著業(yè)務(wù)要業(yè)務(wù)方案”、“業(yè)務(wù)催著產(chǎn)品經(jīng)理知悉上線進度”。

以上三個點，缺一不可。只要缺失一項，產(chǎn)品、技術(shù)、業(yè)務(wù)會被拖死的。同時也需要制定產(chǎn)品路線的清晰性和完備性。

10 關(guān)于加班

如果上面任何一步都沒有做好，長時間的加班肯定是在所難免的。加班真的不可怕，可怕的是加班效率還賊低。

我非常不鼓勵團隊的小伙伴加班，因為正常的加班只有兩種情況：

• 時間沒有分配好，該搬磚時在摸魚，所以下班就趕進度；——按時定點的完成，絕對不說。
• 工作效率低，重復(fù)性的工作太多（需求沒有搞清楚，反復(fù)修改原型之類的）?！蔷托枰牧淖鍪碌姆绞搅恕?/li>

鼓勵的是下班后，留一個小時一起學(xué)習(xí)、討論、交流。。。

11 關(guān)于OKR

OKR絕對來不了半點虛的，一定是要落地的。過程中的每一步必須要做到有跡可循。尤其是作為產(chǎn)品經(jīng)理在梳理產(chǎn)品OKR拆分時，并不能停留在PPT上，而是一五一十落地到產(chǎn)品路線圖中。因為制定的OKR是最終到公司資源投入層面上，只有做好和有效果，整個公司才能往前走。

除非，您是用來炫技的。。。

12 總結(jié)

最后想聊的是盡管圖片上都是段子，但是也是我們正在遇到的“糟心事”。這也就是產(chǎn)品經(jīng)理的價值：能盡量正確的處理好每一步。簡單的做好了才能判斷復(fù)雜的決定。站好馬步后才能開始習(xí)武。

一遍一遍的理需求和一步一步過流程后，你才能看到產(chǎn)品框架。競品拆解多了，你就能看到產(chǎn)品架構(gòu)、商業(yè)模式和運營體系。

勿以事情零碎而不為，否則永遠(yuǎn)都是站在岸上游泳。

作者：John，產(chǎn)品狗一枚，微信公眾號：產(chǎn)品狗聚集地。

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

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