前幾天有人問我：“你做產品有沒有什么方法論？” 當時我愣了幾秒鐘，意識到其實我是有方法論的，但是從沒有認真總結過，也就是說，對于怎樣做產品這件事，我并沒有形成一套適用于自己（也可能給他人有借鑒意義的）的思維方式。既然如此，那現在我應該總結一下echo的產品方法論。

方法論一：產品滿足的本質需求和商業目的起碼在當下，應該明晰。
首先，為何會有一個產品被創造出來？其背后必然是有一個或多個需求，凡是未看到需求而盲目生產出來的產品都是耍流氓。因此，做產品之前不做需求分析顯然是不可行的。然而，無論在任何以營利為目的的商業實體中做產品，該產品總應該實現該實體的商業目標，或是賺取利潤，或是提高流量，沒有任何商業目的的產品，也是無法獲得生存下去的理由的。

由于我所在的互聯網金融行業在過去的幾年里似乎比較熱門，常常會聽到有人說：“哎，我們家也想做個互聯網金融平臺，你看怎么做一下比較好？我們有這個資源那個資源。”那我就想問一句了：“做互聯網金融為了達到什么樣的商業目的呢？你想拉流量？放貸賺錢？賣理財產品賺錢？“通常問到這以后，對方就陷入沉吟，或者賴皮的說：”你幫我想一個吧！“

事實上作為產品經理，給企業規劃產品目標確為本職工作，但對于沒有具體需求卻已預先定好解決需求的工具的老板，我只能說一句：“臣妾做不到啊~”要么我需要知道有什么需求，要么我需要知道有什么商業目的，對于需求不明目的不明，卻規定好你必須用互聯網金融這個工具的商業機構，我想說的是，老喬下凡也幫不了你什么。（嘿嘿嘿，事實上這種公司還真不少！）

方法論二：產品的規劃應該由用例發起，用例驗證。
鑒定好了產品的需求或商業目的之后（起碼是當前已經確定），應該進入產品的業務架構階段。

現在到處在講究MVP，一夜之間產品做得挫都可以堂而皇之得稱之為為了敏捷開發，快速上線，好一塊遮羞布！我在產品業務架構這一步的主要執行方式是實用主義至上，先用例后功能。

技術出身的產品經理一定知道用例是什么，但其他背景的產品經理對于用例可能比較陌生，但可以這里把用例理解為“用戶故事”，即做這個業務的所有人，在這個業務中的行為是什么。每個用例都有一個明確的目的。例如投資者這個業務主角，他有一個關鍵用例稱為”投資“。“投資”用例中，可能包括投資者的實名認證和綁卡，而“綁卡”則一般不會稱為一個單獨的用例，因為，一般來說投資者不可能單純為了綁卡而綁卡，且沒有下一步目的的。我們的目標，是為了找出所有系統相關人員在這個產品的所有目的。這個“目的”，其實正對應著第一步的“需求”。

從零到一規劃一個產品的工作通常是這樣：你需要憑空想象出一件物體，并假設這個物體已經制造出來了。這時，你需要向他人描述這個物體，描述它是做什么用的，描述它的形狀，質地，硬度，大小，它是不是有什么氣味，搖晃一下聽會發出什么聲音，或者使使勁韌性如何。描述完畢后，會有人（開發兄弟們）把這件物體制造出來。也許你覺得在腦中已經想到了這件物體的每一個零件，在制造的過程中還是會有各種各樣的問題。按照我一個老朋友的話說：“尼瑪做實現的不是你啊！”如果用例不走通，功能當然也會設計的相當殘缺。如果不幸已經進入了研發流程，那么當程序猿拿著走不通的流程來問你的時候，如果你是男生恭喜你，你還能下跪求原諒；如果你是個妹子，你說你該怎樣吧。

說到這里有人會疑惑，既然產品的業務架構如此繁瑣，那MVP到底還存在嗎？我想說，一定還是存在的。一個產品的功能可以簡單，比如只有一個功能，滿足一類使用者的一類業務目的，但這個業務目的的滿足，一定是完善的。打個比方，如果你有兩枚一元硬幣，要你交出一半，你是給出一個硬幣，還是用刀把兩枚硬幣都切成半圓，然后給出兩個半圓？MVP需要你給出一個硬幣，而不是兩個半圓。即“可使用的最小產品”而不是'殘缺的大產品“。很多時候我們MVP給不出來的原因并不是我們規劃的太細了，而是，我們把產品規劃的太大了。

產品的業務架構做的差不多了，這時候各種文檔也應該出齊了。我并不覺得文檔出的越齊就代表產品做得越好或做的不齊就沒法開發。文檔齊不齊和研發測試團隊的默契程度、專業背景都有關聯。但是為保證產品能夠順利迭代，以及人員變動不會給產品帶來影響，最好保持較完善的需求文檔或主用例文檔。

有的團隊在產品規劃出來之后還面臨著拆分任務。即拆分功能點給不同的產品經理進行進一步完善的工作。在這點上我認為功能點任務的拆分，在產品這方面應依據技術任務的拆分來做。例如某個功能點，是研發小組A來實現，則應匹配產品經理A，功能點B由研發小組B來實現，則應對應產品經理B。這樣可以有效避免產品經理的跨研發小組溝通，以及技術部門之間需求協調不暢的問題。產品功能的協調問題，在產品組內解決，功能模塊間的通信與耦合，在技術組內解決，涇渭分明。

方法論三： 沒有一勞永逸的產品架構，早期產品可能隨時被推翻。因此應盡量簡單。

按照三段式理論，現在應該是方法論的最后一點，研發中的需求變更和產品迭代問題的處理方法。

在互聯網行業中我們都應該習慣了“只有變是永遠不變的”。初入行時，還常常為變來變去的需求和經常白做的功能感到惋惜，而現在已經能泰然面對了。

當我們在上述的第二步業務架構時，一般就應該對產品的生命周期及未來一兩個版本的迭代有基本的預估，這樣在第三步時，可以有效避免產品持續迭代中的荒腔走板。如果產品在老板（或“未知力量”）的影響下，發生了重大變更，那事實上可以認為是研發一個新產品，而不是在當前產品上的變更了。

鑒于此，MVP其實是非常重要的，這意味著我們必須有一個非常簡易且擴展性強的業務架構，而設計出這種架構的前提又是對業務的高度熟悉。因此，在互聯網行業，尤其是互聯網金融行業中，如果要適應快速的業務變動，對于產品經理的要求，應該是對業務理解到能抽象的程度，所以，我們時時刻刻都應該檢視自己，金融到底學的怎么樣？對金融的本質有多少的理解，而不僅僅拘泥在”這個按鈕應該放這還是放那？“這種UI層面的問題上。

產品經理是互聯網職業中入門門檻最低的一個職位，但是，在互聯網金融領域，它的入門門檻就不是那么低了。所以，當你做來做去還是覺得自己業務能力沒有什么提升的時候，我覺得問題主要出現在：你把自己的職能范圍縮得太小了。而為什么縮小，可能是你的潛意識把你的學習能力圈在舒適區了，你說呢？