從0到1和從1到100：產品經理的應對之道

一個產品從0做到1，和從1做到100，哪個更難？對待這兩個階段，產品經理如何應對。

一個產品從0做到1，和從1做到100，哪個更難？

Paypal創始人之一，Peter Thiel的《Zero To One》對從0到1的過程，包括如何找到需求，如何小範圍試錯，如何快速叠代等，已經進行了詳細的闡述。

的確，“創建新產品”對產品經理而言，更激動人心。從需求的挖掘，痛點的分析，想法的提出，產品的定位，產品的架構等，直至經過繁復的可行性討論，最終看到一個產品“長”出來， 這個從無到有的過程，需要產品經理有過硬的基本功和良好的sense，同時也要有強大的遊說能力，使團隊形成統一的合力。

而從1到100的過程，聽起來更像是“運營的職責”。很多產品經理會有這樣的想法：框架都搭建好了，產品也做出來了，種子用戶也有了，接下來不就是推廣了嗎？聽起來在這個過程中，產品經理貌似難以施展和發揮，更多是配合運營的工作，或者是做些“縫縫補補”的邊角工作。

然而，事實真的是這樣嗎？我曾經從0到1做過一個小產品，也曾經接手別人的產品，經歷過從1到100的過程，我的體會是： 從0到1的過程不見得很創新或者多獨特，但是從1到100著實更難做，更費心，對產品經理的要求反而更高。

從0到1：解決需求大於創新

談起從0到1，很多同行會認為這個過程強調“創新”，要有與眾不同的點子，甚至有不少誤解，認為有獨特的想法就可以贏得用戶和市場。然而，在公司裏，尤其是大公司，一個產品的出現，最根本的是要 解決在業務中遇到的實際問題 。以廣告平臺為例，最基本的功能是廣告主可以投放廣告，查看效果，隨著業務的發展，自然需要精細化的工具，這時候，優化工具出現了，各種“眼花繚亂”的報表系統出現了，等等。每個平臺所處的發展階段不同，比如百度鳳巢或者阿裏媽媽，產品體系已經很成熟，在這種情況下，想要從0到1做一個新產品難度就比較大，關鍵是業務並不需要。

比起創新更重要的是， 如何用產品去解決業務的難點痛點 ？你的用戶在哪個階段，需要什麽產品，產品經理必須基於業務考慮需求，而不能因為“別人有，我們也要有”，“我們可以提供不同的功能來吸引用戶”，這種判斷明顯偏離了業務本身。

第一，“別人有，我們也要有”，問題是：我們的用戶需要嗎？現階段我們的用戶最期待的功能是什麽？

第二，“提供不同的功能來吸引用戶”，事實上，在同質產品中，很少有用戶是因為某些炫酷的功能而選擇某個產品的。關鍵是：這個功能是要解決什麽問題。

從1到100：產品進化與叠代

一個產品從0到1建立起來之後，並不意味著這個產品的主要功能就完成了，事實上，產品的進化和叠代才剛剛開始，這個過程比0到1要漫長也難多了。

為什麽這麽說呢？

第一，你的用戶會變，而且要得更多。雖然在初期，一款產品的受眾就已經確定了，但是隨著產品的發展，用戶會越來越“刁鉆”，第一個版本只需要基本的功能就夠了，如果有流程的交互那是更好。第二版可能就需要高級的功能了，到了後續的版本中，由於用戶基礎變大了，產品經理會聽到各種各樣的用戶反饋， 如何取舍？

第二，產品支持的業務會變。之前我們談到，產品不能偏離業務。在一款產品的生命周期內，業務的變化是不可避免的，包括KPI的轉變，業務重點的遷移，還有業務的調整，都會影響產品的設計。比如，某電商APP，原來的KPI是拉新，今年變成了留存。訴求變了，產品也要調整。因為之前的框架和內容都是基於原有的策略的，這種情況下，受眾是一樣的，但是你要用戶關註的重點不一樣了，那麽，產品經理應該 如何應對策略和思路的變化 ，平穩過度呢？

第三，老板的思路也會變。不管在大公司還是小公司，結構是扁平還是官僚，在做產品的過程中，都要協調好老板與自身的思路，尤其是當兩者思路有沖突的時候。在這種情況下，產品經理又應該 如何協調不同的方案呢 ？

產品經理的應對之道

前面提出了三個問題，在從1到100的過程中，面對用戶反饋如何取舍？面對業務變化，如何過渡？面對思路沖突，如何協調？以我個人的經歷為基礎，我認為產品經理的應對之道有這些：

第一，對用戶反饋要去偽存真。

很多產品經理會有這樣的體會，用戶反饋是個坑。你不重視，會被認為“不註重用戶體驗”，你重視它，又覺得用戶的意見有點“無理取鬧”。

我的觀點是：不要過分強調用戶的反饋， 更重要的是，要學會去偽存真的方法：哪些是偽需求，哪些是真BUG。

那麽，如何去偽存真呢？

在實際操作中，先將用戶的反饋歸類，功能上的，交互上的，架構上的，等等，按照類別分開，不同的類別處理方法不同。比如，交互上的反饋，往往比較主觀， 最重要的是不要有跳轉死循環就好。 如果仍有問題，將反復出現的問題整理，與交互設計師溝通解決。如果是功能或者是架構上的問題，首先不要輕易懷疑自己對功能和架構的理解（尤其是前期經過各種論證的點），其次一定要用 數據驗證 。自己去後臺找相關功能的用戶數據，或者灰度的時候小流量實驗，要 量化分析 ！前提是，一定要記得正確埋點，不要有遺漏。

第二，對業務變化先拆解後合並。

不少人認為業務的變化特別抽象，尤其是戰略的目標，看起來今年和去年完全不一樣。我的觀點是： 對於一個持續發展的公司，戰略目標一般情況下是有延續的，有同類項的。 如果戰略變來變去，那一定是作死的節奏。

業務訴求的變化是一定的。通常情況下，我的應對策略是：先拆解後合並。

拆解，首先要熟知KPI是怎麽來的， 要把KPI拆成幾個關聯的指標 。比如，銷售額=UV*成交轉化率*客單價，如果要拉新，那就主要是針對UV（unique visitor，訪問人數）了。如果是存留，那要看成交轉化（用戶停留時間越長，理論上越容易產生購買行為），當然還要結合時間序列的分析。

合並，合並不同的KPI中的同類指標。還是以拉新和留存為例，如果重點從拉新轉向了留存，並不意味著原來的架構就完全不適用，比如，留存也需要有用戶基數，沒有拉新，留存也意義不大。按照這個思路，產品經理可以找到哪些為原來的目標設計的功能可用，哪些需要變化或者加強。

第三，對不同方案拉長時間線思考。

為什麽要 拉長時間線 思考？其實這算是一種緩兵之計，重點是要和你的上級包括團隊對長期目標達成一致。

實際經驗表明，這一招對於大多數短期的沖突來說尤其奏效。很多看起來不可調和的矛盾，放到長的時間裏面，其實只是不同的走向，爭論的原點在長期的目標上。很多情況下，產品經理會陷入要麽A要麽B的選擇題，但是如果能結合長期的產品規劃，也許會發現，其實當下最好的策略並不是A或者是B，而且這兩種方案還有調和的空間。

具體的例子我這裏不贅述了。如果下次遇到類似的沖突，我建議產品經理可以先試著和團隊或者領導分享你對產品的長期規劃，在整體目標一致的情況下，重新看待當下的方案。當然，在這個過程中，你也許會驚奇的發現，你和領導或者團隊對於長期的目標是不一樣的，這才是短期沖突不斷的根源。

最後總結下，在從1到100的過程中，一定要做長期的產品版本規劃，隨時關註用戶的反饋，並且根據業務自身來調整產品的設計。不僅如此，在這個過程中，產品也要合理解決與運營之間的分工問題，產品經理在從1到100的這一段同樣是主導，而且需要更靈活的適應變化。

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

題圖來自 Pexels，基於 CC0 協議

文章來源：