嘉賓介紹

劉飛，資深產(chǎn)品人，前滴滴出行司機(jī)方向前產(chǎn)品負(fù)責(zé)人，點(diǎn)我達(dá)前產(chǎn)品專家，嘟嘟美甲聯(lián)合創(chuàng)始人，錘子科技產(chǎn)品經(jīng)理。在知乎累計(jì)446579次贊同，224900人關(guān)注，“產(chǎn)品經(jīng)理”話題下的優(yōu)秀回答者。虎嗅網(wǎng)、36kr、雷鋒網(wǎng)、人人都是產(chǎn)品經(jīng)理、知乎等媒體專欄作者，通過(guò)“在行”平臺(tái)線下幫助200余位產(chǎn)品學(xué)員進(jìn)階。開有公眾號(hào)“劉言飛語(yǔ)”。

新書《產(chǎn)品思維》將產(chǎn)品經(jīng)理工作中必須要面對(duì)的認(rèn)知盲點(diǎn)和實(shí)踐痛點(diǎn)掰開揉碎進(jìn)行講解，毫無(wú)保留地分享了產(chǎn)品新人迫切需要卻很難在公開渠道獲取的知識(shí)，現(xiàn)全網(wǎng)熱賣中。

Q1. 產(chǎn)品經(jīng)理如何在設(shè)計(jì)產(chǎn)品時(shí)避免給開發(fā)挖坑??

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

產(chǎn)品經(jīng)理需不需要懂技術(shù)是老生常談的問(wèn)題，我的回答是肯定要懂，關(guān)鍵在于，懂的技術(shù)是怎么樣的技術(shù)。

懂技術(shù)并不是就要能自己成為架構(gòu)師、自己成為工程師，又可以規(guī)劃技術(shù)架構(gòu)又能實(shí)現(xiàn)產(chǎn)品功能。懂技術(shù)是要明白技術(shù)實(shí)現(xiàn)的邏輯。

比如，我們?cè)谧龅呐渌蜆I(yè)務(wù)，需要有配送員、訂單、商家多種信息，每種信息是存放在各自的數(shù)據(jù)結(jié)構(gòu)里的，它們之間又通過(guò)邏輯關(guān)系串聯(lián)起來(lái)。這些產(chǎn)品上都未必體現(xiàn)得出來(lái)，但在很多產(chǎn)品設(shè)計(jì)的時(shí)候要考慮到，要做某個(gè)新業(yè)務(wù)時(shí)，發(fā)現(xiàn)商家要分截然不同的兩類，那中間的邏輯怎么樣成本最低，是同一張表用屬性區(qū)分、還是新造一張表，都是要跟技術(shù)一起討論研究的。?

平時(shí)，也建議多看些技術(shù)相關(guān)的文章和科普。注意，千萬(wàn)不要買什么《七天掌握安卓系統(tǒng)》之類的書，看一些跟產(chǎn)品息息相關(guān)的比較好。

2. 學(xué)會(huì)梳理產(chǎn)品邏輯?

這個(gè)邏輯不是 APP 上有幾個(gè) tab 頁(yè)，也不是功能之間簡(jiǎn)單的關(guān)系，說(shuō)的是背后的幾個(gè)邏輯：數(shù)據(jù)結(jié)構(gòu)、信息流程和其它的邏輯關(guān)系。

然而我見到的很多產(chǎn)品經(jīng)理，并不太把這個(gè)當(dāng)回事。「只要給我實(shí)現(xiàn)就行了，我不關(guān)心怎么實(shí)現(xiàn)。」

數(shù)據(jù)結(jié)構(gòu)其實(shí)是第一重要的東西，可以讓產(chǎn)品經(jīng)理非常深入地理解技術(shù)實(shí)現(xiàn)的邏輯。

比如，這是美團(tuán)酒店銷售的數(shù)據(jù)結(jié)構(gòu)。可以讓整個(gè)酒店商品的邏輯一目了然，而不是零散的需求。?

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

比如，這是嘟嘟美甲最初交互草稿里，我們梳理的訂單狀態(tài)轉(zhuǎn)化圖。

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

比如，我們前段時(shí)間在設(shè)計(jì)取消訂單機(jī)制的時(shí)候，發(fā)現(xiàn)有很多種情況，每種情況的文案也不應(yīng)該一樣，這時(shí)候就要梳理出每種具體的提示，不能讓技術(shù)去幫你完善。

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

3. 出現(xiàn)坑的時(shí)候，多復(fù)盤?

不同的產(chǎn)品差異很大，即使再有經(jīng)驗(yàn)的產(chǎn)品經(jīng)理，也不一定就永遠(yuǎn)不會(huì)埋坑。

坑出現(xiàn)了之后，除了盡快填起來(lái)，還要去復(fù)盤，多想想，怎么避免下次再進(jìn)坑。

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

關(guān)于產(chǎn)品技術(shù)協(xié)作，在我們公司，是設(shè)置了一套復(fù)盤機(jī)制的。每次出現(xiàn)大的問(wèn)題，都會(huì)在解決之后，召集一次大會(huì)，所有相關(guān)人員加產(chǎn)品和技術(shù)的總負(fù)責(zé)人都在場(chǎng)的情況下，把事情說(shuō)清楚，搞明白原委，并且會(huì)上要制定解決方案。?

經(jīng)過(guò)一兩個(gè)月的嘗試，我們發(fā)現(xiàn)，大多數(shù)的坑都是同樣的原因，我們就重點(diǎn)攻克這個(gè)難點(diǎn)，慢慢讓坑變少，原來(lái)的大坑也變小了。

Q2. 作為產(chǎn)品經(jīng)理，你是如何分析和管理你的產(chǎn)品需求的？

下面是我的經(jīng)驗(yàn)，我都寫在新書《產(chǎn)品思維》中，在這里也簡(jiǎn)單講一下，解決這個(gè)問(wèn)題未必是只從需求管理來(lái)做，而是整體流程上把控。?

1. 獲取階段?

需求的來(lái)源有很多。業(yè)務(wù)越復(fù)雜，需求就越雜。一個(gè)淘寶，產(chǎn)品需求就可以拆分成分類、檢索、排序、商品展示、營(yíng)銷活動(dòng)、支付、配送、售后等等。

你的職級(jí)越高，也代表著身邊人提需求的可能性越大。初入行的產(chǎn)品專員或助理，主要是得到被安排的任務(wù)；初級(jí)產(chǎn)品經(jīng)理，需求來(lái)源主要是用戶和上級(jí)；產(chǎn)品負(fù)責(zé)人，需求來(lái)源就要增加老板和其他相關(guān)部門；而作為老板，誰(shuí)都可能跟他提產(chǎn)品需求。

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

做判斷的內(nèi)容具體是什么呢？

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

同樣是頁(yè)面寫錯(cuò)了一個(gè)字，把「登錄」寫成「登陸」，和把「獎(jiǎng)勵(lì) 15 元」寫成「獎(jiǎng)勵(lì) 50 元」，重要性不言而喻吧。有個(gè)大致的預(yù)估。?

第二，考慮需求來(lái)源。

需求來(lái)源會(huì)表明一些事情，要慎重思考。比如老板提到的，未必是目前你能理解的，但他認(rèn)為特別重要，就暫且把這個(gè)當(dāng)成特別重要的，這是政治任務(wù)。再比如是用戶提到的，但細(xì)想他并不是目標(biāo)用戶，他的需求就不必太關(guān)注。

第三，簡(jiǎn)要得到需求背景。?

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

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

最后，依據(jù)這三個(gè)因素，判斷屬于大致哪個(gè)類別的。一般的需求管理都會(huì)分 P0-P3 或者 P1-P4，總之先打個(gè)標(biāo)簽。這里的技巧是盡量標(biāo)記為比估計(jì)的更重要一層的需求，就是你感覺是 P2 的，暫且先標(biāo)為 P1。這樣以防錯(cuò)漏，低優(yōu)先級(jí)的標(biāo)成高的沒關(guān)系，但高優(yōu)先級(jí)的標(biāo)低了會(huì)出現(xiàn)麻煩。這時(shí)候的預(yù)估往往不準(zhǔn)確，但沒關(guān)系，等后面第二步再說(shuō)。

比如這樣：?

?2. 討論/設(shè)計(jì)階段

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

我們會(huì)詳細(xì)討論每個(gè)需求的情況，確認(rèn)幾個(gè)事項(xiàng)：

一，需求的優(yōu)先級(jí)

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

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

• 不做會(huì)造成嚴(yán)重的問(wèn)題和惡劣的影響的

• 做了會(huì)產(chǎn)生巨大好處和極佳效果的

• 跟重要合作對(duì)象或投資人有關(guān)的

• 跟核心用戶利益有關(guān)的

• 跟大部分用戶權(quán)益有關(guān)的

• 跟效率或成本有關(guān)的

• 跟用戶體驗(yàn)有關(guān)的

緊急程度按這個(gè)排序：

• 不做錯(cuò)誤會(huì)持續(xù)發(fā)生，造成嚴(yán)重影響

• 在一定時(shí)間內(nèi)可控，但長(zhǎng)期會(huì)有糟糕的影響

• 做了立刻能解決很多問(wèn)題、產(chǎn)生正面的影響

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

大家把能考慮到的因素想全，會(huì)標(biāo)上 P1 - P4 的優(yōu)先級(jí)。

二，方案的方向

需求有不同的解決辦法，我們會(huì)討論清楚到底用哪種解決。比如我們發(fā)現(xiàn)有刷單現(xiàn)象，可以事前提醒，告知用戶目前地理位置或訂單信息有嫌疑；可以事中限制，必須到達(dá)指定地點(diǎn)、拍攝當(dāng)?shù)卣掌鹊炔僮鱽?lái)限制用戶；可以事后懲戒，提供給客服或者業(yè)務(wù)部門疑似刷單的名單和證據(jù)，罰款或者封號(hào)。這幾項(xiàng)到底做哪個(gè)？還是做其中哪幾個(gè)？優(yōu)劣在哪？需要好好討論。?

有時(shí)會(huì)有大概的方向，再去跟相關(guān)部門和需求相關(guān)的同事確認(rèn)。這不在本文討論范圍內(nèi)，暫且不提。

三，指定負(fù)責(zé)人

我之前經(jīng)歷過(guò)兩種需求分配制度。一種是每個(gè)人負(fù)責(zé)的需求范圍有清晰的邊界，那需求對(duì)應(yīng)哪個(gè)模塊，就直接分配即可；另一種是團(tuán)隊(duì)作戰(zhàn)，每次指定或者認(rèn)領(lǐng)，誰(shuí)都有可能接手任意需求。

前一種的好處在，模塊清晰，負(fù)責(zé)人可以對(duì)自己負(fù)責(zé)的部分足夠熟悉，但缺點(diǎn)是，工作量很可能不平衡，有的同事一直在忙，有的可能就比較閑，因?yàn)樾枨蟛皇瞧骄茨K分布的。

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

不管怎么樣，一定一定要指定負(fù)責(zé)人，他需要對(duì)需求負(fù)責(zé)，一直到產(chǎn)品上線后，出了的問(wèn)題他也要承擔(dān)責(zé)任。要保證運(yùn)營(yíng)良好的工作責(zé)任制。?

四、劃定時(shí)間節(jié)點(diǎn)

許多產(chǎn)品經(jīng)理會(huì)疏漏這點(diǎn)，只是覺得盡快去做，但總是做不完。

時(shí)間節(jié)點(diǎn)至少也要包括方案完成的時(shí)間。就是這個(gè)需求，能夠完好提交給開發(fā)的時(shí)間。如果沒有這個(gè)時(shí)間，對(duì)需求的管理就沒有一點(diǎn)意義了。

另外，如果是要跟相關(guān)部門再確認(rèn)、或者要跟用戶調(diào)研、或者要統(tǒng)計(jì)各種數(shù)據(jù)再作判斷的需求，那還要有調(diào)研/討論完成的時(shí)間。

這個(gè)時(shí)間節(jié)點(diǎn)的劃定，主要是按照方案的復(fù)雜程度，用經(jīng)驗(yàn)做個(gè)簡(jiǎn)單判斷。最長(zhǎng)的時(shí)間周期也不能超過(guò)一周，保證需求的推動(dòng)進(jìn)度，因?yàn)楹茈y有復(fù)雜程度超過(guò)一周的產(chǎn)品需求。對(duì)于有嚴(yán)格上線時(shí)間的需求（經(jīng)常會(huì)出現(xiàn)，比如很苛刻的老板需求、投資人需求、政府需求等），要倒推出最合理又富有余地的時(shí)間節(jié)點(diǎn)。?

討論完剛剛?cè)氤氐囊慌枨?#xff0c;我們會(huì)再整理和討論其它狀態(tài)（有方案或者調(diào)研結(jié)論）的需求。這樣會(huì)議結(jié)束，每條需求都會(huì)得到更新。

我們?cè)谶@個(gè)時(shí)刻，一般會(huì)讓負(fù)責(zé)的產(chǎn)品經(jīng)理，及時(shí)更新需求狀態(tài)給需求來(lái)源方。當(dāng)然，來(lái)源方 95% 的情況下會(huì)對(duì)進(jìn)度不滿意，這很正常，但除非來(lái)源方有確鑿的理由，我們不會(huì)輕易調(diào)整優(yōu)先級(jí)和時(shí)間節(jié)點(diǎn)。?

3. 待開發(fā)階段?

有了確切方案，我們會(huì)盡快跟研發(fā)的同事做可行性評(píng)審。這一步必不可少。我感覺題主出現(xiàn)的「落不了地」和「頻繁更改」的問(wèn)題，要著重在這個(gè)步驟里解決。

可行性評(píng)審上，完成的是對(duì)需求的大致評(píng)估，要做的有這么幾件事：

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

在技術(shù)方案上，是不是能夠完成？就是讓技術(shù)部門評(píng)估這個(gè)問(wèn)題。

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

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

第三，涉及的產(chǎn)品和技術(shù)環(huán)節(jié)有哪些？

這個(gè)需要相關(guān)的同事仔細(xì)討論。尤其是很多公司產(chǎn)品線比較多，有可能存在牽一發(fā)動(dòng)全身的情況，如果相關(guān)的產(chǎn)品同事和技術(shù)同事不知情，必然會(huì)延期，必然會(huì)扯皮，必然會(huì)造成麻煩，必然會(huì)有各種改動(dòng)。即便是再小的產(chǎn)品，也要分前后端，讓技術(shù)的同事來(lái)判斷有哪些人需要知情和參與評(píng)估。

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

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

有了這樣的討論，會(huì)議輸出的，就是比較嚴(yán)謹(jǐn)?shù)目蓤?zhí)行方案（或草稿）了。

如果會(huì)上遇到各種問(wèn)題，要確認(rèn)解決問(wèn)題的時(shí)間節(jié)點(diǎn)。

4. 開發(fā)階段

開發(fā)需求的次序，我們不是完全按照需求池里的需求優(yōu)先級(jí)來(lái)的。剛才說(shuō)到，在可行性評(píng)估會(huì)上，我們會(huì)核算大致的需求成本，那成本結(jié)合需求的優(yōu)先級(jí)，就可以得出需求的性價(jià)比了。?

大概是用這樣的表格：?

提交開發(fā)之后，相當(dāng)于關(guān)閉需求。原則上，本次迭代不再加入新的需求。

當(dāng)然啦，如果什么事情都是原則上那樣...就不會(huì)出現(xiàn)這么多扯皮的情況了。?

在開發(fā)中，扯皮的問(wèn)題歸納起來(lái)就是三種：需求太多，沒按時(shí)做完；需求有改動(dòng)，導(dǎo)致了額外工作量以及開發(fā)的不滿；有新的緊急需求，導(dǎo)致發(fā)布延期。?

這三種問(wèn)題，再抽象一下，導(dǎo)致的原因很多，大概有幾類，分別是：

?一，產(chǎn)品方案不完整

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

之前我們經(jīng)常出現(xiàn)，做的時(shí)候技術(shù)才發(fā)現(xiàn)臥槽這里有個(gè)邏輯沒想通啊。然后喊產(chǎn)品來(lái)一起討論的時(shí)候，大家發(fā)現(xiàn)需要加一些功能才能完善邏輯。最后結(jié)果就是周六加了個(gè)班，大家很不開心。

這種事情也不好追責(zé)，畢竟參與者很多，流程拖得很長(zhǎng)。硬要說(shuō)是負(fù)責(zé)需求的產(chǎn)品經(jīng)理有問(wèn)題倒也可以，但總是片面的：他也不一定知道技術(shù)上開發(fā)才發(fā)現(xiàn)的邏輯。?

后來(lái)我們反思，各個(gè)流程中的環(huán)節(jié)都要做一些調(diào)整，才能確保最終產(chǎn)品方案的完整：?

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

• 討論方案時(shí)，所有產(chǎn)品經(jīng)理參與小組討論，一起提出疑惑，發(fā)現(xiàn)問(wèn)題。

• 可行性評(píng)審時(shí)，技術(shù)從邏輯角度提出質(zhì)疑，發(fā)現(xiàn)問(wèn)題。

之后再出問(wèn)題，會(huì)回溯原因。如果是前兩個(gè)環(huán)節(jié)出的問(wèn)題，那就是產(chǎn)品經(jīng)理的責(zé)任；如果是產(chǎn)品經(jīng)理未知的邏輯，那就是可行性評(píng)審中，技術(shù)的同事的責(zé)任。

二，需求方的主觀改動(dòng)

這種情況基本都是需求方或者產(chǎn)品經(jīng)理的問(wèn)題：他們?cè)谔峤环桨盖皼]有完全想清楚。

有時(shí)候都開始開發(fā)了，業(yè)務(wù)部門來(lái)人說(shuō)，哎我們發(fā)現(xiàn)這個(gè)問(wèn)題好像不存在了，大家不要做了。他們覺得無(wú)所謂，還減輕了開發(fā)負(fù)擔(dān)。但對(duì)技術(shù)部門的同事來(lái)說(shuō)，就好像在說(shuō)「你被耍了，哈哈哈」。造成的影響是惡劣的。

產(chǎn)品經(jīng)理在對(duì)接他們的需求時(shí)要做判斷，他們是不是完全想清楚了，是靈機(jī)一動(dòng)的小點(diǎn)子，還是不得不解決的問(wèn)題。

另外，還有一種情況，是需求方跟產(chǎn)品經(jīng)理對(duì)接時(shí)出了問(wèn)題。表述有誤，并且方案沒有跟他們核對(duì)清楚，結(jié)果產(chǎn)品功能上線，才發(fā)現(xiàn)并沒有解決問(wèn)題。

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

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

三、無(wú)法預(yù)測(cè)的客觀原因

這種是唯一一種能夠接受的原因，不需要有誰(shuí)承擔(dān)責(zé)任。?

比如，本來(lái)要做一個(gè)功能狙擊對(duì)手，結(jié)果做了一半，競(jìng)爭(zhēng)對(duì)手倒閉了，那這個(gè)功能就沒有意義了，確實(shí)要廢除。

還有一些業(yè)務(wù)上的確無(wú)法預(yù)測(cè)的各種原因，導(dǎo)致原本存在的問(wèn)題不存在了，也無(wú)可厚非。

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

5. 復(fù)盤階段

需求從獲取到上線，走完生命周期之后，還要有一個(gè)很重要的復(fù)盤階段，尤其是在需求管理出過(guò)故障和問(wèn)題的時(shí)候。

略靠譜的團(tuán)隊(duì)，都會(huì)有復(fù)盤的機(jī)制，主要是防止問(wèn)題再次發(fā)生。解決問(wèn)題很簡(jiǎn)單，如何盡量規(guī)避下次再出問(wèn)題很復(fù)雜。?

大致就是，要搞清楚之前出現(xiàn)問(wèn)題的所有邏輯和流程，再去看在哪些環(huán)節(jié)可以做點(diǎn)什么，去防止再次出現(xiàn)。這塊的內(nèi)容說(shuō)得多了又得寫一篇文，就不多講了。?

以上就是我的經(jīng)驗(yàn)，僅供參考。沒有什么流程和機(jī)制是完美的，關(guān)鍵在于怎么去解決自己的問(wèn)題。如果哪些思路給你了啟發(fā)，那就夠了。

Q3. 產(chǎn)品經(jīng)理如何給用戶需求排序？

需求分析有兩種核心的方法：定性分析和定量分析。我就從這個(gè)維度來(lái)解釋下怎樣對(duì)需求做判斷。

1. 定性分析

1.1 KANO 模型

KANO 模型是現(xiàn)在大家都比較認(rèn)可的方法。實(shí)際上，這個(gè)模型即使你沒有系統(tǒng)學(xué)習(xí)過(guò)，也肯定對(duì)其理念有一定體會(huì)。?

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

我這里用的是飛哥簡(jiǎn)化版，大概是這樣的：

解釋下這個(gè)圖。

作為一個(gè)功能， 每行對(duì)應(yīng)的是如果有的話，用戶會(huì)開心、無(wú)所謂還是不開心，每列則是如果沒有的情況。具體說(shuō)：

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

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

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

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

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

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

驚喜：如果功能不存在的時(shí)候用戶并沒有感覺，說(shuō)明這個(gè)功能用戶之前沒有預(yù)期，但功能存在用戶很開心，也就是說(shuō)達(dá)到了驚喜的效果。這就是小米常說(shuō)的『驚喜點(diǎn)』，所謂讓用戶尖叫的功能。?

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

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

1.2 用戶訪談

除了通過(guò)常識(shí)對(duì)需求做以上提到的判斷，深度訪談可以作為配合，來(lái)驗(yàn)證之前的考慮。

訪談的時(shí)候盡量用開放性的問(wèn)題來(lái)溝通，不要直接問(wèn)『如果有這樣的功能你會(huì)不會(huì)用？』、『你到底想要什么樣的功能？』，而是了解用戶背后的需求、TA 使用的場(chǎng)景以及 TA 過(guò)去滿足相同需求的方法，這些信息能提供關(guān)鍵的證據(jù)，來(lái)輔助驗(yàn)證你的判斷。?

溝通時(shí)，對(duì)同樣的功能，也可以用多種問(wèn)法來(lái)試探用戶，以防用戶不夠理解；同時(shí)，也要反復(fù)對(duì)同一個(gè)功能做深入的探討：『這樣不好的話，那如果是那樣呢？』『你覺得它不符合你要求的原因是什么呢？』再即時(shí)地做出反應(yīng)，能獲得更有價(jià)值的信息。?

2. 定量分析?

如果定性分析不能保證效果，那定量分析就可以獲得更準(zhǔn)確的信息，相應(yīng)地，成本會(huì)偏高一些。?

2.1 數(shù)據(jù)獲取?

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

對(duì)于前者，具體方法很多，公開渠道、咨詢公司或者調(diào)研都可以，就不展開說(shuō)了。對(duì)于后者，關(guān)鍵就是觀察用戶是不是在用某個(gè)功能和在用這個(gè)功能時(shí)的具體行為。

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

2.2 快速驗(yàn)證?

訪談的結(jié)果有時(shí)候不會(huì)特別可靠，快速驗(yàn)證是最重要的方式。具體方法有很多，包括大家常提到的 Demo 或者 MVP（最簡(jiǎn)化可實(shí)行產(chǎn)品） 或者灰度發(fā)布或者 A/B 測(cè)試都可以作為驗(yàn)證手段。?

其實(shí)大部分手段只適用于功能已經(jīng)比較完善的情況下，也就是做事后判斷，而不是事前的預(yù)測(cè)。

折衷的方案是：用最簡(jiǎn)陋的方式做一個(gè)滿足需求的功能出來(lái)，投入到市場(chǎng)中觀察用戶的反饋，來(lái)確定功能的重要程度。如果用戶反饋良好，就做得更完善、優(yōu)化得更好用，反饋糟糕就砍掉。?

不過(guò)這樣的驗(yàn)證可靠，但顯然成本很高，要酌情使用，對(duì)于特別拿捏不定的可以用這方法，但如果每個(gè)需求或功能都用這套方法，其實(shí)意義就不大了。還是要通過(guò)更準(zhǔn)確的判斷來(lái)對(duì)需求和功能定性，從而節(jié)省成本。

最近我看過(guò)一個(gè)最有趣的快速驗(yàn)證方法，特別雞賊，是國(guó)外的，可以參考。

他們?cè)谙霗z驗(yàn)用戶是不是對(duì)他們的服務(wù)有興趣時(shí)，并沒有考慮做個(gè)簡(jiǎn)陋的 MVP，因?yàn)樗麄冋J(rèn)為沒有良好體驗(yàn)的功能版本并不能很好地檢驗(yàn)，所以他們就做了個(gè)精美的官網(wǎng)、列舉了他們要提供的所有的功能和服務(wù)、甚至支持真實(shí)支付成為會(huì)員。但是，他們沒有做任何功能和服務(wù)。?

這是他們官網(wǎng)首頁(yè)?

這是詢問(wèn)用戶是不是要使用他們的服務(wù)。（做得跟真的似的......）

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

是不是很牛逼的方法？

Q4. 算法是不是產(chǎn)品經(jīng)理應(yīng)該考慮的問(wèn)題？

去年在點(diǎn)我達(dá)，我接手了調(diào)度模塊的設(shè)計(jì)，有幾個(gè)月時(shí)間一直在搭建產(chǎn)品框架和協(xié)作流程。在此之前，調(diào)度的產(chǎn)品、算法以及除了開發(fā)的方方面面，都只由一個(gè)同事負(fù)責(zé)。

與此同時(shí)，公司成立了算法研究院，請(qǐng)來(lái)了機(jī)器學(xué)習(xí)相關(guān)的博士，負(fù)責(zé)以調(diào)度為主的各項(xiàng)算法的設(shè)計(jì)。

于是原本從接受需求、設(shè)計(jì)功能，到研究算法、跟進(jìn)實(shí)施的步驟，拆分成了兩塊：我?guī)У恼{(diào)度產(chǎn)品組負(fù)責(zé)調(diào)度產(chǎn)品，而研究員團(tuán)隊(duì)負(fù)責(zé)調(diào)度算法。

現(xiàn)在的協(xié)作流程大概是這樣的：

1. 需求方提出需求。

例如，運(yùn)營(yíng)的同事認(rèn)為，鮮花訂單的派單形式要有新的產(chǎn)品和算法支撐。這里講一下背景。我們的即時(shí)物流平臺(tái)會(huì)有外賣、商超、快遞、鮮花等一系列類型的訂單，其中外賣訂單是比較核心的，我們做的也比較久，因此很多產(chǎn)品模塊包括調(diào)度的設(shè)計(jì)，都是適應(yīng)外賣場(chǎng)景的。當(dāng)時(shí)鮮花則是相對(duì)新的業(yè)務(wù)。

2. 產(chǎn)品經(jīng)理承接需求，并抽象。

我們小組的同事小 C 接到了這個(gè)需求，于是跟運(yùn)營(yíng)的同事多次溝通討論需求背景，以及跟相關(guān)的其他同事（比如銷售、商務(wù)的同事，以及騎手）確認(rèn)實(shí)際場(chǎng)景。最終，抽象出算法問(wèn)題。

比如，以下就是典型的算法問(wèn)題描述：

在時(shí)效要求不高（以天為單位，而外賣是 1 小時(shí)內(nèi)送達(dá)）、起點(diǎn)集聚終點(diǎn)分散（外賣的起點(diǎn)終點(diǎn)都是分散的）、每個(gè)騎手可攜帶鮮花訂單數(shù)量為 n （外賣的上限 m < n）的前提下，應(yīng)該如何基于外賣調(diào)度邏輯來(lái)設(shè)計(jì)鮮花調(diào)度邏輯。

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

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

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

4. 產(chǎn)品經(jīng)理整合算法模型成為產(chǎn)品功能。

此后，小 C 會(huì)考慮模型的細(xì)節(jié)，然后就跟把引擎裝入發(fā)動(dòng)機(jī)一樣，設(shè)計(jì)出模型相關(guān)的配套產(chǎn)品功能。真正的需求文檔會(huì)是算法文檔長(zhǎng)度的幾倍甚至十幾倍。后續(xù)就會(huì)跟技術(shù)協(xié)作，跟進(jìn)研發(fā)。過(guò)程中也是會(huì)跟常博經(jīng)常溝通，但在此階段負(fù)責(zé)人始終是小 C。

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

那么回到題主的問(wèn)題。可能現(xiàn)在沒有專職的算法研究員，那么產(chǎn)品和研發(fā)直接協(xié)作該怎么辦？

就推送喜歡的內(nèi)容這個(gè)需求來(lái)說(shuō)，首先，需求的目的、背景是產(chǎn)品經(jīng)理要搞清楚的。推薦這些內(nèi)容，是為了什么？淺顯的目的是為了讓用戶點(diǎn)擊，那背后相關(guān)的需求是什么？是現(xiàn)在用戶活躍度比較低、是用戶發(fā)掘優(yōu)質(zhì)內(nèi)容的路徑過(guò)長(zhǎng)，還是并不清楚老板說(shuō)好像大家都有那就做吧？

其次，最關(guān)鍵的，需求的實(shí)現(xiàn)方式是產(chǎn)品經(jīng)理要搞清楚的。需求和算法是兩個(gè)層面的事情，作為產(chǎn)品經(jīng)理不能丟給研發(fā)說(shuō)「做個(gè)推薦」就行了。顯然，推薦不是一種具體的算法課題。就好像告訴研發(fā)說(shuō)「做個(gè)個(gè)人中心頁(yè)面」一樣不具體，這個(gè)頁(yè)面應(yīng)該有什么、要達(dá)到什么效果，跟其他功能的邏輯關(guān)系......都是產(chǎn)品經(jīng)理要考慮的。

就推薦來(lái)說(shuō)，是基于什么數(shù)據(jù)做推薦呢？用戶的歷史瀏覽、用戶的已有關(guān)注、用戶的資料畫像，還是用戶的社交關(guān)系？即使作為產(chǎn)品經(jīng)理，你不清楚基于規(guī)則、基于內(nèi)容和協(xié)同過(guò)濾都是什么概念，你也要知道推薦不是憑空做的，是要根據(jù)具體的數(shù)據(jù)做分析的。

一個(gè)合理的梳理結(jié)果就像前文提到的，應(yīng)該是類似于：「基于用戶已有關(guān)注對(duì)象的類型和這些對(duì)象發(fā)布內(nèi)容的特征，來(lái)推薦更多同類的關(guān)注」或者「基于用戶目前的社交關(guān)系和相關(guān)的互動(dòng)情況，推薦更多他可能喜歡的用戶」。

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

然后是建模。在這里確實(shí)有一個(gè)模糊地帶，如果是非常懶的研發(fā)，不愿意自己研究算法課題、自己建模，是有點(diǎn)尷尬。在職責(zé)劃分上，坦率地說(shuō)有計(jì)算機(jī)背景的研發(fā)做建模和算法研究會(huì)更合理一些。但如果是我，我會(huì)很開心有往前多走一步的機(jī)會(huì)。如果把這件事做好，就相當(dāng)于多了一項(xiàng)不錯(cuò)的核心競(jìng)爭(zhēng)力（可以想象未來(lái)懂算法、懂機(jī)器學(xué)習(xí)的產(chǎn)品經(jīng)理會(huì)越來(lái)越吃香），也許會(huì)大大有利于你在公司甚至未來(lái)市場(chǎng)上的競(jìng)爭(zhēng)力。

即使是你并不想有這項(xiàng)核心競(jìng)爭(zhēng)力，在爭(zhēng)執(zhí)不下的場(chǎng)景中，我也建議你暫時(shí)把這個(gè)任務(wù)做起來(lái)。畢竟產(chǎn)品經(jīng)理是要為產(chǎn)品的方方面面負(fù)（tian）責(zé)（keng）的，產(chǎn)品因?yàn)槿魏螁?wèn)題沒有如期完成，產(chǎn)品經(jīng)理都跑不了。

接下來(lái)就是根據(jù)建模的結(jié)果，梳理功能了。推薦當(dāng)然不是簡(jiǎn)單的建模而已，具體什么時(shí)間節(jié)點(diǎn)收集用戶信息？在什么功能模塊下推送給用戶？推送的數(shù)量有沒有限制？展示交互和界面都是怎樣的？這也都是產(chǎn)品經(jīng)理要整理好的。

最后，具體用什么樣的代碼、什么樣的系統(tǒng)框架來(lái)實(shí)現(xiàn)，那就是研發(fā)的事情了。

大致來(lái)看，就是這樣的：

從題主的描述看，其實(shí)有點(diǎn)像省掉了「需求抽象」和「功能設(shè)計(jì)」的步驟，認(rèn)為這純粹是個(gè)算法課題，需求來(lái)了就硬生生扔給研發(fā)，等待產(chǎn)品出爐了。我覺得這是不太合理的。

前文提到了，在點(diǎn)我達(dá)初期，實(shí)際上所有實(shí)現(xiàn)之前的步驟，都是由我一位同事完成的。這也是我推薦的方式。?

Q5. 如何看待「產(chǎn)品經(jīng)理的時(shí)代正在慢慢結(jié)束」這個(gè)觀點(diǎn)？

用我的話歸納下就是：人人都是產(chǎn)品經(jīng)理的時(shí)代結(jié)束了，職業(yè)產(chǎn)品經(jīng)理的時(shí)代開始了。

大家可以回憶下程序員剛出現(xiàn)時(shí)，每個(gè)碼農(nóng)都稱得上是「全棧工程師」吧。當(dāng)時(shí)很多項(xiàng)目開發(fā)流程并不標(biāo)準(zhǔn)，對(duì)品質(zhì)的要求也不會(huì)太高，所以除了巨頭企業(yè)，并不會(huì)分工太細(xì)。?

但十年過(guò)去，現(xiàn)在即便是一個(gè)小創(chuàng)業(yè)團(tuán)隊(duì)，也至少會(huì)分清服務(wù)端工程師、iOS 工程師、安卓工程師和 Web 工程師，不會(huì)輕易招一個(gè)安卓工程師來(lái)寫后臺(tái)，也不會(huì)找個(gè)前端工程師做手機(jī)端。而且顯然對(duì)專業(yè)性方面的要求更高了。你不僅需要實(shí)現(xiàn)功能，還要保證代碼不冗余；不光讓代碼簡(jiǎn)潔，還得有極強(qiáng)的擴(kuò)展性。

兩點(diǎn)：對(duì)領(lǐng)域的細(xì)分更多；對(duì)專業(yè)的要求更高。也正在產(chǎn)品經(jīng)理身上發(fā)生。?

要證明這個(gè)論點(diǎn)，有這么幾個(gè)論據(jù)：?

1. 互聯(lián)網(wǎng)產(chǎn)品的類別越來(lái)越多、差別越來(lái)越大

過(guò)去的互聯(lián)網(wǎng)產(chǎn)品，最早的巨頭是清一色的門戶網(wǎng)站。再后來(lái)，BAT 三分天下，開始走不一樣的路。時(shí)至今日，全國(guó)有幾千萬(wàn)個(gè)互聯(lián)網(wǎng)項(xiàng)目在折騰，每個(gè)市場(chǎng)幾乎都有互聯(lián)網(wǎng)產(chǎn)品在覬覦。

最早的產(chǎn)品形態(tài)也很趨同，網(wǎng)站的形式簡(jiǎn)單、軟件的形式也很簡(jiǎn)單，后臺(tái)產(chǎn)品更不用說(shuō)了，就那么幾家。移動(dòng)互聯(lián)網(wǎng)出現(xiàn)后，產(chǎn)品之間越來(lái)越不一樣。比如布局的方式，就有宮格、列表、邊欄、標(biāo)簽等各種各樣的。?

再比如對(duì)于線上社交的產(chǎn)品，和涉及線下服務(wù)的產(chǎn)品，產(chǎn)品邏輯也全然不同。

另外，由于業(yè)務(wù)需要，像后臺(tái)產(chǎn)品，規(guī)模稍大些的公司，都不會(huì)用第三方。后臺(tái)產(chǎn)品經(jīng)理的需求也是節(jié)節(jié)攀升。更不用說(shuō)其他比如 CRM、客服等內(nèi)部使用的產(chǎn)品，自己招募團(tuán)隊(duì)完成，應(yīng)該會(huì)成為常態(tài)。?

我并不覺得現(xiàn)在同質(zhì)化嚴(yán)重。反而是每天都有新花樣的產(chǎn)品出現(xiàn)、每時(shí)每刻都有新產(chǎn)品在挑戰(zhàn)舊霸主。

從這個(gè)角度說(shuō)，對(duì)產(chǎn)品經(jīng)理的要求真的不僅僅是「想個(gè)主意」這么簡(jiǎn)單。

2. 用戶的需求越來(lái)越雜、產(chǎn)品的復(fù)雜度越來(lái)越高?

相應(yīng)的，隨互聯(lián)網(wǎng)發(fā)展，不僅是用互聯(lián)網(wǎng)產(chǎn)品的用戶多了，他們的需求也變多了。原本可能只是滿足基本需求（能完成任務(wù)、做成這件事，專業(yè)說(shuō)法是「可用性」），現(xiàn)在也要追求附加價(jià)值，比如是不是用著順心、用著舒服、用這個(gè)產(chǎn)品的時(shí)候又快又好？

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

要解決這些問(wèn)題，可不是工程師夠多就行了。會(huì)需要更多牛逼的產(chǎn)品經(jīng)理、更專業(yè)的產(chǎn)品經(jīng)理，去滿足大家日益增長(zhǎng)的需求。?

試想下 10 年前我們使用互聯(lián)網(wǎng)產(chǎn)品的心態(tài)，往往都是費(fèi)勁心思一定要搞定，出了問(wèn)題甚至?xí)楣ヂ浴⒔o朋友打電話、向客服求助。現(xiàn)在呢？注冊(cè)的時(shí)候多一個(gè)步驟，你就滾犢子吧。

這些也給產(chǎn)品經(jīng)理更高的要求：要懂各種知識(shí)，要理解各種用戶，要完成更難的工作。有個(gè)很簡(jiǎn)單的例子：很多老板覺得做產(chǎn)品經(jīng)理很簡(jiǎn)單，自己去兼任，結(jié)果出來(lái)的產(chǎn)品都是慘不忍睹。

3. 產(chǎn)品經(jīng)理將隨互聯(lián)網(wǎng)滲透進(jìn)各行各業(yè)?

我之前提過(guò)，互聯(lián)網(wǎng)在過(guò)去可以稱得上是特有的「行業(yè)」，就跟旅游業(yè)啊、出版業(yè)啊、房地產(chǎn)業(yè)啊一樣的概念。但未來(lái)互聯(lián)網(wǎng)肯定是會(huì)滲透進(jìn)各行各業(yè)的，未必是所謂「互聯(lián)網(wǎng) +」的形式，但未來(lái)人們看待互聯(lián)網(wǎng)，不會(huì)把它當(dāng)成是特殊的領(lǐng)域，而是會(huì)當(dāng)成是誰(shuí)都用得上的工具。?

現(xiàn)在的層面都還比較淺，但也有了雛形。只要是有點(diǎn)規(guī)模的公司、企業(yè)、單位，都在做自己的 APP，不管功能體驗(yàn)如何，這些 APP 都是產(chǎn)品經(jīng)理做出來(lái)的。未來(lái)它們會(huì)起到更多的作用，道理很簡(jiǎn)單：過(guò)去的很多信息方面的記錄、傳遞、處理，都是落后的。互聯(lián)網(wǎng)就是解決這個(gè)問(wèn)題的。?

比如我認(rèn)識(shí)一個(gè)傳統(tǒng)行業(yè)的朋友。他告訴我現(xiàn)在他們的記錄和通訊方式特別落后，每個(gè)人平時(shí)工作都要拿厚厚的本子，整理的時(shí)間花去工作時(shí)間的大半。在需要拿到一些領(lǐng)導(dǎo)簽字的時(shí)候也是無(wú)比麻煩，需要挨個(gè)去找，費(fèi)時(shí)費(fèi)力。這樣的流程，未來(lái)必然是會(huì)被手機(jī)工具取代（在線記錄、電子簽名）。?

類似的行業(yè)有很多。只不過(guò)沒有到時(shí)候。

就跟個(gè)人電腦普及之前，大家用的還都是手寫表格、手寫文檔，覺得電腦是個(gè)新奇玩意兒一樣。未來(lái)互聯(lián)網(wǎng)工具普及之后，任何人都會(huì)對(duì)在手機(jī)上完成生活工作的大部分任務(wù)習(xí)以為常的。?

而這些產(chǎn)品、工具，都是要有產(chǎn)品經(jīng)理去做的。

上面說(shuō)的三方面，其實(shí)就是在表達(dá)「移動(dòng)互聯(lián)網(wǎng)并沒有成熟」、「產(chǎn)品經(jīng)理并不只是做創(chuàng)新」和「產(chǎn)品顯然并沒有在同質(zhì)化」。?

綜上所述，我覺得職業(yè)產(chǎn)品經(jīng)理的時(shí)代剛剛到來(lái)。?

未來(lái)，產(chǎn)品經(jīng)理可能會(huì)細(xì)分到「技術(shù)型產(chǎn)品經(jīng)理」、「運(yùn)營(yíng)型產(chǎn)品經(jīng)理」、「體驗(yàn)型產(chǎn)品經(jīng)理」，或者按領(lǐng)域區(qū)分為「社交產(chǎn)品專家」、「后臺(tái)產(chǎn)品專家」、「電商產(chǎn)品專家」等等。

產(chǎn)品經(jīng)理也會(huì)有更成熟的培養(yǎng)體系和成長(zhǎng)體系出現(xiàn)，在高校里產(chǎn)品設(shè)計(jì)、項(xiàng)目管理這樣的課程會(huì)越來(lái)越多、更加專業(yè)。

整個(gè)行業(yè)，也會(huì)出現(xiàn)公認(rèn)的教學(xué)著作和指導(dǎo)思想，產(chǎn)品方面的知識(shí)不再是零散的、虛無(wú)的或者有些模棱兩可的（看看張小龍被解讀成了什么樣子吧...），而是邏輯自洽、經(jīng)過(guò)實(shí)踐檢驗(yàn)的、屢試不爽的。?

那時(shí)候，可能就不會(huì)有人對(duì)產(chǎn)品經(jīng)理有這么深的誤解了吧。至少不會(huì)覺得產(chǎn)品經(jīng)理就是每天在想 idea 的人吧？

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

這個(gè)世界問(wèn)題太多，我們需要一個(gè)能夠解決問(wèn)題的人。

如果你有足夠的能力解決來(lái)自PMCAFF用戶在你的專業(yè)領(lǐng)域中，以不同的角度提出各類刁鉆問(wèn)題，那么歡迎你參加PMCAFF問(wèn)答專場(chǎng)。

活動(dòng)申請(qǐng)可以添加工作人員微信溝通咨詢，加好友請(qǐng)備注：問(wèn)答專場(chǎng)。

與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。