產(chǎn)品需求是為了解決用戶在某個(gè)場(chǎng)景下的操作，需求發(fā)生的具象是故事，產(chǎn)品經(jīng)理需要學(xué)會(huì)將具象的故事抽象為產(chǎn)品需求。

產(chǎn)品經(jīng)理太不容易了，就想橋梁工程師一樣，除了把橋梁的設(shè)計(jì)搞定，還要監(jiān)督實(shí)施工作，跟進(jìn)具體的項(xiàng)目進(jìn)度，以確保把自己的思路能夠完整的執(zhí)行下來(lái)。

所有的產(chǎn)品設(shè)計(jì)想法都是用戶（這個(gè)用戶可能是你產(chǎn)品的用戶、產(chǎn)品經(jīng)理、項(xiàng)目組同事、老板以及競(jìng)品）的故事，把用戶故事簡(jiǎn)化為需求就是產(chǎn)品設(shè)計(jì)的過(guò)程。

而通過(guò)把需求實(shí)現(xiàn)的過(guò)程，產(chǎn)品經(jīng)理需要依托于迭代和開(kāi)發(fā)，不可能一口氣把產(chǎn)品能夠做到盡善盡美的。需求通過(guò)迭代釋放，迭代完成需求的積累和搭建。需求就像一口水井，版本就是盛水器，通過(guò)版本和迭代來(lái)控制盛水的容量，這就是產(chǎn)品開(kāi)發(fā)的節(jié)奏。

迭代視角的產(chǎn)品經(jīng)理必須在認(rèn)知和行為上都了解這個(gè)過(guò)程，這樣才能保證產(chǎn)品的質(zhì)量和速度兼顧。當(dāng)水井里面的水越來(lái)越少，盛水器所需要的線就越來(lái)越長(zhǎng)。同樣，對(duì)于產(chǎn)品經(jīng)理來(lái)說(shuō)，形成的壓力也會(huì)越來(lái)越大。

有時(shí)候產(chǎn)品經(jīng)理會(huì)尋求一個(gè)大的版本來(lái)釋放更多的需求，但是這時(shí)候產(chǎn)品經(jīng)理沒(méi)有能力去承接這個(gè)大版本規(guī)劃，導(dǎo)致出現(xiàn)該版本迭代的周期越來(lái)越長(zhǎng)，一旦加快速度，則質(zhì)量也會(huì)越來(lái)越差。漸漸地，感覺(jué)到產(chǎn)品力不從心，違背了自己的初衷和主觀意愿。（往往產(chǎn)品經(jīng)理在這個(gè)階段扛住了就成長(zhǎng)了，沒(méi)扛住就會(huì)否定了自己的能力。）

從某種意義上來(lái)看，產(chǎn)品經(jīng)理應(yīng)該在需求管理上做到嚴(yán)格的把控，當(dāng)需求池的內(nèi)容增多時(shí)，應(yīng)該對(duì)需求進(jìn)行優(yōu)先級(jí)排序，讓緊急重要的需求優(yōu)先開(kāi)始做，把其他的需求先放一放，因?yàn)樵谧霎a(chǎn)品的同時(shí)，我們應(yīng)該去習(xí)慣來(lái)自不同的需求，并且做好甄別的方式和方法。

產(chǎn)品經(jīng)理的職責(zé)并不是去消滅需求池，而是針對(duì)于需求做出符合用戶預(yù)期的產(chǎn)品。

其實(shí)產(chǎn)品經(jīng)理都應(yīng)該很清晰，我們?cè)谧霎a(chǎn)品的核心版本時(shí)，核心版本的成功率會(huì)隨著時(shí)間周期的延長(zhǎng)而下降，一般根據(jù)John的經(jīng)驗(yàn)，APP核心版本開(kāi)發(fā)上線最好不要超過(guò)兩個(gè)月，小程序產(chǎn)品的核心功能開(kāi)發(fā)上線不能超過(guò)1個(gè)月。

有些小伙伴在問(wèn)：為什么產(chǎn)品經(jīng)理要做好版本管理和項(xiàng)目管理？其實(shí)版本管理和項(xiàng)目管理是保證產(chǎn)品能夠成功交付，以及后面產(chǎn)品經(jīng)理做自我回溯的（方便存檔用）。

如果版本管理沒(méi)有控制好，導(dǎo)致核心版本的需求特別大，那么承載的周期就特別長(zhǎng)。所以筆者建議：先砍掉核心流程不相關(guān)的功能，把核心流程實(shí)現(xiàn)出來(lái)就可以了。那么針對(duì)于核心流程or第一版本開(kāi)發(fā)，產(chǎn)品經(jīng)理也可以用MVP（最小可行性產(chǎn)品）的模式來(lái)迭代開(kāi)發(fā)。

根據(jù)個(gè)人的經(jīng)驗(yàn)，除了核心流程的開(kāi)發(fā)，MVP的模式主要是在講述用戶故事上做簡(jiǎn)單化處理。給用戶講一個(gè)最能理解的故事，然后把這些故事的主要功能提煉出來(lái)進(jìn)行開(kāi)發(fā)，在開(kāi)發(fā)完后交給用戶使用。（先讓用戶跑起來(lái)）按照道理來(lái)說(shuō)，MVP的迭代應(yīng)該是最好的一種迭代方式。故事脈絡(luò)清晰，功能點(diǎn)燃燒層次分明，容錯(cuò)和糾錯(cuò)成本最低。

舉個(gè)例子：原來(lái)在做電商產(chǎn)品的時(shí)候，前期挑選符合種子用戶的商品，通過(guò)積累用戶的數(shù)據(jù)后，找到用戶的精準(zhǔn)畫像，針對(duì)商品的頻次和客單價(jià)維度，GMV達(dá)到了1000W后，然后上線了優(yōu)惠券系統(tǒng)和增加商品維度以及促銷體系，一步步迭代，節(jié)奏還是挺適中的。

但是我們?cè)谧霎a(chǎn)品的同時(shí)，我們需要去思考版本的核心點(diǎn)，這個(gè)核心點(diǎn)是需要去尋找產(chǎn)品的核心用戶和做產(chǎn)品的核心功能。這里筆者建議需要尋找的用戶夠精準(zhǔn)，方便MVP產(chǎn)品版本做減法，達(dá)到最優(yōu)化。

所以MVP是最小可行化產(chǎn)品：最小能保證速度，能夠在最小版本內(nèi)快速開(kāi)發(fā)迭代。可視化保證的是用戶能感知到，是做給用戶的產(chǎn)品，而不是非功能性產(chǎn)品。要讓用戶感受到產(chǎn)品的快速變化，小步快跑，快速迭代。

產(chǎn)品的節(jié)奏來(lái)說(shuō)，肯定是從不完美變得日臻完美的。也就是筆者經(jīng)常說(shuō)的，產(chǎn)品前期一定是可用的，然后變成易用，最后到好用，直至讓用戶瘋狂的。

但是針對(duì)于MVP化產(chǎn)品來(lái)說(shuō)：

• MVP產(chǎn)品就是小版本快速試錯(cuò)找方向，能夠直接感知產(chǎn)品能不能被用戶快速接受；
• MVP糾錯(cuò)成本低，每次獨(dú)立模塊的迭代，也能減少開(kāi)發(fā)成本；
• 產(chǎn)品規(guī)劃的問(wèn)題后面看，小范圍跑起來(lái)達(dá)到一定的效果后，再回頭看產(chǎn)品具體規(guī)劃的模塊和細(xì)節(jié)；
• 不要怕產(chǎn)品死亡，快速迭代化的死亡是能降低時(shí)間成本，半死不活最可怕。

互聯(lián)網(wǎng)產(chǎn)品公司與傳統(tǒng)軟件公司最大的區(qū)別就是產(chǎn)品小步快跑，快速迭代。

或許產(chǎn)品經(jīng)理做產(chǎn)品的過(guò)程就是不斷踩坑的，當(dāng)然，后面能填坑的產(chǎn)品經(jīng)理才是優(yōu)秀的。

作者：John，產(chǎn)品狗一枚，微信公眾號(hào)：產(chǎn)品狗聚集地。歡迎一起溝通交流。

本文由@John 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來(lái)自Unsplash, 基于CC0協(xié)議。