產(chǎn)品經(jīng)理必修課(8)：需求管理

了解訂單生命周期可以描繪出電商購(gòu)買(mǎi)流程，了解帖子生命周

期可以描繪出論壇的交流場(chǎng)景，同樣地，從需求的生命周期可以勾

勒出整個(gè)產(chǎn)品設(shè)計(jì)和實(shí)現(xiàn)的流程。

在相對(duì)成熟、處于發(fā)展階段的團(tuán)隊(duì)中，需求管理是產(chǎn)品經(jīng)理的

核心工作之一。就像長(zhǎng)途駕駛需要確保方向正確、目標(biāo)清晰，同時(shí)

也要確保駕駛平穩(wěn)、安全，不出差錯(cuò)。

在不同階段，產(chǎn)品經(jīng)理對(duì)需求的責(zé)任也不同。然而，需求應(yīng)該

始終掌握在產(chǎn)品經(jīng)理手中。產(chǎn)品經(jīng)理應(yīng)該了解每個(gè)需求，清楚明了,

這才能稱(chēng)得上是“管理者”。要管理整個(gè)產(chǎn)品，將其拆分為各個(gè)功能,

而這些功能都源自需求。嚴(yán)格來(lái)說(shuō)，需求在開(kāi)發(fā)階段就變成了功能,

但為了描述的一致性，我們將此時(shí)的“實(shí)現(xiàn)功能”也視為“實(shí)現(xiàn)需求”。

需求可以分為幾個(gè)階段，我們將逐一討論產(chǎn)品經(jīng)理在每個(gè)階段

應(yīng)該如何管理和處理需求。

、獲取需求階段

需求的來(lái)源多種多樣。業(yè)務(wù)越復(fù)雜，需求也越復(fù)雜。以電商平

臺(tái)為例，產(chǎn)品需求可以分為導(dǎo)購(gòu)、商品、營(yíng)銷(xiāo)、交易支付、售后、

個(gè)人中心等。

隨著職級(jí)的提升，身邊提出需求的可能性也越大。初入行的產(chǎn)

品專(zhuān)員或助理主要執(zhí)行被分配的任務(wù)；初級(jí)產(chǎn)品經(jīng)理的需求主要來(lái)

自用戶(hù)和上級(jí)；產(chǎn)品負(fù)責(zé)人還會(huì)收到老板和其他相關(guān)部門(mén)的需求；

而老板作為產(chǎn)品需求的提出者也是有可能的。

因此，在獲取需求的同時(shí)，必須進(jìn)行判斷并記錄下來(lái)。如果不

進(jìn)行判斷，等到處理時(shí)就無(wú)法整理出頭緒，可能會(huì)花費(fèi)大量時(shí)間在

處理需求清單上。記錄的目的是方便回溯，即使是最小的需求也要

記下來(lái)，不要指望自己能隨時(shí)記得每天聽(tīng)到的每個(gè)需求。

判斷需求的方法如下：

首先，判斷需求本身的重要性。

同樣是頁(yè)面上一個(gè)字寫(xiě)錯(cuò)了，將“登錄”寫(xiě)成“登陸”和將“獎(jiǎng)勵(lì)

15元”寫(xiě)成“獎(jiǎng)勵(lì)50元”，對(duì)不同問(wèn)題的嚴(yán)重性要有一個(gè)大致的預(yù)估。

其次，考慮需求的來(lái)源。

需求的來(lái)源會(huì)透露一些信息，需要慎重考慮。例如，老板提出

的需求可能是目前你無(wú)法理解的，但他認(rèn)為很重要，因此我們應(yīng)該

將這個(gè)需求視為一個(gè)重要任務(wù)。另外，用戶(hù)提出的需求，如果發(fā)現(xiàn)

他并非目標(biāo)用戶(hù)，那么可以暫時(shí)不考慮他的需求。

最后，了解需求背景。

在工作中，有三類(lèi)需求是絕對(duì)不應(yīng)該被記錄的。

首先是沒(méi)有解釋原因的需求，不應(yīng)該記錄。（“你做個(gè)XX出

來(lái)，別管那么多。

其次是沒(méi)有清晰邏輯的需求，不應(yīng)該記錄。（“啊，這里我也

沒(méi)搞懂，你先看看。”）

最后是非實(shí)際遇到的需求，不應(yīng)該記錄。（“哎，我覺(jué)得可能

有人會(huì)這樣用?！保?/p>

需求背景沒(méi)弄清楚，完全是浪費(fèi)時(shí)間。記錄需求的時(shí)候，耍確

保格式是“問(wèn)題+方案''的形式，例如“XX在用我們的XX功能時(shí)，

感覺(jué)XX,我們可以嘗試XX的方案”。如圖8-1所示為我們平時(shí)記

錄需求時(shí)的常用格式。

二、討論和設(shè)計(jì)階段

每隔一段時(shí)間應(yīng)該舉辦需求討論會(huì)，整理“需求池、也就是記

錄所有獲取到需求的表單。會(huì)上要詳細(xì)討論每個(gè)需求的情況，確認(rèn)

以下幾個(gè)事項(xiàng)。

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

對(duì)于需求的優(yōu)先級(jí)有兩種常見(jiàn)的排序方法。一種是基于四象限

法則，另一種則是基于KANO模型。

\四象限法則

一般需求的重要程度很難量化，尤其在來(lái)源復(fù)雜的情況下。營(yíng)

銷(xiāo)部門(mén)著急要我們配合做活動(dòng)，不做就少賺好多錢(qián)，業(yè)務(wù)部門(mén)著急

要我們配合做一套自動(dòng)化結(jié)賬工具，做了能節(jié)省很多成本……有時(shí)

抉擇會(huì)很痛苦，要權(quán)衡各種利弊，考慮最合理并且能說(shuō)服別人的理

由。

最常用的判斷方法是StephenCovey提出的緊急重要四象限法

則。如圖8-2所示。

我們要把緊急且重要的需求排在最前，不緊急但重要的需求其

次，緊急不重要的需求再次，最后是不緊急不重要的需求。

而在判斷是否重要時(shí)，可以參考這樣的排序（重要程度由強(qiáng)到

弱）：

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

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

?跟核心用戶(hù)利益有關(guān)

?跟大部分用戶(hù)權(quán)益有關(guān)

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

?跟用戶(hù)體驗(yàn)有關(guān)

判斷是否緊急，可以參考以下排序（緊急程度由強(qiáng)到弱）：

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

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

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

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

\KANO模型

另外一種很常用的方法是東京理工大學(xué)教授狩野紀(jì)昭(Noriaki

Kano)提出的KANO模型。我個(gè)人比較習(xí)慣用簡(jiǎn)化版的KANO模

型法，如圖8-3所示。

作為一個(gè)需求對(duì)應(yīng)的功能，“行''描述的是“如果有的話(huà)“，用戶(hù)

會(huì)“開(kāi)心”、“無(wú)所謂”還是，不開(kāi)心”；“列”描述的是“如果沒(méi)有的話(huà)”

的情況。具體分析如下。

矛盾：如果用戶(hù)覺(jué)得功能存在和不存在都很開(kāi)心，或者都不開(kāi)

心，顯然是有問(wèn)題的，這種矛盾的情況是存在邏輯問(wèn)題的，不予考

慮。

錯(cuò)誤：如果功能不存在讓用戶(hù)很開(kāi)心，或者功能存在讓用戶(hù)不

開(kāi)心，那么這個(gè)功能顯然是錯(cuò)誤的功能，不予考慮。

無(wú)關(guān)：如果功能存在和不存在，用戶(hù)都覺(jué)得無(wú)所謂，那功能也

就無(wú)關(guān)緊要了，同樣不予考慮。

最重要的就是以下三類(lèi)需求:

必要：如果功能存在，用戶(hù)并沒(méi)有特別的感覺(jué)，但功能不存在,

用戶(hù)會(huì)不開(kāi)心。這說(shuō)明這個(gè)功能是要滿(mǎn)足基本需求的，也就是大家

常說(shuō)的“痛點(diǎn)

期待：如果功能存在用戶(hù)很開(kāi)心，功能不存在用戶(hù)很不開(kāi)心，

這就是滿(mǎn)足用戶(hù)最直接、最明顯的需求了，因?yàn)樵谟脩?hù)內(nèi)心已經(jīng)有

所期待。

驚喜：如果功能不存在的時(shí)候用戶(hù)并沒(méi)有感覺(jué)，說(shuō)明對(duì)這個(gè)功

能，用戶(hù)之前沒(méi)有預(yù)期，但功能存在用戶(hù)很開(kāi)心，也就是說(shuō)達(dá)到了

驚喜的效果。這就是我們?cè)诘?章所說(shuō)的能夠超預(yù)期滿(mǎn)足用戶(hù)。

任何需求對(duì)應(yīng)的功能都可以分為“驚喜型”、“期待型”和“必要

型”?？紤]需求的價(jià)值，就要基于這三種類(lèi)型來(lái)做判斷。很多公司

和產(chǎn)品利用的產(chǎn)品運(yùn)營(yíng)手法就是在滿(mǎn)足后兩種類(lèi)型需求的同時(shí)，不

斷用第一種類(lèi)型需求激活用戶(hù)的熱情，促使用戶(hù)傳播。

基于四象限法則或者KANO模型，可以完成優(yōu)先級(jí)的標(biāo)注。

通常我們會(huì)用Pl、P2、P3、P4來(lái)標(biāo)注不同優(yōu)先級(jí)的需求，P1優(yōu)先

級(jí)最高，P4優(yōu)先級(jí)最低。

2.方案的草稿

需求有不同的解決辦法，耍討論清楚到底用哪種方法解決。比

如在討論020產(chǎn)品的需求時(shí)，我們發(fā)現(xiàn)有要解決刷單問(wèn)題的需求。

解決方案可以有兒種：事前提醒，告知用戶(hù)目前地理位置或訂單信

息有刷單嫌疑；事中限制，以必須到達(dá)指定地點(diǎn)、拍攝當(dāng)?shù)卣掌?/p>

操作來(lái)限制用戶(hù)；事后懲戒，提供給客服或者業(yè)務(wù)部門(mén)疑似刷單的

名單和證據(jù)，罰款或者封號(hào)。這幾項(xiàng)到底做哪個(gè)？還是做其中哪兒

個(gè)？?jī)?yōu)劣在哪里？需要好好討論。

討論出大概的方向，以及粗略的方案，再跟相關(guān)業(yè)務(wù)部門(mén)或者

需求方確認(rèn)。要確保大家共同認(rèn)可了某個(gè)方向后，再繼續(xù)推進(jìn)。

3.指定負(fù)責(zé)人

通常存在兩種產(chǎn)品經(jīng)理的需求分配制度。一種是每個(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í)，可以酌情調(diào)整一下，讓活少的同事予以

配合。但不管怎么樣一定要指定負(fù)責(zé)人，他需要對(duì)需求負(fù)責(zé)，一直

到產(chǎn)品上線(xiàn)后，出了問(wèn)題他也要承擔(dān)責(zé)任。要保證運(yùn)營(yíng)良好的工作

責(zé)任制，需求管理才能健康運(yùn)作。

4.劃定時(shí)間節(jié)點(diǎn)

許多產(chǎn)品經(jīng)理會(huì)疏漏這點(diǎn)，總覺(jué)得有了需求就盡快去做。但這

樣的結(jié)果往往是需求總也做不完。

時(shí)間節(jié)點(diǎn)主要是指方案完成的截止時(shí)間(Deadline)。就是當(dāng)

前需求能夠完整提交給開(kāi)發(fā)人員的時(shí)間。如果沒(méi)有這個(gè)時(shí)間，對(duì)需

求的管理就沒(méi)有意義了。另外，如果是要跟相關(guān)部門(mén)再確認(rèn)、需要

對(duì)用戶(hù)調(diào)研及要統(tǒng)計(jì)各種數(shù)據(jù)再作判斷，那么還要有調(diào)研或討論完

成的時(shí)間(Deadline)。

時(shí)間節(jié)點(diǎn)的劃定主要還是按照方案的復(fù)雜程度，依照經(jīng)驗(yàn)做粗

略判斷，在多次需求迭代后會(huì)越來(lái)越準(zhǔn)。建議最長(zhǎng)的時(shí)間周期不要

超過(guò)一周，保證需求的推動(dòng)進(jìn)度。對(duì)于有嚴(yán)格上線(xiàn)時(shí)間的需求（比

如很苛刻的老板需求、投資人需求、政策需求等），耍倒推出最合

理又富有余地的時(shí)間節(jié)點(diǎn)。

討論完剛剛?cè)氤氐囊慌枨?，要再整理和討論處于其他狀態(tài)的

（比如需要確認(rèn)方案的）需求。會(huì)議結(jié)束，每條需求都會(huì)得到更新。

這里還有個(gè)建議。我們?cè)谶@個(gè)時(shí)刻，一般會(huì)讓負(fù)責(zé)的產(chǎn)品經(jīng)理

及時(shí)更新需求狀態(tài)給需求來(lái)源方。當(dāng)然，需求方十有八九會(huì)對(duì)進(jìn)度

不滿(mǎn)意，這很正常，但除非需求方有確鑿的理由外，我們不會(huì)輕易

調(diào)整優(yōu)先級(jí)和時(shí)間節(jié)點(diǎn)。

三、待開(kāi)發(fā)階段

有了確切方案后，要盡快跟研發(fā)的同事做可行性評(píng)審，這一步

必不可少。如果缺少可行性評(píng)審，將會(huì)出現(xiàn)很多產(chǎn)品設(shè)計(jì)方案可行

性差、需求頻繁更改、產(chǎn)品功能不切實(shí)際的情況。

在可行性評(píng)審上完成的是對(duì)需求的大致評(píng)估，要做的有以下幾

件事情：

1.方案本身的可行性

在技術(shù)方案上是不是能夠完成？這是技術(shù)部門(mén)的同事要評(píng)估的

問(wèn)題。對(duì)于可行性評(píng)審里的方案未必是很精確的，所以要引導(dǎo)他們

提出對(duì)方案實(shí)現(xiàn)細(xì)節(jié)的問(wèn)題，一起弄清楚可行性。

2.有沒(méi)有更好的方案

要跟技術(shù)部門(mén)灌輸清晰的需求背景，讓他們也基于當(dāng)前的方案

去思考是否有更多可行的方案。方案未必能很快想得完整、周全，

但他們提供的思路一般是可行性較高的。

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

同樣，要配合技術(shù)部門(mén)的同事判斷會(huì)影響到哪些環(huán)節(jié)。尤其是

很多公司產(chǎn)品線(xiàn)比較多，有可能存在牽一發(fā)動(dòng)全身的情況，如果相

關(guān)的產(chǎn)品同事和技術(shù)同事不知情，必然會(huì)延期，然后會(huì)扯皮、造成

麻煩。再小的產(chǎn)品一般也會(huì)分前后端，所以要讓技術(shù)的同事來(lái)判斷

有哪些人需要知情和參與評(píng)估。

4,方案的成本如何

看方案需要多少人、多少資源、多少時(shí)間來(lái)完成，也要看方案

在技術(shù)層面耗費(fèi)的不太明顯的成本，比如服務(wù)器成本、帶寬成本給

用戶(hù)造成的流量成本等。

這些討論結(jié)束，會(huì)議就能夠輸出相對(duì)比較嚴(yán)謹(jǐn)?shù)目蓤?zhí)行方案

（或草稿）了。注意，如果會(huì)上遇到各種問(wèn)題需要改日再評(píng)，也要

確認(rèn)解決問(wèn)題的時(shí)間節(jié)點(diǎn)。

四、開(kāi)發(fā)階段

開(kāi)發(fā)需求的次序，未必完全按照需求池里的需求優(yōu)先級(jí)進(jìn)行。

前文提到，在可行性評(píng)審會(huì)上，我們會(huì)核算大致的需求成本。接下

來(lái)就是拿成本結(jié)合需求的優(yōu)先級(jí)得出該需求的性?xún)r(jià)比。

以在做上門(mén)美甲的產(chǎn)品為例，作為產(chǎn)品經(jīng)理可能同時(shí)要面對(duì)很

多需求，如下所述。

來(lái)自老板的：

?實(shí)時(shí)記錄美甲師的GPS（要解決刷單的問(wèn)題）

?首頁(yè)有點(diǎn)雜亂，不夠簡(jiǎn)潔（純粹視覺(jué)上的問(wèn)題）

來(lái)自運(yùn)營(yíng)的：

?要統(tǒng)計(jì)用戶(hù)對(duì)每個(gè)Banner的點(diǎn)擊率（看活動(dòng)結(jié)束后的效果）

?秒殺功能（下周就要做活動(dòng)，通知發(fā)出去了，必須做）

?需要提供給用戶(hù)在線(xiàn)改單的功能（比如換樣式，補(bǔ)差價(jià)）

?提供私人訂制的功能（包括用戶(hù)上傳圖片、美甲師提供參考

價(jià)、雙方確認(rèn)等步驟）

來(lái)自產(chǎn)品的:

?用戶(hù)下單時(shí)，支付失敗后需要重新下單，不能繼續(xù)支付，應(yīng)

做優(yōu)化

?下單步驟要跳轉(zhuǎn)太多頁(yè)面，應(yīng)該集中在一頁(yè)輸入信息

?根據(jù)關(guān)鍵詞篩選樣式的功能

這些需求結(jié)合我們?cè)谥霸u(píng)估的重要緊急程度，設(shè)定的優(yōu)先級(jí)

如下（Pl、P2、P3優(yōu)先級(jí)由高到低）：

?記錄GPS：P1（記錄GPS是為了防刷單，不然公司損失巨大）

?首頁(yè)簡(jiǎn)潔：P3（相對(duì)來(lái)說(shuō)并不重要）

?banner點(diǎn)擊率：P2（對(duì)運(yùn)營(yíng)安排活動(dòng)有重要作用）

?秒殺功能：P1（通知已經(jīng)給用戶(hù)了，必須做）

?在線(xiàn)改單：P2（現(xiàn)在是人工后臺(tái)改單，運(yùn)營(yíng)人員特別不方便,

消耗大量人力成本）

?私人訂制：P3（訂制用戶(hù)較少，不著急）

?可繼續(xù)支付：P1（體驗(yàn)差，無(wú)法忍受）

?簡(jiǎn)化下單步驟：P2（大大提升體驗(yàn)，但目前可以接受）

?篩選：P3（目前的分類(lèi)功能比較完善，篩選是補(bǔ)充）

總結(jié)完需求，按照優(yōu)先級(jí)分類(lèi)，如圖8-4所示。

再根據(jù)之前在可行性評(píng)審會(huì)后跟開(kāi)發(fā)的同事們討論出的實(shí)現(xiàn)成

本，我們也有個(gè)大致的排序（DI、D2、D3按照實(shí)現(xiàn)成本由低到高

排序）：

?記錄GPS：D1（定時(shí)記錄GPS,并不復(fù)雜）

?首頁(yè)簡(jiǎn)潔：D3（排班布局會(huì)耗費(fèi)大量時(shí)間）

?banner點(diǎn)擊率：D1（注入log,很簡(jiǎn)單）

■秒殺功能：D1/D3（可以分簡(jiǎn)單和復(fù)雜兩個(gè)版本上線(xiàn)，難度

不同）

?在線(xiàn)改單：D2（功能交互比較復(fù)雜）

■私人訂制：D3（同樣是功能交互復(fù)雜）

?可繼續(xù)支付：D1（頁(yè)面改動(dòng)少，主要是調(diào)試接口）

?簡(jiǎn)化下單步驟：D2（還是功能交互比較復(fù)雜）

?篩選：D3（后臺(tái)邏輯需要做大的改動(dòng)，數(shù)據(jù)處理也很麻煩）

整理后，按照需求成本分類(lèi)，如圖8-5所示。

然后，可以把P序列和D序列做成矩陣圖，如圖8-6所示。

而有了矩陣圖我們就可以從性?xún)r(jià)比由高到低的順序，依次完成

需求了。如圖8-7所示，可以參考按照從1到9的順序。

按照工作量確認(rèn)了本次迭代的需求，提交開(kāi)發(fā)之后，要關(guān)閉本

次迭代的需求。也就是說(shuō)，原則上本次迭代不再加入新的需求。

在開(kāi)發(fā)中，“扯皮”的問(wèn)題歸納起來(lái)有三種：需求太多，沒(méi)按時(shí)

做完；需求有改動(dòng)，導(dǎo)致了額外工作量，引起開(kāi)發(fā)人員的不滿(mǎn)；有

新的緊急需求，導(dǎo)致發(fā)布延期。

導(dǎo)致出現(xiàn)這三種問(wèn)題的原因如下。

1.產(chǎn)品方案不完整

方案不完整往往是沒(méi)有考慮全面。這個(gè)跟需求管理本身沒(méi)關(guān)系,

就是在出方案的過(guò)程中看能不能把事情想全。

經(jīng)常出現(xiàn)這樣的情況，在實(shí)際開(kāi)發(fā)的時(shí)候技術(shù)人員才發(fā)現(xiàn)某個(gè)

邏輯沒(méi)想通。再喊產(chǎn)品經(jīng)理來(lái)一起討論的時(shí)候，大家才發(fā)現(xiàn)需要加

一些功能才能完善邏輯。最終結(jié)果就是周六加了個(gè)班，大家都很不

開(kāi)心。

這種事情也不好追責(zé)，畢竟參與者眾多，流程拖得很長(zhǎng)。

對(duì)于這種情況，各個(gè)流程中的環(huán)節(jié)都要做一些調(diào)整，才能確保

最終產(chǎn)品方案的完整。

分析需求時(shí)，先梳理邏輯再出方案。能畫(huà)流程圖的畫(huà)流程圖，

能畫(huà)邏輯圖的畫(huà)邏輯圖，能畫(huà)腦圖的畫(huà)腦圖，窮舉整體的邏輯。

討論方案時(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é)任；如果問(wèn)題出在產(chǎn)品經(jīng)理并不熟悉的技術(shù)邏輯,

那就是在可行性評(píng)審中技術(shù)同事的責(zé)任。

2.需求方的主觀(guān)改動(dòng)

這種情況基本上是需求方或者產(chǎn)品經(jīng)理的問(wèn)題，他們?cè)谔峤环?/p>

案前沒(méi)有完全想清楚。有時(shí)候都開(kāi)始開(kāi)發(fā)了，業(yè)務(wù)部門(mén)來(lái)人說(shuō)：

“我們發(fā)現(xiàn)這個(gè)問(wèn)題好像不存在了，大家不要做了”。他們覺(jué)得無(wú)所

謂，還減輕了開(kāi)發(fā)人員的負(fù)擔(dān)。但對(duì)技術(shù)部門(mén)的同事來(lái)說(shuō)就好像是

被耍了一樣，過(guò)去的工作一下沒(méi)有意義了，造成的影響是惡劣的。

產(chǎn)品經(jīng)理在對(duì)接業(yè)務(wù)方或者其他同事的需求時(shí)要做判斷，他們

是不是完全想清楚了：是靈機(jī)一動(dòng)的小點(diǎn)子，還是不得不解決的問(wèn)

題。

有一種情況是需求方跟產(chǎn)品經(jīng)理