從做電商轉到做工具，幾個月做下來，筆者發現產品屬性對于產品思維的要求是不一樣的，而從整個產品設計到上線的過程，筆者也有五大思考與大家一起分享。

過去四年的時間，我一直在做電商類產品。最近半年公司戰略調整，我被劃分到了新的業務線開始從0到1打造一批出海工具類產品，今年的目標是達到日活達到50萬，這個是立了軍令狀的。

從做電商轉到做工具，幾個月做下來，我認為兩種不同的產品屬性對于產品思維的要求也是不一樣的。

比如電商產品更加注重「數據思維」，產品的改動往往需要數據作為支撐，「漏洞模型」是重要的環節之一。而工具類產品在很多時候則需要反復思考其在體驗和設計上的「合理性」，尤其是出海產品在構建之初是「距離」用戶是很遠的，產品經理往往需要依靠自己的感性經驗和對使用場景的構想來進行設計。

再比如電商產品依靠出售商品本身已經有自己的商業模式了，而工具產品往往需要借用到「廣告」來實現營收。如何巧妙的加入廣告而不引起用戶反感，也是需要反復琢磨的。

考慮到Google Play特殊的生態環境，在打法上我們采用的是「產品矩陣」的策略，就是針對某一特定領域，會批量的上架不同定位的產品，然后配合上運營的ASO方案多點開花。

在產品功能上，我們的思考是采用「瑞士軍刀式」的功能設計，就是一個產品會內含多個核心功能，每個功能在體驗上都做到盡可能的做到極致。在宣傳方面可能只重點介紹其中一個功能，但是實際的體驗上讓每個細分功能都擁有較高的易用性。

幾個月下來，我們目前已經上線兩款產品并投入運營，而從整個產品設計到上線的過程，對我來說也是一次新的挑戰與嘗試，在這個過程中有以下幾點思考。

01 所有的流程都是為結果服務的

產品規模到了一定程度的時候，從設計、產品、開發到測試，需要建立相對完善的流程，確保每一次的產品的變動與調整都是在流程內進行運作，減少人為因素帶來問題的可能性。

但是這次做工具性產品，我們整個團隊都是新組建的，無論是團隊還是產品，都是一個從0到1的過程。這個階段我對于流程的看法一直是持「探索的態度」——到底什么樣的流程適合我們？我們需要制定哪些規范和原則？如何讓流程幫助、而不是阻礙到產品的打造？這些是我一直在思考問題的。

這個階段我很擔心的是團隊里的成員「拿一些固有的流程來解決當下的問題」。比如產品提測時候，我肯定會反復體驗和反饋，這個時候發現有些地方設計的不是很合理地方，我就會直接提出來要求開發進行改動。但測試人員在面對此類問題時會出來對我說：按流程來講，你這屬于需求變更了，我們需要走需求變更的流程。

而實際上也就是開發隨手就改掉的事情，如果一旦上升到需求變更的流程，整個過程就會變得很麻煩，尤其是在產品的初始打造階段。

所以我的總結就是：在工具性產品從0到1 的過程中，流程要盡可能的簡化與靈活。而且所有的流程都是為最終的結果服務的（好的產品）。如果流程反過來沒有幫助到最終的結果，反而因為流程的存在制約了很多問題的快速解決。那這種流程就是特別愚蠢的、不合理的流程，就應該被廢棄掉的。所謂黑貓白貓抓住老鼠的就是好貓，也是這個道理。我們看重的是最終的結果，而非過程。

初期打造產品的階段，流程沒必要絕對的完善，只要能夠輸出的高品質的產品，那么也就是合理的。反之，流程再怎么規范，輸出的結果卻很垃圾，那么這樣的流程也就毫無意義。

02「是否合理」是檢驗工具產品的主要標準

我們都知道「實踐是檢驗真理的唯一標準」，這句話套用到互聯網領域可以是「用戶是檢驗工具產品的唯一標準」，但是很多時候產品還沒上線該怎么辦呢？這個時候我認為就應該強調「是否合理」是檢驗工具產品的主要標準。

之前公司的測試人員對我說過一句話「產品文檔對我們而言就是圣旨，我們都是以你的需求為準的」。

這句話聽起來沒什么毛病，給予了產品文檔足夠的尊重，但是背后隱藏的含義卻很有意思：一切以產品文檔為準，言下之意就是產品文檔無論是對錯，我們都應該以此為準。

這其實是一種惰性思維，實際在新產品誕生的環境中，產品文檔怎么可能做到100%的準確無誤呢？怎么可能做到覆蓋100%的用戶場景呢？

這個中間會有一定概率出現紕漏和疏忽，尤其是我現在面臨的情況：同時推進多個產品、一個人面對十幾位開發人員。

所以無論是開發還是測試，在看待產品需求時都是帶著辯證的思維去看待，要評判產品文檔是否合理？產品文檔所覆蓋的情況是否存在漏洞？產品需求的出發點是否與實際的用戶使用場景相吻合？

如果開發和測試的過程中發現不合理或疏漏的地方要及時的指出來，而不是用「產品文檔對我們而言就是圣旨」這樣的話來掩蓋自己不愿意思考的行為。

我特別喜歡開發人員就產品上的問題來質問我，因為質問的動作本身就表明了開發人員其實是在思考產品上的問題，而非單純的產品讓開發做什么，他就做什么。

所以在整個團隊里千萬不能有「對產品經理負責」的想法，整個團隊都應該是抱著「對用戶負責」的想法來做產品的，每個人都要有產品意識、需要判斷產品的設計是否合理。

03「最小化可行性產品理論」的局限性

最小化可行性產品（簡稱MVP）的概念是Eric Ries 在《精益創業》里提出的。簡單地說，就是指開發團隊通過提供最小化可行產品獲取用戶反饋，并在這個最小化可行產品上持續快速迭代，直到產品到達一個相對穩定的階段。

這個概念做過產品的人應該都很熟悉了，在一定時期內也被奉為真理一般的存在。但是我最近反思下來發現MVP理論有其自身的局限性，它更適用于一些創業公司以及新興市場。

新興市場的需求往往是不明確的，這個時候需要快速的做出產品到市場上進行驗證，獲取用戶反饋后再進行迭代。比如微信早期的功能就極其簡陋，甚至IOS系統1.0版本也是極為簡單的。

但是現在的市場競爭環境已經發生了極大的變化，在大量的領域已經誕生了較為成熟的產品，MVP理論在這些成熟的市場環境里已經是完全不適用了。

比如AirPods切入的是無線耳機市場，但是在AirPods切入之前，該市場已經是紅海了，所以蘋果的做法就不再是用戶最小化產品去進行嘗試了。而是利用其強大的產品和供應鏈能力，一次性的把體驗做到極致，讓AirPods一上市就直接干翻所有競爭對手。

之所以談這個問題，是我們所做的產品也是從0到1 的，在整個過程中，團隊內部都有較強的MVP產品的思想。認為先做一個產品，推到市場上看看再說。

但是我在進行市場調研的過程中，發現我們所切入的市場已經有著相對成熟的競爭對手了，市場環境并不允許我們再做一個MVP去進行驗證，我們推出的產品必須是在綜合體驗上領先于競爭對手的。

而這個時候，就需要整個團隊產品觀念的轉變。

04 開發人員的產品意識是逼出來的

好的產品背后肯定是一個牛逼的團隊！這個道理是我在很早之前就意識到的，單靠某個人的產品意識和能力，都是難成大事的。

但是「產品意識」這個詞說起來簡單，做起來極難！尤其是提升整個開發團隊的產品意識上。

很多顯而易見的錯誤，一個缺乏產品意識的開發人員會完全發現不了，硬等著別人去提醒。還有就是凡是產品文檔中沒有覆蓋到的地方，一概不考慮、不做，也不愿意思考。

搞到最后就是，開發交付的東西存在各種奇奇怪怪的問題，不問則罷、問就是扯皮。每個開發都這樣搞下去，就會產生極大的內耗，最終結果就是做出一個垃圾產品。

我們團隊在組建初期，就面臨過這樣的問題——開發做東西應付測試，測試應付產品，產品怎么辦呢？難不成去應付用戶？

當時我一想，不對??！團隊里的開發都是工作至少3-5年的是中高級的開發人員，為什么湊在一起反而做不好一款產品呢？

但是我也發現其中有個別的開發人員產品意識很強，很喜歡去質問我產品上的問題，交付的質量也很高。后來我去請教對方，問他為什么會有這么強的產品意識。他的回答是：是被逼出來的，之前所在的團隊里只要做的東西有丁點問題，就會被一群人追著說，后來就逐漸把他逼的必須有產品意識了。

反應過來這個道理后，我就圍繞著「產品意識」這個事情反復的去給周圍人講，我講完還不行，讓開發主管也講、也運營也講……

通過這樣一個多維度轟炸的過程，開發人員的產品意識才可能真正的提升起來。

05 你是什么樣，你的團隊就是什么樣

在產品上我是一個很堅持的人，但是在和團隊相處的過程中，我是一個很不愿意讓別人尷尬的人。

平常在團隊里發現一些問題，我很少會公開的提出來，為啥呢？有些問題屬于開發團隊的，我去提出來不是讓開發主管難堪嗎？而有些問題又涉及到企業文化和公司的管理模式，我直言不諱，對我也沒什么好處。

但是我最近在琢磨兩件事：

• 我的核心目的是打造一批優質的出海工具產品，所以我不應當對團隊出現的問題坐視不管，畢竟團隊都出問題了，還怎么去打造好的產品呢；
• 我認為只要我的出發點是為了團隊和產品考慮，我就應當更直接的去指出團隊的問題，沒必要過于顧忌「面子問題」。

所以雖然我們公司的文化相對保守，但是現在我也放飛自我了，只要發現哪里有問題，我就直接提給相應的負責人，并且跟蹤問題的解決。

因為我的理念是：我需要打造優秀的產品，我就必須讓整個團隊都是優秀的。我是正派的人，我也影響到整個團隊去形成正派的風氣。

以上幾點就是近期在做工具性產品的思考。

#專欄作家#

旺仔九號，人人都是產品經理專欄作家。心理學碩士，服務電商類產品經理，微信號：Jackaniy（添加請說明來意）。

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

題圖來自 Unsplash ，基于 CC0 協議