身在創業團隊中工作，討論與意見分歧是不可避免的，最近在進行復盤的時候，我發現討論通常會分為兩種：

• 一種是針對於模稜兩可的問題進行進一步的明晰與界定，這種討論往往是有積極意義的，會促使團隊成員深度思考；
• 另一種是討論往往是針對於產品細節可A或可B的意見分歧，這種討論會浪費大量的時間，並且在很多時候是無意義的。

進一步分析第二種討論，我發現原因是團隊內部對於一些基本的產品原則模糊不清，每個人都會有不同的產品理解與產品原則，這也就不可避免的在很多次要問題上進行了過多的無意義討論。為此，我專門總結了一下產品從設計到開發上線這個過程中的一些基本原則，然後把這些原則與公司各部門同事進行了溝通，以期就一些基本的產品原則達成共識，從而減少無意義的討論。

這些原則中，有些是已有廣泛應用的，有些是我自己的經驗總結，歡迎同行們補充糾錯，相互學習。

一. MVP產品原則

1. 該原則的含義

這個概念最早是由《精益創業》的作者Eric Ries提出來的，意思是指開發團隊通過提供最小化可行產品獲取使用者反饋，並在這個最小化可行產品上持續快速迭代，直到產品到達一個相對穩定的階段。MVP產品的重點並不是讓產品如何美觀、互動如何炫酷，而僅僅是為了驗證產品的功能是否被使用者所接受，人們的接受程度如何。

如果團隊成員對這個原則沒有清晰的認知，那麼產品經理就會接到大量關於優化與細節體驗上的需求，而且產品也會經常被內部成員吐槽。所以這個最基本的觀念需要在團隊內部達成充分的共識。

2. 該原則的意義

（1）MVP原則可以使創業團隊在擁有較少資源的情況下，對使用者的需求進行快速試錯；

（2）MVP產品可以使團隊大量減少因為開發錯誤功能而產生的成本與開支（時間成本、人員成本等）。

3. 注意的點：

（1）MVP產品是一個持續優化的過程，初期不要將眼光過多著眼於UI與體驗層面；

（2）MVP需要產品團隊將更多的精力花費使用者意見反饋蒐集及資料分析上，並以此為依據進行版本的持續更迭。

二. 需求凍結原則

1. 該原則的含義

這個原則是我自己總結的，是因為在創業團隊裡雖然也有開發節奏把控和版本控制，但是經常性的會被上級或者老闆以一些有理或者無理的需求所強行打亂，逼得我變更需求，而開發團隊又是敢怒不敢言。所以這個“需求凍結原則”就是針對於公司內部喜歡頻繁變更需求所制定的。

需求凍結是指在需求評審會議結束之後直到產品新版本上線之前，對需求進行暫時性的凍結，不在此期間內接受新的需求。新提出的需求都需要統一延期到後續版本中去。

2. 該原則的意義

（1）對開發進行保護，避免因產品經理或其他人頻繁變更需求而導致開發進度延期；

（2）提升團隊開發效率、對需求提出方進行約束、避免過多的需求擾亂開發節奏。

3. 注意的點：

需求凍結在實際中很難做到百分之百，你總會有那麼個別上級或老闆喜歡在上線前強行插需求，但凍結率至少應控制在90%以上，否則會擾亂開發節奏、而且讓開發感你的需求控制能力很差。

以下是提需求的過程中，可能需要注意的原則：

三. 資料導向原則

1. 該原則的含義

創業團隊內的每個成員都有提需求的權力，但是很多人會根據個人的主觀感覺提一些不重要或當前階段並不需要的需求。而每當這時，我都還需要花費一定的時間解釋這個需求為什麼不重要、為什麼不適合在當前版本做等等問題，時間長了還挺浪費我時間的。

所以我覺得團隊內部在提需求的時候，應當有一個數據導向的原則，提需求並不是憑空構想的過程，而是需要有具體的資料分析依據，根據資料分析出來的需求、才有可能是核心需求。在各種需求依據當中、總體的排序如下：

資料分析>使用者反饋>競品情況>先前經驗>個人構想

2. 該原則的意義

（1）這樣做的核心目的是為了降低開發錯誤需求的概率；

（2）讓全體成員都擁有資料意識，養成從資料角度看產品的習慣。

四. 需求統一管理原則

1. 該原則的含義

需求的管理其實並不是一件容易的事，因為需求的管理需要綜合考慮需求的來源、優先順序、影響的範圍、帶來的收益、可能帶來的風險以及產品當前所處於的階段等等方面。而很多人在提需求的時候（尤其是老闆），總是認為自己的需求就是最重要的，而要求產品經理將自己所提出的需求進行插隊。

需求統一管理原則其實就是讓各個部門以及老闆知道：既然你們現在有產品經理，那麼你們所有人提出的需求都應該讓產品經理進行統一管理，讓他去排序優先順序、決定做與不做，在這方面進行充分的授權。而非自以為是的要求產品經理按照你的要求一會做這個、一會做那個。

2. 該原則的意義

（1）給予產品人員更多的自主性與授權，提升產品人員對於產品的責任心與擔當；

（2）只有維護產品人員的相對獨立性，才有可能做出更好的產品。

3. 注意的點：

產品人員也同時需要承擔需求錯誤、延期等問題以及所帶來的責任。

以下是需求評審中的一些原則：

五. 可行性先行原則

1. 該原則的含義

需求評審過程中，如果技術人員針對於某個產品需求提出了更便捷的實現方式，原則上尊重技術人員的意見，按照可行性先行原則進行。

2. 該原則的意義

可行性先行原則有利於提升開發團隊的效率，並且提升技術團隊的參與感與責任感。這個原則也與MVP原則是內在統一的。

六. 責任人定奪原則

1. 該原則的含義

在產品設計與開發的過程中，經常會出現可A可B的時候，各方也經常會為了證明到底是A對還是B更正確進行非常多的討論。這個時候如果沒有具體的結論，應當遵循責任人定奪原則，比如宣傳頁面到底是藍色好、還是紅色好，這種問題發生爭論的時候，最終應當交由設計師進行定奪。

比如互動方式到底是A好還是B好的時候，最終應當交由互動設計師去定奪。再比如一個需求到底做或者不做，最終也應當是產品經理髮話。

2. 該原則的意義

（1）責任人定論的原則其實是對員工的一種授權與信任；

（2）責任人定奪的原則有利於讓專業的人在其專業的領域發揮更大作用。

3. 注意的點：

責任人定奪原則需要責任承認其定奪錯誤帶來的問題與責任，所以責任人定奪並非是亂授權、亂定奪。

以上就是我最近覆盤所總結出來的產品從設計到開發上線中的一些基本原則，歡迎同行進行修正或補充。