嘉賓介紹

劉飛，資深產品人，前滴滴出行司機方向前產品負責人，點我達前產品專家，嘟嘟美甲聯合創始人，錘子科技產品經理。在知乎累計446579次贊同，224900人關注，“產品經理”話題下的優秀回答者。虎嗅網、36kr、雷鋒網、人人都是產品經理、知乎等媒體專欄作者，通過“在行”平臺線下幫助200余位產品學員進階。開有公眾號“劉言飛語”。

新書《產品思維》將產品經理工作中必須要面對的認知盲點和實踐痛點掰開揉碎進行講解，毫無保留地分享了產品新人迫切需要卻很難在公開渠道獲取的知識，現全網熱賣中。

Q1. 產品經理如何在設計產品時避免給開發挖坑??

1. 搞明白基本的一些技術背景和技術概念

產品經理需不需要懂技術是老生常談的問題，我的回答是肯定要懂，關鍵在于，懂的技術是怎么樣的技術。

懂技術并不是就要能自己成為架構師、自己成為工程師，又可以規劃技術架構又能實現產品功能。懂技術是要明白技術實現的邏輯。

比如，我們在做的配送業務，需要有配送員、訂單、商家多種信息，每種信息是存放在各自的數據結構里的，它們之間又通過邏輯關系串聯起來。這些產品上都未必體現得出來，但在很多產品設計的時候要考慮到，要做某個新業務時，發現商家要分截然不同的兩類，那中間的邏輯怎么樣成本最低，是同一張表用屬性區分、還是新造一張表，都是要跟技術一起討論研究的。?

平時，也建議多看些技術相關的文章和科普。注意，千萬不要買什么《七天掌握安卓系統》之類的書，看一些跟產品息息相關的比較好。

2. 學會梳理產品邏輯?

這個邏輯不是 APP 上有幾個 tab 頁，也不是功能之間簡單的關系，說的是背后的幾個邏輯：數據結構、信息流程和其它的邏輯關系。

然而我見到的很多產品經理，并不太把這個當回事。「只要給我實現就行了，我不關心怎么實現。」

數據結構其實是第一重要的東西，可以讓產品經理非常深入地理解技術實現的邏輯。

比如，這是美團酒店銷售的數據結構。可以讓整個酒店商品的邏輯一目了然，而不是零散的需求。?

信息流程則是在有一個信息通路、存在一些狀態轉化邏輯的情況下，需要考慮的。比如常見的訂單從生成到支付到結束的環節，如果也只是零散地提出功能需求，那很可能出現紕漏，技術實現上也不明晰。?

比如，這是嘟嘟美甲最初交互草稿里，我們梳理的訂單狀態轉化圖。

還有很多其他的邏輯，也需要梳理清楚。

比如，我們前段時間在設計取消訂單機制的時候，發現有很多種情況，每種情況的文案也不應該一樣，這時候就要梳理出每種具體的提示，不能讓技術去幫你完善。

對于應該梳理什么、怎樣梳理比較好，可以多問問程序員哥哥們的意見。如果他們看到你的文檔，立刻就能想到該怎么實現，那就證明起到作用了。如果每次都要花費大量的時間拆解和討論，那就是梳理得還不夠。?

3. 出現坑的時候，多復盤?

不同的產品差異很大，即使再有經驗的產品經理，也不一定就永遠不會埋坑。

坑出現了之后，除了盡快填起來，還要去復盤，多想想，怎么避免下次再進坑。

如果是文檔寫得不周全，那就盡量寫得周全些；如果是缺乏溝通，那就在協作時多設立溝通會；如果是需求總會變動，那就研究需求變動的根本原因，把它大事化小小事化了。

關于產品技術協作，在我們公司，是設置了一套復盤機制的。每次出現大的問題，都會在解決之后，召集一次大會，所有相關人員加產品和技術的總負責人都在場的情況下，把事情說清楚，搞明白原委，并且會上要制定解決方案。?

經過一兩個月的嘗試，我們發現，大多數的坑都是同樣的原因，我們就重點攻克這個難點，慢慢讓坑變少，原來的大坑也變小了。

Q2. 作為產品經理，你是如何分析和管理你的產品需求的？

下面是我的經驗，我都寫在新書《產品思維》中，在這里也簡單講一下，解決這個問題未必是只從需求管理來做，而是整體流程上把控。?

1. 獲取階段?

需求的來源有很多。業務越復雜，需求就越雜。一個淘寶，產品需求就可以拆分成分類、檢索、排序、商品展示、營銷活動、支付、配送、售后等等。

你的職級越高，也代表著身邊人提需求的可能性越大。初入行的產品專員或助理，主要是得到被安排的任務；初級產品經理，需求來源主要是用戶和上級；產品負責人，需求來源就要增加老板和其他相關部門；而作為老板，誰都可能跟他提產品需求。

所以在獲取到需求這一時刻，就必須做一個判斷，并且記錄。如果不做判斷堆在那里，等做的時候根本沒辦法梳理出頭緒，可能大部分時間都在疲于折騰需求清單。記錄當然是為了方便回溯。獲取到的再小的需求也記下來，不要指望你隨時能想起來每天聽過的每個需求。

做判斷的內容具體是什么呢？

第一，判斷需求本身的重要性。

同樣是頁面寫錯了一個字，把「登錄」寫成「登陸」，和把「獎勵 15 元」寫成「獎勵 50 元」，重要性不言而喻吧。有個大致的預估。?

第二，考慮需求來源。

需求來源會表明一些事情，要慎重思考。比如老板提到的，未必是目前你能理解的，但他認為特別重要，就暫且把這個當成特別重要的，這是政治任務。再比如是用戶提到的，但細想他并不是目標用戶，他的需求就不必太關注。

第三，簡要得到需求背景。?

我自己工作中有三類需求絕對不記：沒說清楚原因的，不記（你做個XX出來，別管那么多）；不說清邏輯的，不記（啊，這里我也沒搞懂，你先看看）；不是實際遇到的，不記（哎，我覺得可能有人會這樣用）。?

需求背景沒搞清楚，完全是浪費時間。有一句話的記錄，但不說背景，也是浪費時間。記的時候，我會確保格式是問題+方案，「XXX 在用我們的 XX 功能時，感覺 XXX，我們可以嘗試 XXX 這樣的方案」。?

最后，依據這三個因素，判斷屬于大致哪個類別的。一般的需求管理都會分 P0-P3 或者 P1-P4，總之先打個標簽。這里的技巧是盡量標記為比估計的更重要一層的需求，就是你感覺是 P2 的，暫且先標為 P1。這樣以防錯漏，低優先級的標成高的沒關系，但高優先級的標低了會出現麻煩。這時候的預估往往不準確，但沒關系，等后面第二步再說。

比如這樣：?

?2. 討論/設計階段

隔一段時間，我們會開需求討論會，整理需求池，也就是記錄所有獲取到需求的表單。

我們會詳細討論每個需求的情況，確認幾個事項：

一，需求的優先級

之前的判斷是粗估，這里的判斷就要精細了。一般需求的重要程度很難量化，尤其來源復雜的情況下。營銷部門著急要我們配合做活動，不做就少賺好多錢，業務部門著急要我們配合做一套自動化結賬工具，做了能節省很多成本... 有時抉擇很痛苦。

這里還是用最常用的判斷方法，緊急重要四象限法則：四象限法則_百度百科。重要程度大致按這種排序：

• 不做會造成嚴重的問題和惡劣的影響的

• 做了會產生巨大好處和極佳效果的

• 跟重要合作對象或投資人有關的

• 跟核心用戶利益有關的

• 跟大部分用戶權益有關的

• 跟效率或成本有關的

• 跟用戶體驗有關的

緊急程度按這個排序：

• 不做錯誤會持續發生，造成嚴重影響

• 在一定時間內可控，但長期會有糟糕的影響

• 做了立刻能解決很多問題、產生正面的影響

• 做了在一段時間后可以有良好的效果

大家把能考慮到的因素想全，會標上 P1 - P4 的優先級。

二，方案的方向

需求有不同的解決辦法，我們會討論清楚到底用哪種解決。比如我們發現有刷單現象，可以事前提醒，告知用戶目前地理位置或訂單信息有嫌疑；可以事中限制，必須到達指定地點、拍攝當地照片等等操作來限制用戶；可以事后懲戒，提供給客服或者業務部門疑似刷單的名單和證據，罰款或者封號。這幾項到底做哪個？還是做其中哪幾個？優劣在哪？需要好好討論。?

有時會有大概的方向，再去跟相關部門和需求相關的同事確認。這不在本文討論范圍內，暫且不提。

三，指定負責人

我之前經歷過兩種需求分配制度。一種是每個人負責的需求范圍有清晰的邊界，那需求對應哪個模塊，就直接分配即可；另一種是團隊作戰，每次指定或者認領，誰都有可能接手任意需求。

前一種的好處在，模塊清晰，負責人可以對自己負責的部分足夠熟悉，但缺點是，工作量很可能不平衡，有的同事一直在忙，有的可能就比較閑，因為需求不是平均按模塊分布的。

在我們需求分配時，大致還是按照模塊分配，但在出現工作量不平衡的情況時，會酌情調整一下，讓活少的同事予以配合。

不管怎么樣，一定一定要指定負責人，他需要對需求負責，一直到產品上線后，出了的問題他也要承擔責任。要保證運營良好的工作責任制。?

四、劃定時間節點

許多產品經理會疏漏這點，只是覺得盡快去做，但總是做不完。

時間節點至少也要包括方案完成的時間。就是這個需求，能夠完好提交給開發的時間。如果沒有這個時間，對需求的管理就沒有一點意義了。

另外，如果是要跟相關部門再確認、或者要跟用戶調研、或者要統計各種數據再作判斷的需求，那還要有調研/討論完成的時間。

這個時間節點的劃定，主要是按照方案的復雜程度，用經驗做個簡單判斷。最長的時間周期也不能超過一周，保證需求的推動進度，因為很難有復雜程度超過一周的產品需求。對于有嚴格上線時間的需求（經常會出現，比如很苛刻的老板需求、投資人需求、政府需求等），要倒推出最合理又富有余地的時間節點。?

討論完剛剛入池的一批需求，我們會再整理和討論其它狀態（有方案或者調研結論）的需求。這樣會議結束，每條需求都會得到更新。

我們在這個時刻，一般會讓負責的產品經理，及時更新需求狀態給需求來源方。當然，來源方 95% 的情況下會對進度不滿意，這很正常，但除非來源方有確鑿的理由，我們不會輕易調整優先級和時間節點。?

3. 待開發階段?

有了確切方案，我們會盡快跟研發的同事做可行性評審。這一步必不可少。我感覺題主出現的「落不了地」和「頻繁更改」的問題，要著重在這個步驟里解決。

可行性評審上，完成的是對需求的大致評估，要做的有這么幾件事：

第一，方案本身的可行性。

在技術方案上，是不是能夠完成？就是讓技術部門評估這個問題。

第二，有沒有更好的方案？?

一定要跟技術部門灌輸清晰的需求背景，讓他們也想一些可行的方案。方案未必是完整、準確的，但他們提供的思路，一般是可行性較高的。

第三，涉及的產品和技術環節有哪些？

這個需要相關的同事仔細討論。尤其是很多公司產品線比較多，有可能存在牽一發動全身的情況，如果相關的產品同事和技術同事不知情，必然會延期，必然會扯皮，必然會造成麻煩，必然會有各種改動。即便是再小的產品，也要分前后端，讓技術的同事來判斷有哪些人需要知情和參與評估。

第四，方案的成本如何？?

看方案需要多少人、多少資源、多少時間來完成，也要看方案在技術層面耗費的不太明顯的成本，比如服務器成本、帶寬成本，給用戶造成的流量成本等。

有了這樣的討論，會議輸出的，就是比較嚴謹的可執行方案（或草稿）了。

如果會上遇到各種問題，要確認解決問題的時間節點。

4. 開發階段

開發需求的次序，我們不是完全按照需求池里的需求優先級來的。剛才說到，在可行性評估會上，我們會核算大致的需求成本，那成本結合需求的優先級，就可以得出需求的性價比了。?

大概是用這樣的表格：?

提交開發之后，相當于關閉需求。原則上，本次迭代不再加入新的需求。

當然啦，如果什么事情都是原則上那樣...就不會出現這么多扯皮的情況了。?

在開發中，扯皮的問題歸納起來就是三種：需求太多，沒按時做完；需求有改動，導致了額外工作量以及開發的不滿；有新的緊急需求，導致發布延期。?

這三種問題，再抽象一下，導致的原因很多，大概有幾類，分別是：

?一，產品方案不完整

方案不完整往往是沒有考慮全面。這個跟需求管理本身沒關系，就是在出方案的途中，看能不能把事情想全。

之前我們經常出現，做的時候技術才發現臥槽這里有個邏輯沒想通啊。然后喊產品來一起討論的時候，大家發現需要加一些功能才能完善邏輯。最后結果就是周六加了個班，大家很不開心。

這種事情也不好追責，畢竟參與者很多，流程拖得很長。硬要說是負責需求的產品經理有問題倒也可以，但總是片面的：他也不一定知道技術上開發才發現的邏輯。?

后來我們反思，各個流程中的環節都要做一些調整，才能確保最終產品方案的完整：?

• 分析需求時，先梳理邏輯再出方案。能畫流程圖的畫流程圖，能畫邏輯圖的畫邏輯圖，能畫腦圖的畫腦圖，窮舉整體的邏輯。

• 討論方案時，所有產品經理參與小組討論，一起提出疑惑，發現問題。

• 可行性評審時，技術從邏輯角度提出質疑，發現問題。

之后再出問題，會回溯原因。如果是前兩個環節出的問題，那就是產品經理的責任；如果是產品經理未知的邏輯，那就是可行性評審中，技術的同事的責任。

二，需求方的主觀改動

這種情況基本都是需求方或者產品經理的問題：他們在提交方案前沒有完全想清楚。

有時候都開始開發了，業務部門來人說，哎我們發現這個問題好像不存在了，大家不要做了。他們覺得無所謂，還減輕了開發負擔。但對技術部門的同事來說，就好像在說「你被耍了，哈哈哈」。造成的影響是惡劣的。

產品經理在對接他們的需求時要做判斷，他們是不是完全想清楚了，是靈機一動的小點子，還是不得不解決的問題。

另外，還有一種情況，是需求方跟產品經理對接時出了問題。表述有誤，并且方案沒有跟他們核對清楚，結果產品功能上線，才發現并沒有解決問題。

我們的做法剛才多少提到了一些：要在任何需求的屬性（內容、時間點）發生變化時，跟需求方同步。讓他們知道我們的情況，也獲取他們的意見和建議。

比如這是我們的需求同步流程：?

三、無法預測的客觀原因

這種是唯一一種能夠接受的原因，不需要有誰承擔責任。?

比如，本來要做一個功能狙擊對手，結果做了一半，競爭對手倒閉了，那這個功能就沒有意義了，確實要廢除。

還有一些業務上的確無法預測的各種原因，導致原本存在的問題不存在了，也無可厚非。

這種情況下，產品經理最重要的是安撫技術的同事，尤其是跟他們解釋清楚背景和詳細的原因，不要讓他們誤以為是剛才提到的前兩種理由。?

5. 復盤階段

需求從獲取到上線，走完生命周期之后，還要有一個很重要的復盤階段，尤其是在需求管理出過故障和問題的時候。

略靠譜的團隊，都會有復盤的機制，主要是防止問題再次發生。解決問題很簡單，如何盡量規避下次再出問題很復雜。?

大致就是，要搞清楚之前出現問題的所有邏輯和流程，再去看在哪些環節可以做點什么，去防止再次出現。這塊的內容說得多了又得寫一篇文，就不多講了。?

以上就是我的經驗，僅供參考。沒有什么流程和機制是完美的，關鍵在于怎么去解決自己的問題。如果哪些思路給你了啟發，那就夠了。

Q3. 產品經理如何給用戶需求排序？

需求分析有兩種核心的方法：定性分析和定量分析。我就從這個維度來解釋下怎樣對需求做判斷。

1. 定性分析

1.1 KANO 模型

KANO 模型是現在大家都比較認可的方法。實際上，這個模型即使你沒有系統學習過，也肯定對其理念有一定體會。?

那具體怎么區分這些需求呢？KANO 模型就是提供了這樣的方法。

我這里用的是飛哥簡化版，大概是這樣的：

解釋下這個圖。

作為一個功能， 每行對應的是如果有的話，用戶會開心、無所謂還是不開心，每列則是如果沒有的情況。具體說：

矛盾：如果用戶覺得功能存在和不存在都很開心，或者都不開心，顯然是有問題的，所以說是矛盾的情況，是存在邏輯問題的，不予考慮。

錯誤：如果功能不存在讓用戶很開心，或者功能存在讓用戶不開心，那這個功能顯然是錯誤的功能，不予考慮。

無關：如果功能存在和不存在，用戶都覺得無所謂，那功能也就無關緊要了，同樣不予考慮。

最重要的就是剩下的三類了：

必要：如果功能存在用戶并沒有特別的感覺，但不存在會不開心，說明這個功能是要滿足基本需求的，也就是大家常說的『痛點』。?

期待：如果功能存在用戶很開心，功能不存在用戶很不開心，這就是滿足用戶最直接、最明顯的需求了，是用戶內心已有期待的。

驚喜：如果功能不存在的時候用戶并沒有感覺，說明這個功能用戶之前沒有預期，但功能存在用戶很開心，也就是說達到了驚喜的效果。這就是小米常說的『驚喜點』，所謂讓用戶尖叫的功能。?

任何需求都可以分為『驚喜型』、『期待型』和『必要型』。大家考慮需求的價值，就要基于這三種來做判斷了。

很多公司和產品利用的產品運營手法就是在滿足后兩種需求的同時，不斷用第一種需求激活用戶的熱情、促使用戶傳播。

1.2 用戶訪談

除了通過常識對需求做以上提到的判斷，深度訪談可以作為配合，來驗證之前的考慮。

訪談的時候盡量用開放性的問題來溝通，不要直接問『如果有這樣的功能你會不會用？』、『你到底想要什么樣的功能？』，而是了解用戶背后的需求、TA 使用的場景以及 TA 過去滿足相同需求的方法，這些信息能提供關鍵的證據，來輔助驗證你的判斷。?

溝通時，對同樣的功能，也可以用多種問法來試探用戶，以防用戶不夠理解；同時，也要反復對同一個功能做深入的探討：『這樣不好的話，那如果是那樣呢？』『你覺得它不符合你要求的原因是什么呢？』再即時地做出反應，能獲得更有價值的信息。?

2. 定量分析?

如果定性分析不能保證效果，那定量分析就可以獲得更準確的信息，相應地，成本會偏高一些。?

2.1 數據獲取?

數據獲取有兩種，一種是功能設計前獲取一些能輔助做判斷的信息，一種是功能上線后觀察一些用戶使用的行為數據。?

對于前者，具體方法很多，公開渠道、咨詢公司或者調研都可以，就不展開說了。對于后者，關鍵就是觀察用戶是不是在用某個功能和在用這個功能時的具體行為。

很重要的還是：數據只是提供信息，做判斷一定要經過邏輯分析。之前某老板說從大數據判斷出去洗腳店和去醫院看病的因果關系，讓人跌眼鏡，就是濫用數據做判斷的典型例子。用戶數據是最有價值的信息，但怎么用，是很講究的。?

2.2 快速驗證?

訪談的結果有時候不會特別可靠，快速驗證是最重要的方式。具體方法有很多，包括大家常提到的 Demo 或者 MVP（最簡化可實行產品） 或者灰度發布或者 A/B 測試都可以作為驗證手段。?

其實大部分手段只適用于功能已經比較完善的情況下，也就是做事后判斷，而不是事前的預測。

折衷的方案是：用最簡陋的方式做一個滿足需求的功能出來，投入到市場中觀察用戶的反饋，來確定功能的重要程度。如果用戶反饋良好，就做得更完善、優化得更好用，反饋糟糕就砍掉。?

不過這樣的驗證可靠，但顯然成本很高，要酌情使用，對于特別拿捏不定的可以用這方法，但如果每個需求或功能都用這套方法，其實意義就不大了。還是要通過更準確的判斷來對需求和功能定性，從而節省成本。

最近我看過一個最有趣的快速驗證方法，特別雞賊，是國外的，可以參考。

他們在想檢驗用戶是不是對他們的服務有興趣時，并沒有考慮做個簡陋的 MVP，因為他們認為沒有良好體驗的功能版本并不能很好地檢驗，所以他們就做了個精美的官網、列舉了他們要提供的所有的功能和服務、甚至支持真實支付成為會員。但是，他們沒有做任何功能和服務。?

這是他們官網首頁?

這是詢問用戶是不是要使用他們的服務。（做得跟真的似的......）

最后再告訴用戶：都是假的，還沒做好那。雖然都是假的，但用戶真正來到了哪個頁面、有多少關注這個服務、有哪些有付費意愿，這些數據是都拿到了。覺得靠譜接著做完，不靠譜就退款給用戶，成本極小。

是不是很牛逼的方法？

Q4. 算法是不是產品經理應該考慮的問題？

去年在點我達，我接手了調度模塊的設計，有幾個月時間一直在搭建產品框架和協作流程。在此之前，調度的產品、算法以及除了開發的方方面面，都只由一個同事負責。

與此同時，公司成立了算法研究院，請來了機器學習相關的博士，負責以調度為主的各項算法的設計。

于是原本從接受需求、設計功能，到研究算法、跟進實施的步驟，拆分成了兩塊：我帶的調度產品組負責調度產品，而研究員團隊負責調度算法。

現在的協作流程大概是這樣的：

1. 需求方提出需求。

例如，運營的同事認為，鮮花訂單的派單形式要有新的產品和算法支撐。這里講一下背景。我們的即時物流平臺會有外賣、商超、快遞、鮮花等一系列類型的訂單，其中外賣訂單是比較核心的，我們做的也比較久，因此很多產品模塊包括調度的設計，都是適應外賣場景的。當時鮮花則是相對新的業務。

2. 產品經理承接需求，并抽象。

我們小組的同事小 C 接到了這個需求，于是跟運營的同事多次溝通討論需求背景，以及跟相關的其他同事（比如銷售、商務的同事，以及騎手）確認實際場景。最終，抽象出算法問題。

比如，以下就是典型的算法問題描述：

在時效要求不高（以天為單位，而外賣是 1 小時內送達）、起點集聚終點分散（外賣的起點終點都是分散的）、每個騎手可攜帶鮮花訂單數量為 n （外賣的上限 m < n）的前提下，應該如何基于外賣調度邏輯來設計鮮花調度邏輯。

3. 算法研究員承接算法需求，解決算法課題。

算法研究員常博接受了算法需求，于是會把產品經理的描述再抽象一層，變成約束條件下的最優派單策略。以這些可量化的指標，就可以搭建起算法模型，依據已有的歷史數據，來跑出最合理的算法策略以及相關的參數設置。當然，在此過程中，不免會與小 C 和運營的同事持續溝通，有許多策略涉及的因素，比如在產品邏輯中的耦合性、比如在具體業務場景中的合理性，都要做大量探討。

像下圖就是典型的算法描述（是我們已棄用的一個算法）：

4. 產品經理整合算法模型成為產品功能。

此后，小 C 會考慮模型的細節，然后就跟把引擎裝入發動機一樣，設計出模型相關的配套產品功能。真正的需求文檔會是算法文檔長度的幾倍甚至十幾倍。后續就會跟技術協作，跟進研發。過程中也是會跟常博經常溝通，但在此階段負責人始終是小 C。

這種協作模式可以算是一種可參考的模板。我們運行了半年多，一直沒有問題，而且雙方的協作極少有模糊地帶。

那么回到題主的問題。可能現在沒有專職的算法研究員，那么產品和研發直接協作該怎么辦？

就推送喜歡的內容這個需求來說，首先，需求的目的、背景是產品經理要搞清楚的。推薦這些內容，是為了什么？淺顯的目的是為了讓用戶點擊，那背后相關的需求是什么？是現在用戶活躍度比較低、是用戶發掘優質內容的路徑過長，還是并不清楚老板說好像大家都有那就做吧？

其次，最關鍵的，需求的實現方式是產品經理要搞清楚的。需求和算法是兩個層面的事情，作為產品經理不能丟給研發說「做個推薦」就行了。顯然，推薦不是一種具體的算法課題。就好像告訴研發說「做個個人中心頁面」一樣不具體，這個頁面應該有什么、要達到什么效果，跟其他功能的邏輯關系......都是產品經理要考慮的。

就推薦來說，是基于什么數據做推薦呢？用戶的歷史瀏覽、用戶的已有關注、用戶的資料畫像，還是用戶的社交關系？即使作為產品經理，你不清楚基于規則、基于內容和協同過濾都是什么概念，你也要知道推薦不是憑空做的，是要根據具體的數據做分析的。

一個合理的梳理結果就像前文提到的，應該是類似于：「基于用戶已有關注對象的類型和這些對象發布內容的特征，來推薦更多同類的關注」或者「基于用戶目前的社交關系和相關的互動情況，推薦更多他可能喜歡的用戶」。

再之后，是跟研發搞清楚，所給出數據的意義（比如相關因素的權重），以及溝通邏輯上的合理性。比如，拿基于社交關系的推薦來說，用戶 A 給用戶 B 經常點贊意味著什么？用戶 A 跟用戶 C 每周有 15 次互動意味著什么？用戶 A 拉黑了用戶 D 意味著什么？這些不是算法課題！這些是產品經理應該以自己對用戶或主觀或客觀的感知，得出的功能判斷。

然后是建模。在這里確實有一個模糊地帶，如果是非常懶的研發，不愿意自己研究算法課題、自己建模，是有點尷尬。在職責劃分上，坦率地說有計算機背景的研發做建模和算法研究會更合理一些。但如果是我，我會很開心有往前多走一步的機會。如果把這件事做好，就相當于多了一項不錯的核心競爭力（可以想象未來懂算法、懂機器學習的產品經理會越來越吃香），也許會大大有利于你在公司甚至未來市場上的競爭力。

即使是你并不想有這項核心競爭力，在爭執不下的場景中，我也建議你暫時把這個任務做起來。畢竟產品經理是要為產品的方方面面負（tian）責（keng）的，產品因為任何問題沒有如期完成，產品經理都跑不了。

接下來就是根據建模的結果，梳理功能了。推薦當然不是簡單的建模而已，具體什么時間節點收集用戶信息？在什么功能模塊下推送給用戶？推送的數量有沒有限制？展示交互和界面都是怎樣的？這也都是產品經理要整理好的。

最后，具體用什么樣的代碼、什么樣的系統框架來實現，那就是研發的事情了。

大致來看，就是這樣的：

從題主的描述看，其實有點像省掉了「需求抽象」和「功能設計」的步驟，認為這純粹是個算法課題，需求來了就硬生生扔給研發，等待產品出爐了。我覺得這是不太合理的。

前文提到了，在點我達初期，實際上所有實現之前的步驟，都是由我一位同事完成的。這也是我推薦的方式。?

Q5. 如何看待「產品經理的時代正在慢慢結束」這個觀點？

用我的話歸納下就是：人人都是產品經理的時代結束了，職業產品經理的時代開始了。

大家可以回憶下程序員剛出現時，每個碼農都稱得上是「全棧工程師」吧。當時很多項目開發流程并不標準，對品質的要求也不會太高，所以除了巨頭企業，并不會分工太細。?

但十年過去，現在即便是一個小創業團隊，也至少會分清服務端工程師、iOS 工程師、安卓工程師和 Web 工程師，不會輕易招一個安卓工程師來寫后臺，也不會找個前端工程師做手機端。而且顯然對專業性方面的要求更高了。你不僅需要實現功能，還要保證代碼不冗余；不光讓代碼簡潔，還得有極強的擴展性。

兩點：對領域的細分更多；對專業的要求更高。也正在產品經理身上發生。?

要證明這個論點，有這么幾個論據：?

1. 互聯網產品的類別越來越多、差別越來越大

過去的互聯網產品，最早的巨頭是清一色的門戶網站。再后來，BAT 三分天下，開始走不一樣的路。時至今日，全國有幾千萬個互聯網項目在折騰，每個市場幾乎都有互聯網產品在覬覦。

最早的產品形態也很趨同，網站的形式簡單、軟件的形式也很簡單，后臺產品更不用說了，就那么幾家。移動互聯網出現后，產品之間越來越不一樣。比如布局的方式，就有宮格、列表、邊欄、標簽等各種各樣的。?

再比如對于線上社交的產品，和涉及線下服務的產品，產品邏輯也全然不同。

另外，由于業務需要，像后臺產品，規模稍大些的公司，都不會用第三方。后臺產品經理的需求也是節節攀升。更不用說其他比如 CRM、客服等內部使用的產品，自己招募團隊完成，應該會成為常態。?

我并不覺得現在同質化嚴重。反而是每天都有新花樣的產品出現、每時每刻都有新產品在挑戰舊霸主。

從這個角度說，對產品經理的要求真的不僅僅是「想個主意」這么簡單。

2. 用戶的需求越來越雜、產品的復雜度越來越高?

相應的，隨互聯網發展，不僅是用互聯網產品的用戶多了，他們的需求也變多了。原本可能只是滿足基本需求（能完成任務、做成這件事，專業說法是「可用性」），現在也要追求附加價值，比如是不是用著順心、用著舒服、用這個產品的時候又快又好？

從諾基亞到蘋果，飛躍的既是產品的復雜度，也是用戶的需求。大家不只滿足于「能夠打電話」、「能夠看照片」和「能夠上網」，而是要「很爽地打電話」、「很爽地看照片」和「很爽地上網」。進一步說，大家還需要蘋果手機本身給自己帶來的光環加成，不然為什么買 6s 都選玫瑰色。

要解決這些問題，可不是工程師夠多就行了。會需要更多牛逼的產品經理、更專業的產品經理，去滿足大家日益增長的需求。?

試想下 10 年前我們使用互聯網產品的心態，往往都是費勁心思一定要搞定，出了問題甚至會查攻略、給朋友打電話、向客服求助。現在呢？注冊的時候多一個步驟，你就滾犢子吧。

這些也給產品經理更高的要求：要懂各種知識，要理解各種用戶，要完成更難的工作。有個很簡單的例子：很多老板覺得做產品經理很簡單，自己去兼任，結果出來的產品都是慘不忍睹。

3. 產品經理將隨互聯網滲透進各行各業?

我之前提過，互聯網在過去可以稱得上是特有的「行業」，就跟旅游業啊、出版業啊、房地產業啊一樣的概念。但未來互聯網肯定是會滲透進各行各業的，未必是所謂「互聯網 +」的形式，但未來人們看待互聯網，不會把它當成是特殊的領域，而是會當成是誰都用得上的工具。?

現在的層面都還比較淺，但也有了雛形。只要是有點規模的公司、企業、單位，都在做自己的 APP，不管功能體驗如何，這些 APP 都是產品經理做出來的。未來它們會起到更多的作用，道理很簡單：過去的很多信息方面的記錄、傳遞、處理，都是落后的。互聯網就是解決這個問題的。?

比如我認識一個傳統行業的朋友。他告訴我現在他們的記錄和通訊方式特別落后，每個人平時工作都要拿厚厚的本子，整理的時間花去工作時間的大半。在需要拿到一些領導簽字的時候也是無比麻煩，需要挨個去找，費時費力。這樣的流程，未來必然是會被手機工具取代（在線記錄、電子簽名）。?

類似的行業有很多。只不過沒有到時候。

就跟個人電腦普及之前，大家用的還都是手寫表格、手寫文檔，覺得電腦是個新奇玩意兒一樣。未來互聯網工具普及之后，任何人都會對在手機上完成生活工作的大部分任務習以為常的。?

而這些產品、工具，都是要有產品經理去做的。

上面說的三方面，其實就是在表達「移動互聯網并沒有成熟」、「產品經理并不只是做創新」和「產品顯然并沒有在同質化」。?

綜上所述，我覺得職業產品經理的時代剛剛到來。?

未來，產品經理可能會細分到「技術型產品經理」、「運營型產品經理」、「體驗型產品經理」，或者按領域區分為「社交產品專家」、「后臺產品專家」、「電商產品專家」等等。

產品經理也會有更成熟的培養體系和成長體系出現，在高校里產品設計、項目管理這樣的課程會越來越多、更加專業。

整個行業，也會出現公認的教學著作和指導思想，產品方面的知識不再是零散的、虛無的或者有些模棱兩可的（看看張小龍被解讀成了什么樣子吧...），而是邏輯自洽、經過實踐檢驗的、屢試不爽的。?

那時候，可能就不會有人對產品經理有這么深的誤解了吧。至少不會覺得產品經理就是每天在想 idea 的人吧？

PMCAFF問答專場是一場與PMCAFF用戶互動的問答活動，我們每期都會邀請知名互聯網公司的一線產品從業者和咖友們共同交流，目前已成功舉辦過60+期，先后有來自騰訊、百度、阿里、360、小米、京東、去哪兒等大廠嘉賓入駐。

這個世界問題太多，我們需要一個能夠解決問題的人。

如果你有足夠的能力解決來自PMCAFF用戶在你的專業領域中，以不同的角度提出各類刁鉆問題，那么歡迎你參加PMCAFF問答專場。

活動申請可以添加工作人員微信溝通咨詢，加好友請備注：問答專場。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的前滴滴出行产品经理刘飞：写给产品经理的说明书（下）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。