我們知道在財務系統里有三張表：「 資產負債表 」、「 利潤表 」和 「 現金流量表 」。

1、資產負債表反映公司的財務狀況

2、利潤表反映經營成果

3、現金流量表詳細描述了公司的經營、投資與籌資活動所產生的現金流。

通過這樣的抽象能讓我們對一家公司的發展狀況有一個可量化的認知。

那么，映射到產品管理的工作上，如果也用三張表來抽象的話，我個人認為是「 需求過濾表 」、「 項目排期表 」和 「 核心數據表 」。

「需求過濾表」代表著產品未來的發展方向

「項目排期表」代表著產品正在迭代的進度

「核心數據報表」代表產品在過去的表現

一、未來：需求過濾表

需求的來源有很多，如果我們不對需求進行有效過濾，一定會陷入需求爆倉的窘境。但是，我們必須保證對關鍵需求源的持續關注，也不能因為需求太多就不接收。

一般來說，客服、運營、核心用戶群和跟蹤競品四個渠道能夠比較靠譜地從內外部輸出各種需求，因此我們要保證相關通道足夠通暢，比如定期座談、郵件report、調研等形式。

拿到各種需求之后，最重要的就是對需求真偽、優先級進行判斷。

需求真偽聽起來很詭異，用戶想要一個功能還可以是偽需求？

是的，需求是否為真，最為關鍵是在產品樹立了明確服務邊界下，這個需求是否應該在我們的產品里得到滿足。

1. 需求是要考慮成本和代價的

舉個例子，某用戶反饋“希望支持視頻課購買單課節，讓購課變得更加靈活”，這個需求聽起來有點意思，我不想買所有的，只買一節或者先試著買一節聽聽，好再買整個課程。

這個需求屬于比較典型的偽需求。

一個課程的服務邊界是由我們來定義，如果讓用戶自定義的話：

對于用戶學習效果無法得到有效保障，難保用戶單買的那節課沒有和前后節有關，導致聽單節并不能取得很好的學習效果，因此這種過于靈活的購買方式反而是對用戶體驗的更大傷害。

這就好比水果店賣草莓或者櫻桃，很多店主不允許用戶自己挑，因為里面有些有損傷——如果讓用戶自己挑，必然會折算較大利潤。所以，追求企業營利的目標會讓我們更加理性去看待用戶需求。

老板經常舉一個極端例子，你拿經濟艙的價格讓用戶坐頭等艙，用戶當然爽，但那是做慈善，不是做企業。

2. 是需求還是解決方案

第二種典型案例是用戶反饋希望提供XX功能，比如“希望提供一個歷史課程刪除功能”。當用戶提到希望提供某個很具體的功能時，此時一定要高度警惕。

功能對應的是一個需求的具體解決方案，這個時候最好再和用戶溝通一下，為啥你需要這個刪除功能，他可能會說我的免費課程太多了，影響我第一時間找到那些更為重要的付費課程。

哈，這才是需求！

所以，提供一個刪除功能是一種解決辦法，那是不是這是最好且唯一的呢？如果提供一個課程分類或者快速篩選是否會是一個更好的解決方案呢？

所以，在做需求真偽判斷時，一定要弄清楚用戶反饋的是一個需求還是一個解決方案，如果是后者需要往深再挖挖。

當然， 有時候需求和解決方案很顯而易見。比如用戶反饋“希望提供回放的倍數播放功能”，目的也很簡單，就是想快一點看回放，從而節省時間——這種情況需求和解決方案的映射比較容易，但是依然要時刻保持對需求和解決方案兩個概念之間差別的敏感度，不然很容易被用戶帶到溝里去。

然后再多說一句：有時候去比較一個需求的多種可能解決方案的核心因素還是在于成本和體驗，能否以最小化成本去實現或超越行業同等對手的體驗是考驗一個產品經理的關鍵能力。

特別是在團隊規?；蛘吖疽幠］^小時，有些功能點難度很大，是否有些土辦法去盡量擬合效果，這里是能看出產品經理的智慧和實操能力的。

那么當真需求進來之后，就到了需求優先級判斷了，這是一個很顯產品經理在該領域洞察力的活兒。

首先有個經典的公式分享給大家：

需求優先級 = 用戶覆蓋面 * 用戶使用頻次  * 對用戶的重要程度

功能的覆蓋面越大、使用頻次越高、對用戶的重要程度越大，優先級越高。一些產品相關的書還會教大家通過打分制來幫助大家去比較——我個人覺得數值化還是略有些機械，不如拉上Team Core一起去充分討論，從不同角度去審視并達成共識。

共識比單純的數值化打分結果更重要。但是這幾個因素一定要牢記心中，在討論時是一個很好的共識基礎，避免過于離散的討論。

需求過濾表核心字段：需求名稱、需求詳細描述、需求來源、需求提出時間、需求優先級、處理人、處理方案、處理進度、需求解決時間（記得在需求解決時，向需求來源及時反饋，讓來源方感到被重視，未來能更加熱情地合作）

二、現在：項目排期表

如果說需求過濾表是規劃一個產品未來的發展方向，那么項目排期表自然是活在當下的一張表，項目排期表里一定要有的元素：項目名稱、項目相關人、項目優先級、項目進度及狀態、項目上線時間。

其中項目名稱、項目相關人、項目優先級是在項目啟動前就定好的：

項目相關人一般可以把PM、FE、RD、QA、UE五個角色的具體負責人都標上，便于項目執行過程中各自擔起責任并相互協作。

項目優先級是從需求優先級帶過來的，一般保持一致，當然有時候會出現一些時效性較高的項目，比如年度總結、雙十一活動等等，這一類有明確時間要求的項目一方面要盡早規劃，另外一方面確實需要在執行過程中做更精準的安排。

項目進度及狀態屬于過程中變更的信息，用于過程管理，項目上線時間則是結果，一方面用于后續數據分析時去初步判斷某些數據變化和某些功能是否有關，另外一方面就是季度和年度review時好了解各個時間階段的工作產出。

我理解在整個項目管理過程中，最重要的兩件事就是review進度和異常情況的處理。

定期review進度能夠幫助我們更好地知曉當前項目所處的進度是否正常，及時發現異常情況，盡量把問題在萌芽階段就消滅掉。

至于異常情況的處理，這里的異常情況花樣太多了：高優先級項目插入、團隊成員生病了、產品經理在評審后要改需求（嘻嘻）、項目復雜度超出預期等等，各種花式問題會讓項目delay。所以，這里就不提供具體每件事該如何處理了，也無法一一列舉。但大致思路就是確保高優先級項目能夠按時上線，中、低優先級項目可適當delay。

一般delay可以買零食哄哄技術小哥哥加班，人力缺失的要及時和技術負責人協調額外人力支持，時間緊任務重還有明確上線時間的需要封閉開發+天級站立會。

術有很多，核心還是想盡一切辦法讓項目如期上線。

吶，換個說法就是執行力和推動力。

最后，在項目優先級的整體把握上，要和公司戰略保持一致，舉個例子很多公司至今都沒有走出當年PC轉移動時代，因為慢半拍帶來的被動。

因此，如果一旦確定一個明確的戰略時，產品團隊需要第一時間去review手上項目和戰略的一致性，如果有違背需要盡快收尾甚至凍結那些和戰略不一致的項目，否則慢半拍會導致后面很多拍都跟不上。

三、過去：核心數據表

數據一定是對于過去動作的一種表現，它是有一定的滯后性，因此數據是幫助我們分析過去我們的產品行為是否產生了正收益的坐標。

看數據最重要的點是看什么，聽起來蠻搞笑，但事實上確定核心數據項是一個非常重要的工作，這需要我們深刻了解我們做的事情以及影響這件事情的關鍵性過程指標和結果指標。

對，這里提到了兩種指標：一個是過程指標，一個是結果指標。

比如一家教育機構，結果指標一定是現金收入和確認收入，但過程指標就會因為機構的規模和階段有所側重，比如剛開始階段一定是新生獲取量，但隨著服務穩定之后就會開始關注這批新生的續費以及轉介紹，再往后隨著自身業務的橫向擴張，就會開始關注擴科和多科聯報等指標。

抓結果，重過程是我們看待數據的重要態度；過程對了，自然結果就對了。

其次看數據的方式上，最重要的就是比較，只有比較才能看出變化和問題。比如我們常見的天級報表，對于核心數據的天級監控，同時拿天級數據和前日、周平均、月平均、季度平均進行對比并標出漲跌，這對于我們做到“心中有數”很重要。特別是天級報表中的異常值，漲跌超過一般幅度，比如收入一下翻倍，或者日上課人數掉了一半等等，是我們關注天級報表的重點工作。

那么，遇到這一類異常情況，我們馬上要啟動的工作是要“下鉆”到細節上，比如日上課人數掉了一半，可以拉出兩天具體課程級別的上課人數情況進行對比，看看原因是頭部課程的下降，還是整體下降，或者是某個品類的課程下降，找到原因后再去和相關小伙伴去聊，判斷這個下降是否在預期之內，如果不是那么接下來我們該采取什么動作去補救。

除了天級報表以外，趨勢圖是在一段時間內去看整體走勢，比如一個月或一個季度，此時能看到一個整體的變化趨勢，持平、上升還是下降。以及剛剛提到的在核心數據下的二級細化報表，比如日上課人數是核心數據，那么按照課程粒度的TOP50課程日上課人數排行榜、不同端日上課人數分布（PC網頁、PC客戶端、M站、APP）就能在更多細節上去支撐核心數據。

數據分析其實就是在不斷地“上抽”和“下鉆”中去看宏觀表現和微觀細節，既有大局觀，也有細節認知。

四、小結

綜上，管好以上三張表將會極大地幫助產品經理找到產品迭代的方向和節奏。

如果在某張表上的管理老是遇到問題，那么就需要好好看看，在哪個環節還存在問題，比如需求過濾表的需求來源是否通暢、項目排期表的相關負責人是否知曉并按照這張表達成的共識推進、核心數據表的統計源是否準確無誤等等。

通過這三張表的有效監控，將會讓產品經理更加清晰、有效地推進產品相關的各項工作。

希望能幫到那些還不知道怎么做產品有效管理的小伙伴們。