如何論證自己的想法，產(chǎn)生靠譜的需求？

如何進行需求評審？

如何寫能讓人看得懂的產(chǎn)品需求文檔？

如何和別人溝通想法？

如何說服別人？

這些問題都是產(chǎn)品新人經(jīng)常遇到的問題，只有深刻的理解這些過程才能幫助產(chǎn)品經(jīng)理順利的把控整個產(chǎn)品的落地。文中還會有嘉賓多年實踐中的一些小技巧，大家要仔細看嘍!

如何論證自己的想法，產(chǎn)生靠譜的需求？

大家知道一千個人眼中就有一千個哈姆雷特，同樣產(chǎn)品從0到1這個過程中，一千個人也會有一千種做法遇到一千種問題。盡管大家做法可能不一樣，遇到的問題也不一樣，但一個產(chǎn)品的需求就分兩種，那就是真需求和偽需求。當我們做一個產(chǎn)品時，最初要確定的肯定是這個需求是真需求還是偽需求，其次還要辨別這個需求是大眾需求，還是小眾需求或者是特別需求。那我們其實看的就是這個需求的規(guī)模有多大，這個東西做出來之后，能給用戶帶來什么東西，解決什么問題。所以我們定需求時，第一要確認是真需求，第二要確認是大眾需求。

產(chǎn)品從0到1，一定是從需求開始，從一個想法開始的。假設(shè)我們有了一個想法以后，就要通過某方面的論證，證明這個需求在一定范圍內(nèi)是可行的。那問題來了，我們是先快速把產(chǎn)品做出來，然后再驗證呢？還是拿著需求來不斷的驗證，驗證半年，甚至一年才去做這個產(chǎn)品。當然這兩種方法沒有對錯，那如果是互聯(lián)網(wǎng)產(chǎn)品的話，這里建議用第一種方法，因為不管你前期準備的如何充分，到最后做出來之后，你會發(fā)現(xiàn)不一樣。所以我們要先快速的把產(chǎn)品做出來，再不停的迭代。那如果采用第二種會發(fā)生什么情況呢，第一種情況是你論證完了，發(fā)現(xiàn)不可行，第二種情況是你論證完了，發(fā)現(xiàn)別人已經(jīng)做出來了?？焖侔旬a(chǎn)品做出來，再快速迭代這個方法是否適合大公司呢？

大公司就好像是航空母艦，它掉頭非常難，它有很多部門，有大量的地勤人員，空勤人員，所以它是牽一發(fā)而動全身的。另外在一個大平臺上，每天都有大量的流量，所以它很難做調(diào)整。一旦這個產(chǎn)品，今天確定了一個方向，它的原型出來了，它的商業(yè)模式也出來了，第一天的訪問量可能就是幾百上千萬，如果你第二天去做調(diào)整的話，用戶很可能會出錯，所以它前面這個論證的環(huán)節(jié)就需要非常非常的嚴謹。這是一個優(yōu)勢，他的優(yōu)勢在于他它的論證環(huán)節(jié)很嚴謹，雖然它的這個決策不一定是非常正確的，但是一般不會出錯。但是劣勢是什么呢？就在于長時間的論證過程中，外面有一些抄襲的產(chǎn)品會快速的迭代，因為創(chuàng)業(yè)型的產(chǎn)品沒有流量，也沒有這么大的用戶群，他只有在細分領(lǐng)域進行超越，才能取得一定的成功。所以對于一個航空母艦來講的話，這種小眾化的需求是沒有辦法快速迭代的，但是對于一個創(chuàng)業(yè)型團隊，它為什么做的快呢？因為試錯的成本低，今天我們可能做的是一個社交軟件，做著做著發(fā)現(xiàn)社交不適合我，明天就變成了一個交易軟件，所以快速的迭代也是一個不斷的試錯過程。但是在試錯之前，這個思考的過程是一定要有的。

在大公司中，這些需求的來源是怎么樣的呢？

在大公司做這個產(chǎn)品規(guī)劃和需求的時候，一般會把產(chǎn)品的需求分為兩大類：第一類是小需求，就是一些功能的迭代。這些小需求呢，其實是一些用戶或者運營的痛點。并且這些小需求，每天都會大量的生產(chǎn)，我們怎么選擇呢？哪些更痛，哪些更直接，哪些轉(zhuǎn)化效率更高，我們就先做哪些。第二類，我們叫大需求，大需求其實就是一個項目，一個項目的誕生必然會使產(chǎn)品的商業(yè)模式產(chǎn)生變化，甚至會開拓一個新的領(lǐng)域。

那一般情況下，如果是后臺方面的小需求，最重要的來源是運營，運營在使用這些產(chǎn)品的時候，會發(fā)現(xiàn)一些痛點，這些痛點可能會讓他們經(jīng)常加班，這個時候呢，他們就會把這個痛點提上來。那如果是前端的小需求，會有非常多的收集渠道，比如說淘寶的論壇，淘寶的客服團隊；另外一個就是大家細心的話，會發(fā)現(xiàn)包括手機淘寶頁面也好，PC淘寶頁面也好，都會有一個提建議的反饋渠道，阿里自己叫輿情監(jiān)控。那最有效的需求來源是什么呢？是服務團隊，因為他們的描述是非常詳細，且具有場景化的。

如何進行需求評審？

在阿里，不管做任何一個需求，都有一個把關(guān)型的會議，叫做需求評審。它的這個需求是來自各個部門，包括市場部，營銷部，運營部等，他們都有自己的績效考核，也就是KPI，然后他們會為了完成這個目標而去想一些需求，因為這個需求可以幫他們快速的達成目標。那這個需求放到產(chǎn)品的團隊里來，產(chǎn)品團隊要考慮的是：這個需求本身是不是真的存在，需求評審的時候，產(chǎn)品一般會問“你的這個需求是不是真需求，它解決了用戶的一個什么問題”，提出的這個需求不是說為了讓運營人員達成某個目標而提出來的，而應該是真正能讓用戶在這個需求里提升效率，或者優(yōu)化體驗的，這是需求評審的一個根本要素。

舉個實際例子，在阿里，運營提出來一個需求，他會把這個需求提給產(chǎn)品運營，那產(chǎn)品運營需要把它梳理成一個PRD文檔。在阿里，每個產(chǎn)品運營只對接一個業(yè)務，所以他會有一個需求池，分辨優(yōu)先級，那一般的需求，產(chǎn)品運營都會做一個簡單的判斷，如果產(chǎn)品運營覺得這個需求目前不符合整個產(chǎn)品的發(fā)展情況，那他們會把它slow down了，就是放慢下來。如果產(chǎn)品運營覺得是優(yōu)先級比較高的的需求，那他們會簡單的畫一些原型圖，然后出一些文檔，然后產(chǎn)出PRD，之后就進入需求評審的階段。一般在評審的過程中有業(yè)務方，也就是提需求的人，產(chǎn)品運營，還有產(chǎn)品經(jīng)理，因為在阿里，產(chǎn)品運營和產(chǎn)品經(jīng)理干的活很相近，相對來講可能產(chǎn)品經(jīng)理對開發(fā)那邊可能更熟悉一點，產(chǎn)品經(jīng)理會提出具體的解決方案，甚至一些研發(fā)的工作，可能他會說，根據(jù)你的這個文檔，我們會用哪些技術(shù)方案實現(xiàn)，或者這個功能我們可能暫時實現(xiàn)不了等等。整個需求評審實際上就是一個多方力量的角逐，每次都會吵得面紅而赤，因為大家都會有自己的考量，比如從研發(fā)的角度來講，他需要在最短的時間內(nèi)產(chǎn)出最有效的產(chǎn)品。

那在阿里，一般評審，會先排優(yōu)先級，如果產(chǎn)品需求壓的不是很多的話，一周一次，如果壓的很多的話，一個月一次，排出優(yōu)先級后，馬上會進入PRD的評審，然后技術(shù)方案的評審，就是這樣反反復復的過程。在這個過程中，一個產(chǎn)品從開始有需求到落地，短的話可能半個月，長的話，可能一個多月。因為在阿里涉及到跨部門，還可能涉及到跨公司，這里有兩個影響因素，一個是溝通成本，另外一個就是系統(tǒng)兼容性的問題。這是一個完整的過程，但真正做的時候，有時候會有一個快速通道，比如用戶痛點優(yōu)先解決；又比如當你的系統(tǒng)出現(xiàn)了不穩(wěn)定，或者系統(tǒng)出現(xiàn)了一個BUG，或者產(chǎn)品出現(xiàn)了一個缺陷，需要馬上補上，這個時候，速度非?？?，他可能今天出產(chǎn)品方案，研發(fā)連夜處理，第二天就測試上線了。當這個產(chǎn)品發(fā)生問題的時候，有可能用戶都感覺不到。

當然，我們在進行需求評審的時候，并不是人越多越好，可能很多產(chǎn)品都已經(jīng)吃過這個苦了，這里提供一個適合大部分公司用的需求評審建議。 第一步需求驗證。老板也好，客戶來需求也好，從需求list里拿出來之后，產(chǎn)品經(jīng)理應該先做一件事情，把它做成一個功能說明文檔，注意不是需求文檔，是功能說明文檔，這種文檔呢，是不拘于形式的，你就讓你的需求提出方能看懂就可以，然后再加上你的產(chǎn)品邏輯。這種文檔出來后，然后讓你的老板，或者需求提供方進行小范圍的需求驗證。這是需求驗證的一次評審，如果這一步有問題，你回去再改，如果完整的需求文檔出來再改就麻煩了。一般這一步，一到兩次都是OK的。因為細節(jié)好沒有涉及，這一步就是我們小范圍的決策層，或者需求提供方進行驗證，第二步出原型。先不要做需求文檔，因為需求文檔你會改很多次，并且需求文檔不是所有人都能看懂，比如，什么用例，接口，出口等。所以你就做原型，所有人都能看懂，也就是可視化。原型做出來后，這一步的評審，跟誰評審呢？老板就不用參加了，和需求提供方，市場人員，運營人員，因為他們會在他們的角度上來看待這件事情，并且市場和運營一定是比產(chǎn)品接觸用戶更多的。有一句話叫做，市場產(chǎn)品運營不分家，所以做產(chǎn)品的，雖然你是產(chǎn)品經(jīng)理，但你一定要想你是市場產(chǎn)品運營的老大，一定要把自己處于這種地位。不然你做出來的東西，市場說，哦，我那里要加個廣告位，然后運營來講，你這樣不好，那你就沒辦法，所以你要提前站在他們的角度來想問題。在這一步，你要確保這個產(chǎn)品做出來不是飄在空中的，是用戶所能接受的，而且對用戶來說是有幫助的，這樣的評審呢，也會經(jīng)歷兩到三次，也是比較小范圍的。第三步出產(chǎn)品需求文檔和UI設(shè)計。這一步說實話是沒有什么可評審的，到PRD出來之后，直接發(fā)給研發(fā)就可以了。

如何寫能讓人看得懂的產(chǎn)品需求文檔？

當評審通過以后，就要考驗我們的產(chǎn)品經(jīng)理了，你的這個prd要寫的非常詳細，非常完善，那么現(xiàn)在好多產(chǎn)品新人通常會犯幾個錯誤：

第一， 不寫邊界。比如我注冊的時候，開發(fā)才不管呢，輸入一個字，我也讓你注冊。這個邊界同時也是讓之后測試人員寫測試用例時的一個非常標準化的界限。

第二， 重文字。比如見附件原型，這是非常不可取的，因為沒有任何一個開發(fā)人員，會一邊拿著文檔，一邊對著文檔去看你的原型，然后再去開發(fā)，沒有人這么去做。

第三，沒有頁面流，也沒有加上注釋。比如單擊，雙擊，長按等等。

那產(chǎn)品需求文檔到底怎么寫比較好呢？包含以下幾點就可以了

功能列表邏輯流程圖，不建議寫總的流程圖，分功能塊寫功能介紹，功能解釋

這個功能里面的邊界，最大處多少，最小處多少，異常情況下怎么處理等

這個功能的頁面流圖

實這個時候?qū)懙淖植皇呛芏?，但是按這么去做，我們這個文檔該說的都說了，隨便拿一個模塊給一個研發(fā)人員看，他是能看的懂的。

其實怎么做需求評審和怎么寫prd對產(chǎn)品如何從0到1是有非常大的幫助的。

如何和別人溝通想法？

這里給產(chǎn)品人員推薦個做法。

當你有了一個想法之后，拋給大家，你不要想，讓大家想，讓大家提出自己的看法，你來判斷，讓大家來吵，你來聽，這個時候就有幾個好處：

1.這個想法經(jīng)過多方碰撞后，會更靠譜一點

2.你獲得支持會更多

3.多次這么做以后，你在你團隊的權(quán)威和影響力會提高，因為你是決策者，大家在幫你想。

現(xiàn)在很多做產(chǎn)品的同學都會說，在公司里沒有地位，得不到支持，為什么呢？就是因為我們在做事情的時候，經(jīng)常拿個需求問別人說，這樣行不行，這樣可以吧，這就是你自己沒有把自己產(chǎn)品經(jīng)理的位置擺正，產(chǎn)品經(jīng)理做什么的，是把控產(chǎn)品需求和把控產(chǎn)品方向的。不是說來問你行不行，行不行的，而是說，你們來給我說，我來決定行不行的。不要總是我以為，我覺得，這樣肯定是不行的。

如何說服別人？

當你是一個層級比較低，閱歷也比較淺的產(chǎn)品經(jīng)理時，會受到很多人的挑戰(zhàn)，尤其是會受到開發(fā)的挑戰(zhàn)，為什么呢？因為第一個，研發(fā)覺得你不懂技術(shù)；第二個，他覺得你提的這個需求，開發(fā)量非常大；第三個，他經(jīng)常會給你一個折中的方案，說這個東西，現(xiàn)在實現(xiàn)三個月，我給你一個計劃，一個月就能搞定，但是這個這個功能點我們沒有，但你也勉強可以用。這就是一個妥協(xié)的過程，那么我們在跟他們溝通的時候，有兩個辦法：

一你跟他說“這個需求是用戶說的，這點很管用”。

二你跟他說“請你看數(shù)據(jù)”這兩個點百試不厭，其實不管研究發(fā)跟你爭執(zhí)什么執(zhí)著什么，研發(fā)們也還是希望能最大程度的滿足用戶需求，也希望有更多的人能用自己開發(fā)的產(chǎn)品，因為研發(fā)也是有情懷的。

作為一個產(chǎn)品經(jīng)理，溝通能力和為人處世能力很重要。

這里再提供幾個說服人的技巧：

一.灌輸。不斷的講不斷的講，當你說100遍腦白金好的時候，腦白金也就真的好了，但是這種方式效率非常低，并且在互聯(lián)網(wǎng)公司工作的人都是非常有個性的，所以這種方法經(jīng)常會失效。

二.就是向他描繪用戶的使用場景，讓他逐步的代入到你的思維圈套里面。在這個思維圈套里，全是你想要表達的東西，他就能融會貫通理解了。

然后他會覺得這個思想是他的思想，至于說這個思想到底是他還是你的其實并不重要，因為他已經(jīng)認可了。再打個比方，今天我們想要喝咖啡，想要帶她去星巴克，但她想去costa，然后你告訴她說“不知道costa今天開不開門，好像星巴克來了個帥哥，還出了個新品種，聽說還不錯，那咱們今天喝什么?”那她會說，那咱們今天喝星巴克，試一試！那這種方式就會比你跟她說“咱們今天去喝星巴克吧！”這種灌輸?shù)姆绞礁行А?/p>

結(jié)語

這些產(chǎn)品從0到1過程中的小技巧小經(jīng)驗都是從資深產(chǎn)品人手中榨出來的，如果產(chǎn)品人員能反復的實踐總結(jié)，對你們未來的產(chǎn)品之路，一定能省卻不少時間