互聯網產品從0到1的幾個小技巧小經驗
《有牛三人行》第二期節目有幸邀請到加我產品中心總經理灼老師、阿里產品運營文由和我們有牛ceo笑空來給大家分享和探討一下關於「互聯網產品如何從0到1」的話題
這些問題都是產品新人經常遇到的問題，只有深刻的理解這些過程才能幫助產品經理順利的把控整個產品的落地。文中還會有嘉賓多年實踐中的一些小技巧，大家要仔細看嘍!
如何論證自己的想法，產生靠譜的需求？大家知道一千個人眼中就有一千個哈姆雷特，同樣產品從0到1這個過程中，一千個人也會有一千種做法遇到一千種問題。儘管大家做法可能不一樣，遇到的問題也不一樣，但一個產品的需求就分兩種，那就是真需求和偽需求。當我們做一個產品時，最初要確定的肯定是這個需求是真需求還是偽需求，其次還要辨別這個需求是大眾需求，還是小眾需求或者是特別需求。那我們其實看的就是這個需求的規模有多大，這個東西做出來之後，能給用戶帶來什麼東西，解決什麼問題。所以我們定需求時，第一要確認是真需求，第二要確認是大眾需求。
產品從0到1，一定是從需求開始，從一個想法開始的。
假設我們有了一個想法以後，就要通過某方面的論證，證明這個需求在一定範圍內是可行的。那問題來了，我們是先快速把產品做出來，然後再驗證呢？還是拿著需求來不斷的驗證，驗證半年，甚至一年才去做這個產品。當然這兩種方法沒有對錯，那如果是互聯網產品的話，這裡建議用第一種方法，因為不管你前期準備的如何充分，到最後做出來之後，你會發現不一樣。所以我們要先快速的把產品做出來，再不停的迭代。那如果採用第二種會發生什麼情況呢，第一種情況是你論證完了，發現不可行，第二種情況是你論證完了，發現別人已經做出來了。
快速把產品做出來，再快速迭代這個方法是否適合大公司呢？
大公司就好像是航空母艦，它掉頭非常難，它有很多部門，有大量的地勤人員，空勤人員，所以它是牽一髮而動全身的。另外在一個大平台上，每天都有大量的流量，所以它很難做調整。一旦這個產品，今天確定了一個方向，它的原型出來了，它的商業模式也出來了，第一天的訪問量可能就是幾百上千萬，如果你第二天去做調整的話，用戶很可能會出錯，所以它前面這個論證的環節就需要非常非常的嚴謹。這是一個優勢，他的優勢在於他它的論證環節很嚴謹，雖然它的這個決策不一定是非常正確的，但是一般不會出錯。但是劣勢是什麼呢？就在於長時間的論證過程中，外面有一些抄襲的產品會快速的迭代，因為創業型的產品沒有流量，也沒有這麼大的用戶群，他只有在細分領域進行超越，才能取得一定的成功。所以對於一個航空母艦來講的話，這種小眾化的需求是沒有辦法快速迭代的，但是對於一個創業型團隊，它為什麼做的快呢？因為試錯的成本低，今天我們可能做的是一個社交軟體，做著做著發現社交不適合我，明天就變成了一個交易軟體，所以快速的迭代也是一個不斷的試錯過程。但是在試錯之前，這個思考的過程是一定要有的。
在大公司中，這些需求的來源是怎麼樣的呢？
在大公司做這個產品規劃和需求的時候，一般會把產品的需求分為兩大類：第一類是小需求，就是一些功能的迭代。這些小需求呢，其實是一些用戶或者運營的痛點。並且這些小需求，每天都會大量的生產，我們怎麼選擇呢？哪些更痛，哪些更直接，哪些轉化效率更高，我們就先做哪些。第二類，我們叫大需求，大需求其實就是一個項目，一個項目的誕生必然會使產品的商業模式產生變化，甚至會開拓一個新的領域。
那一般情況下，如果是後台方面的小需求，最重要的來源是運營，運營在使用這些產品的時候，會發現一些痛點，這些痛點可能會讓他們經常加班，這個時候呢，他們就會把這個痛點提上來。那如果是前端的小需求，會有非常多的收集渠道，比如說淘寶的論壇，淘寶的客服團隊；另外一個就是大家細心的話，會發現包括手機淘寶頁面也好，PC淘寶頁面也好，都會有一個提建議的反饋渠道，阿里自己叫輿情監控。那最有效的需求來源是什麼呢？是服務團隊，因為他們的描述是非常詳細，且具有場景化的。
如何進行需求評審？在阿里，不管做任何一個需求，都有一個把關型的會議，叫做需求評審。它的這個需求是來自各個部門，包括市場部，營銷部，運營部等，他們都有自己的績效考核，也就是KPI，然後他們會為了完成這個目標而去想一些需求，因為這個需求可以幫他們快速的達成目標。那這個需求放到產品的團隊里來，產品團隊要考慮的是：這個需求本身是不是真的存在，需求評審的時候，產品一般會問「你的這個需求是不是真需求，它解決了用戶的一個什麼問題」，提出的這個需求不是說為了讓運營人員達成某個目標而提出來的，而應該是真正能讓用戶在這個需求里提升效率，或者優化體驗的，這是需求評審的一個根本要素。
舉個實際例子，在阿里，運營提出來一個需求，他會把這個需求提給產品運營，那產品運營需要把它梳理成一個PRD文檔。在阿里，每個產品運營只對接一個業務，所以他會有一個需求池，分辨優先順序，那一般的需求，產品運營都會做一個簡單的判斷，如果產品運營覺得這個需求目前不符合整個產品的發展情況，那他們會把它slowdown了，就是放慢下來。如果產品運營覺得是優先順序比較高的的需求，那他們會簡單的畫一些原型圖，然後出一些文檔，然後產出PRD，之後就進入需求評審的階段。一般在評審的過程中有業務方，也就是提需求的人，產品運營，還有產品經理，因為在阿里，產品運營和產品經理乾的活很相近，相對來講可能產品經理對開發那邊可能更熟悉一點，產品經理會提出具體的解決方案，甚至一些研發的工作，可能他會說，根據你的這個文檔，我們會用哪些技術方案實現，或者這個功能我們可能暫時實現不了等等。整個需求評審實際上就是一個多方力量的角逐，每次都會吵得面紅而赤，因為大家都會有自己的考量，比如從研發的角度來講，他需要在最短的時間內產出最有效的產品。
那在阿里，一般評審，會先排優先順序，如果產品需求壓的不是很多的話，一周一次，如果壓的很多的話，一個月一次，排出優先順序後，馬上會進入PRD的評審，然後技術方案的評審，就是這樣反反覆復的過程。在這個過程中，一個產品從開始有需求到落地，短的話可能半個月，長的話，可能一個多月。因為在阿里涉及到跨部門，還可能涉及到跨公司，這裡有兩個影響因素，一個是溝通成本，另外一個就是系統兼容性的問題。這是一個完整的過程，但真正做的時候，有時候會有一個快速通道，比如用戶痛點優先解決；又比如當你的系統出現了不穩定，或者系統出現了一個BUG，或者產品出現了一個缺陷，需要馬上補上，這個時候，速度非常快，他可能今天出產品方案，研發連夜處理，第二天就測試上線了。當這個產品發生問題的時候，有可能用戶都感覺不到。
當然，我們在進行需求評審的時候，並不是人越多越好，可能很多產品都已經吃過這個苦了，這裡提供一個適合大部分公司用的需求評審建議。
第一步需求驗證。老闆也好，客戶來需求也好，從需求list里拿出來之後，產品經理應該先做一件事情，把它做成一個功能說明文檔，注意不是需求文檔，是功能說明文檔，這種文檔呢，是不拘於形式的，你就讓你的需求提出方能看懂就可以，然後再加上你的產品邏輯。這種文檔出來後，然後讓你的老闆，或者需求提供方進行小範圍的需求驗證。這是需求驗證的一次評審，如果這一步有問題，你回去再改，如果完整的需求文檔出來再改就麻煩了。一般這一步，一到兩次都是OK的。因為細節好沒有涉及，這一步就是我們小範圍的決策層，或者需求提供方進行驗證，
第二步出原型。先不要做需求文檔，因為需求文檔你會改很多次，並且需求文檔不是所有人都能看懂，比如，什麼用例，介面，出口等。所以你就做原型，所有人都能看懂，也就是可視化。原型做出來後，這一步的評審，跟誰評審呢？老闆就不用參加了，和需求提供方，市場人員，運營人員，因為他們會在他們的角度上來看待這件事情，並且市場和運營一定是比產品接觸用戶更多的。有一句話叫做，市場產品運營不分家，所以做產品的，雖然你是產品經理，但你一定要想你是市場產品運營的老大，一定要把自己處於這種地位。不然你做出來的東西，市場說，哦，我那裡要加個廣告位，然後運營來講，你這樣不好，那你就沒辦法，所以你要提前站在他們的角度來想問題。在這一步，你要確保這個產品做出來不是飄在空中的，是用戶所能接受的，而且對用戶來說是有幫助的，這樣的評審呢，也會經歷兩到三次，也是比較小範圍的。
第三步出產品需求文檔和UI設計。這一步說實話是沒有什麼可評審的，到PRD出來之後，直接發給研發就可以了。
如何寫能讓人看得懂的產品需求文檔？當評審通過以後，就要考驗我們的產品經理了，你的這個prd要寫的非常詳細，非常完善，那麼現在好多產品新人通常會犯幾個錯誤：
第一，不寫邊界。比如我註冊的時候，開發才不管呢，輸入一個字，我也讓你註冊。這個邊界同時也是讓之後測試人員寫測試用例時的一個非常標準化的界限。
第二，重文字。比如見附件原型，這是非常不可取的，因為沒有任何一個開發人員，會一邊拿著文檔，一邊對著文檔去看你的原型，然後再去開發，沒有人這麼去做。
第三，沒有頁面流，也沒有加上注釋。比如單擊，雙擊，長按等等。
那產品需求文檔到底怎麼寫比較好呢？包含以下幾點就可以了
功能列表
邏輯流程圖，不建議寫總的流程圖，分功能塊寫
功能介紹，功能解釋
這個功能裡面的邊界，最大處多少，最小處多少，異常情況下怎麼處理等
這個功能的頁面流圖
其實這個時候寫的字不是很多，但是按這麼去做，我們這個文檔該說的都說了，隨便拿一個模塊給一個研發人員看，他是能看的懂的。
其實怎麼做需求評審和怎麼寫prd對產品如何從0到1是有非常大的幫助的。
如何和別人溝通想法？這裡給產品人員推薦個做法。
當你有了一個想法之後，拋給大家，你不要想，讓大家想，讓大家提出自己的看法，你來判斷，讓大家來吵，你來聽，這個時候就有幾個好處：
1.這個想法經過多方碰撞後，會更靠譜一點
2.你獲得支持會更多
3.多次這麼做以後，你在你團隊的權威和影響力會提高，因為你是決策者，大家在幫你想
現在很多做產品的同學都會說，在公司里沒有地位，得不到支持，為什麼呢？就是因為我們在做事情的時候，經常拿個需求問別人說，這樣行不行，這樣可以吧，這就是你自己沒有把自己產品經理的位置擺正，產品經理做什麼的，是把控產品需求和把控產品方向的。不是說來問你行不行，行不行的，而是說，你們來給我說，我來決定行不行的。不要總是我以為，我覺得，這樣肯定是不行的。
如何說服別人？
當你是一個層級比較低，閱歷也比較淺的產品經理時，會受到很多人的挑戰，尤其是會受到開發的挑戰，為什麼呢？因為第一個，研發覺得你不懂技術；第二個，他覺得你提的這個需求，開發量非常大；第三個，他經常會給你一個折中的方案，說這個東西，現在實現三個月，我給你一個計劃，一個月就能搞定，但是這個這個功能點我們沒有，但你也勉強可以用。這就是一個妥協的過程，那麼我們在跟他們溝通的時候，有兩個辦法：
一你跟他說「這個需求是用戶說的，這點很管用」。
二你跟他說「請你看數據」。
這兩個點百試不厭，其實不管研究發跟你爭執什麼執著什麼，研發們也還是希望能最大程度的滿足用戶需求，也希望有更多的人能用自己開發的產品，因為研發也是有情懷的。
作為一個產品經理，溝通能力和為人處世能力很重要。
這裡再提供幾個說服人的技巧：
一灌輸。不斷的講不斷的講，當你說100遍腦白金好的時候，腦白金也就真的好了，但是這種方式效率非常低，並且在互聯網公司工作的人都是非常有個性的，所以這種方法經常會失效。
二就是向他描繪用戶的使用場景，讓他逐步的代入到你的思維圈套裡面。在這個思維圈套里，全是你想要表達的東西，他就能融會貫通理解了。然後他會覺得這個思想是他的思想，至於說這個思想到底是他還是你的其實並不重要，因為他已經認可了。再打個比方，今天我們想要喝咖啡，想要帶她去星巴克，但她想去costa，然後你告訴她說「不知道costa今天開不開門，好像星巴克來了個帥哥，還出了個新品種，聽說還不錯，那咱們今天喝什麼?」那她會說，那咱們今天喝星巴克，試一試！那這種方式就會比你跟她說「咱們今天去喝星巴克吧！」這種灌輸的方式更有效。
結語這些產品從0到1過程中的小技巧小經驗都是從資深產品人手中榨出來的，如果產品人員能反覆的實踐總結，對你們未來的產品之路，一定能省卻不少時間。
沒看夠？上有牛約見兩位行家，一對一私聊，點擊左下角「閱讀原文」，在有牛首頁搜索灼老師和王璨進行約見，城市記得選擇杭州哦。
推薦閱讀：
※民間風水經驗談
※【日本篇】賞櫻經驗談+圖賞
※練拳有三條主要經驗一要堅持二要鑽研三要虛心
※"玩"美手冊 超詳盡人像攝影流程全攻略08 - 攝影技巧、經驗分享區(攝影技巧|圖片處理) -...
※整裝出發！一篇過關經驗幫你開啟學霸模式~