導讀產品需求是為了解決用戶在某個場景下的操作，需求發生的具象是故事，產品經理需要學會將具象的故事抽象為產品需求。產品經理太不容易了，就想橋梁工程師一樣，除了把橋....

產品需求是為了解決用戶在某個場景下的操作，需求發生的具象是故事，產品經理需要學會將具象的故事抽象為產品需求。

產品經理太不容易了，就想橋梁工程師一樣，除了把橋梁的設計搞定，還要監督實施工作，跟進具體的項目進度，以確保把自己的思路能夠完整的執行下來。

所有的產品設計想法都是用戶（這個用戶可能是你產品的用戶、產品經理、項目組同事、老板以及競品）的故事，把用戶故事簡化為需求就是產品設計的過程。

而通過把需求實現的過程，產品經理需要依托于迭代和開發，不可能一口氣把產品能夠做到盡善盡美的。需求通過迭代釋放，迭代完成需求的積累和搭建。需求就像一口水井，版本就是盛水器，通過版本和迭代來控制盛水的容量，這就是產品開發的節奏。

迭代視角的產品經理必須在認知和行為上都了解這個過程，這樣才能保證產品的質量和速度兼顧。當水井里面的水越來越少，盛水器所需要的線就越來越長。同樣，對于產品經理來說，形成的壓力也會越來越大。

有時候產品經理會尋求一個大的版本來釋放更多的需求，但是這時候產品經理沒有能力去承接這個大版本規劃，導致出現該版本迭代的周期越來越長，一旦加快速度，則質量也會越來越差。漸漸地，感覺到產品力不從心，違背了自己的初衷和主觀意愿。（往往產品經理在這個階段扛住了就成長了，沒扛住就會否定了自己的能力。）

從某種意義上來看，產品經理應該在需求管理上做到嚴格的把控，當需求池的內容增多時，應該對需求進行優先級排序，讓緊急重要的需求優先開始做，把其他的需求先放一放，因為在做產品的同時，我們應該去習慣來自不同的需求，并且做好甄別的方式和方法。

產品經理的職責并不是去消滅需求池，而是針對于需求做出符合用戶預期的產品。

其實產品經理都應該很清晰，我們在做產品的核心版本時，核心版本的成功率會隨著時間周期的延長而下降，一般根據John的經驗，APP核心版本開發上線最好不要超過兩個月，小程序產品的核心功能開發上線不能超過1個月。

有些小伙伴在問：為什么產品經理要做好版本管理和項目管理？其實版本管理和項目管理是保證產品能夠成功交付，以及后面產品經理做自我回溯的（方便存檔用）。

如果版本管理沒有控制好，導致核心版本的需求特別大，那么承載的周期就特別長。所以筆者建議：先砍掉核心流程不相關的功能，把核心流程實現出來就可以了。那么針對于核心流程or第一版本開發，產品經理也可以用MVP（最小可行性產品）的模式來迭代開發。

根據個人的經驗，除了核心流程的開發，MVP的模式主要是在講述用戶故事上做簡單化處理。給用戶講一個最能理解的故事，然后把這些故事的主要功能提煉出來進行開發，在開發完后交給用戶使用。（先讓用戶跑起來）按照道理來說，MVP的迭代應該是最好的一種迭代方式。故事脈絡清晰，功能點燃燒層次分明，容錯和糾錯成本最低。

舉個例子：原來在做電商產品的時候，前期挑選符合種子用戶的商品，通過積累用戶的數據后，找到用戶的精準畫像，針對商品的頻次和客單價維度，GMV達到了1000W后，然后上線了優惠券系統和增加商品維度以及促銷體系，一步步迭代，節奏還是挺適中的。

但是我們在做產品的同時，我們需要去思考版本的核心點，這個核心點是需要去尋找產品的核心用戶和做產品的核心功能。這里筆者建議需要尋找的用戶夠精準，方便MVP產品版本做減法，達到最優化。

所以MVP是最小可行化產品：最小能保證速度，能夠在最小版本內快速開發迭代?？梢暬ＷC的是用戶能感知到，是做給用戶的產品，而不是非功能性產品。要讓用戶感受到產品的快速變化，小步快跑，快速迭代。

產品的節奏來說，肯定是從不完美變得日臻完美的。也就是筆者經常說的，產品前期一定是可用的，然后變成易用，最后到好用，直至讓用戶瘋狂的。

但是針對于MVP化產品來說：

• MVP產品就是小版本快速試錯找方向，能夠直接感知產品能不能被用戶快速接受；
• MVP糾錯成本低，每次獨立模塊的迭代，也能減少開發成本；
• 產品規劃的問題后面看，小范圍跑起來達到一定的效果后，再回頭看產品具體規劃的模塊和細節；
• 不要怕產品死亡，快速迭代化的死亡是能降低時間成本，半死不活最可怕。

互聯網產品公司與傳統軟件公司最大的區別就是產品小步快跑，快速迭代。

或許產品經理做產品的過程就是不斷踩坑的，當然，后面能填坑的產品經理才是優秀的。

作者：John，產品狗一枚，產品狗聚集地。歡迎一起溝通交流。

本文由@John 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議。