新產品開發必須遵循的基本原則
優秀的團隊，是產品成功的重要因素。但決定產品能走多遠的是產品原則 。
<讓產品從0到1系列第 4 輯>
文 | 杜鬆
從0到1打造一個新產品的過程，團隊的重要性不言而喻，事實上對產品經理而言，ofollow,noindex">團隊，決定其高度 ，是一種產品能夠成功的重要因素，但團隊本身並不足以讓整個產品走的很遠。
回顧整個平臺型產品的全過程，高明的做法是能在專案開始之前明確一些基本性的原則，一來可以避免在專案過程中隨意發生不必要的爭執，更為重要的是產品原則決定了產品的未來。
產品原則，是產品發展的一個潛在標尺，指導著產品發展的方向，它代表著產品的定位與運營的邏輯， 它不僅僅是UI或者互動層面的細節問題，更涉及到整個產品從市場定位、產品架構到運營策略等一系列問題。
比如微信，到底要不要做“已讀”標記，這個看起來是一個功能，其背後的邏輯就是到底是發信者視角還是讀信者視角的問題。
產品原則，就像設定了一個評判尺度。有效的歸置了在面臨取捨時的判斷標準。
通常來說，產品原則可以從5個維度入手：
1、MVP原則
指的是通過提供最小化可行產品獲取使用者反饋，並在這個最小化可行產品上持續快速迭代，直到產品到達一個相對穩定的階段，MVP背後的核心原則就是減少時間成本。
這個原則，根本目的就是要對需求進行快速的試錯驗證，而不是糾結某個點的UI和視覺問題（在產品的某些階段，這些問題完全不值一提），其出發點就是避免團隊耗費不必要的成本開發錯誤的產品功能。
但MVP常常讓人誤入歧途，只關注了它的小，而忽略其是否真正符合市場需求。
“你應該從你的點子、價值定位起步，找到真正的方向（true north）。當然，你需要迭代、機型優化、在市場裡試驗，但你不能迷失方向、失去自己的視野、丟了自己的故事”。
也就是新產品的開發過程必須要經過三個過程的遞進：
1、使用者問題和解決方案的匹配
2、產品和市場的匹配
3、規模性擴充套件
對照起來看，我們能發現很多產品沒有走完前面兩個階段就開始規模性的擴充套件，常常是國內的還沒搞明白就開始國際化，金融行業還沒拿到手，就開始想著製造行業，產品還沒有釋出就想好了10個億的市場訂單。
然後，弄得雞飛狗跳，最終也達不成既定目標。
2、簡潔原則
“大道至簡”，是一種基於人文的哲學之美，喬布斯說“一旦做到了簡潔，你將無所不能。”
這種簡潔，不是簡單的減法，更不是直接減少功能，它是貫穿在產品、組織和企業戰略之中的體系化。具體表現在三個方面：
專注。
深刻的理解“好的產品不是解決所有問題的產品”，整個團隊能夠專注做某事，而不是什麼都在做，什麼都想做，什麼需求都敢接，什麼客戶都要拿下。
喬布斯果斷地砍掉了90%的業務線，只專注做幾款產品，結果這幾款產品非常成功。
簡單
通俗的說，就是把所有的內部邏輯複雜化，而把使用者的操作體驗做到極致的簡單化。
這是很難的一件事情，確實需要“死磕”才可能做到，這會帶來一個矛盾，過度的死磕細節會導致成本的上升，以及與市場的脫節，或者錯失機會。所以，簡單是原則首先是基於MVP之上的，一定要讓整個產品與市場相匹配，而不是盲目的簡單化。
不完美
新產品開發過程中，追求完美是大忌。它帶來的後果就是成本的疊加和機會的錯失。如果團隊有一種“必須要等到“產品”拿得出手了，才好意思展示在公眾面前” 的想法，這個產品可能永遠也無法達到“拿得出手”的地步。
比如，第一代iPhone連最基本的“複製貼上”功能都沒有，但絲毫沒有影響它的成功，在產品開發過程中，一定要搞清楚那些是必備的功能，它起到決定性的作用，有的可能則屬於錦上添花的功能，可以根據市場反饋來進行迭代，千萬切記，不要把自己的產品抱在辦公室，否則它會永遠都走不出去。
任何偉大的產品和事業都不是一上來就做的很好，而是通過不斷試錯，不斷修正，不斷迭代而逐步形成的。
所以，我們可以看到，“簡潔原則”既是組織戰略層的高度專注，也是產品維度的細節體驗，更進一步也需要整個團隊的溝通機制簡單化。
這種“簡單化”的溝通，取決於整個團隊在創立之初所形成的文化。這就是我在整個覆盤過程中，分開了兩個篇幅討論產品經理的角色與擔當，以及如何打造團隊能力的根本原因。
前文回顧：
3、資料導向
我們需要全員的資料意識，來降低錯誤的概率。
資料體現的過去，很多時候都會因為我們的過分解讀和理解不夠，而與事實發生偏移，我們需要資料，但不要去迷戀資料，有的時候不是資料越多越好，儘管通常情況下，資料的可靠性大於使用者的反饋，更大於我們的經驗和構想，但這不應該成為我們迷戀資料的藉口。
這一點很難達成共識，除非你有足夠的權威。
也許正是因為這些原因，現實中常常都是資料反而成為了產品開發中的坑。有些環節，資料被認為是某些機密，而被認為的隱藏或者修飾。
還有些情況是因為對資料的意識不足，所以被忽略，甚至是拿到了資料也不知道怎麼用，或者只關注表面，或者覺得離自己很遠。
最為可笑的是那種只知道拿自身感受來PK資料的做法，卻常常深度干預產品的發展路徑。
4、統一需求
這個原則簡單來說，就是統一需求出入口，不要讓需求滿天飛，它包括需求的優先順序處理和風險分析，也會帶來產品質量和團隊效率低下的問題。
這一點，同時也包括需求必須評審的基本要求，不要出現隨意修改，隨性發揮的情況，整個團隊要有全員的質量意識，既要有自主性，也要有責任心。
在實際操作過程中，“統一需求的原則”是解決產品變更的利器。
基本的思路就是在一定時間幾點上凍結需求，而不是沒完沒了的變更加塞需求，不要為了追求某些“成果”而強行改變計劃，打亂整個團隊的節奏，特別是從零開始的產品，這種變更往往得不償失，市場和使用者不見得會因為我們想象中的“功能”而忽然變成喜愛你的產品。
這個原則和MVP原則是一脈相承，目的是為了快速試錯，找準方向，而不是似是而非悶頭折騰。
5、風險意識
關於“風險”，我不知道應該用什麼詞彙更為貼近描述這個原則。很多人害怕風險，認為風險就是失去控制，這種思路的所有行為都是為了規避和控制風險。
還有一些情況則反過來，“風險”就是不確定性，也就意味著無限可能，凡是都是一種“到時再說”的心態——俗話叫“顧頭不顧腚”。
當組織中的某個產品需要橫跨多部門協作的時候，這種思維導致的後果會非常的嚴重，特別是硬體類等週期性長的產品，上游部門一旦只管自己這一節事情，就很容易給下游環節帶來很多額外工作和不可控因素，最終導致產品的失敗。
所以風險包括業務、技術、質量和團隊等多個環節的“不確定性”。甚至有些產品，還會涉及到一些人文的，社會的風險，都需要及時找到應對和解決的方案。
不同的產品，不同的團隊和管理風格，應對風險的方式都會各自有很大的差異，作為產品經理，首先要理解所在的組織風格，儘早識別風險，並提出預警，協助和推動風險應對方案的落實到位。
6、效率至上
當團隊規模達到一定程度以後，帶來的最顯著問題就是效率的低下。比如制定一些基本的會議規則，郵件的規範等都有助於提升團隊的效率。
舉個郵件管理的例子。
當你的專案週期超過3個月，具有統一識別的郵件標題規範都能提高效率。
———— / END / ————
【 前文回顧 】 <如何讓產品從0到1> 系列