大概三年前互聯(lián)網(wǎng)和移動互聯(lián)網(wǎng)都出現(xiàn)了很明顯的同質化趨勢，現(xiàn)在想來，也許“同質化”只是“標準化”出現(xiàn)的征兆。

“同質化”與“標準化”

移動互聯(lián)網(wǎng)發(fā)展至今，出現(xiàn)了許多優(yōu)秀的企業(yè)，越來越多的人，涌入到這個行業(yè)，相應的，在資本，人才涌入的背景下，APP也越來越多。

同質化的現(xiàn)象已經被人們選擇性的回避，不同軟件相同的功能與我們而言似乎不再那么新鮮，我們身處產品經理的角色，分析競品，分析優(yōu)秀產品的行為，加深了同質化的影響面積。

為什么分享都在右上角，為什么掃一掃都是一樣的，為什么登錄還是那個登錄？

在閱讀到本文之前，我們會將這一切的現(xiàn)象，定義為“同質化現(xiàn)象”，又或者是定義成“抄襲的結果”，然而，我卻想提出另一種可能性的構思。

我需要強調，目前階段，這個提議，任然只是概念階段，就如同新概念汽車一樣，我們看材料是非常的酷炫，但現(xiàn)在卻是無法投入到實際生產中，從概念到現(xiàn)實之間，還有一段不短的歷程，需要我們共同的努力。

同質化也許只是“標準化”出現(xiàn)前的一種征兆，如同黎明前的黑暗。

產品可標準化嗎？

產品可標準化嗎？

這是我思考許久的一個難題，不僅僅是對我而言，我相信對于我們大部分從業(yè)者來講，這都是一個極具“爭議性”的難題。

我能夠理解產品經理需要思考，需要創(chuàng)新，是個重思考的角色，但這不代表我們沒有動手技能。

一次偶然的機會，我將“想”與“做”分開了，過了一段時間，明顯的感受到我“做”的事情，其實完全可以標準化出來。

對于開發(fā)者來講，編程思維便是“想”，寫代碼的過程便是“做”，不論想的多么好，開發(fā)的代碼都需要遵從編程語言的“規(guī)則”，也需要遵循開發(fā)者的“規(guī)范”，還需要遵循團隊內部的“協(xié)議”。

規(guī)則也好，規(guī)范也好，協(xié)議也好，均是某種意義的標準化輸出。

這個發(fā)現(xiàn)讓我開始不再相信自己所從事的這個行業(yè)，也許產品經理這個行業(yè)正在向我們發(fā)起挑戰(zhàn)，也許他正在悄無聲息的孕育自己的規(guī)則，也許我們即將迎來的不僅僅是產品經理起點，也是產品經理的終點

這個時候，我只是模模糊糊的有所感覺，但卻不清晰，讓我更加清楚的看到這場變革的事情在于我所組織的幾次入門培訓。

產品經理可培訓嗎？

如果……我們將其標準化下來

為什么不能呢？

對于開發(fā)者而言，真正掌握編程思維的大牛很少，但能寫代碼，能實現(xiàn)功能的卻很多。

這是因為開發(fā)者有一份標準化的規(guī)范，標準化的規(guī)則，正是因為這樣的標準化，開發(fā)者有許多編程工具，并且這些工具都很強大，比如自動糾錯，自動引用。

作為產品經理的我們，深知一款工具，最大的依賴便是一些可標準化的規(guī)范，而不是為每一個人量身定做。

只有標準化，才能適應一個群體的共同訴求，也才能建立這個群體共同遵守的“規(guī)范”。

標準化產品

相對于“抄襲”而言，我們其實都是在遵循一些“標準”，很多的做法，我們甚至無法追溯到設計的源頭，只知道大家都在這樣做，于是我們就這樣做了。

在不經意間，其實我們已經開始嘗試標準化了，只是我們自己尚未意識到而已。

比如，我們需要引用第三方系統(tǒng)時，遵守他們的規(guī)則，其實這就已經是一種“標準化”的應用現(xiàn)象了

我們使用微信登錄，就必然要登錄微信的unionid（只有unionid能作為多終端使用的唯一身份標識），要獲取用戶的個人資料，就需要使用微信的openID（unionid不能獲得用戶資料，openid唯一但不固定，使用不同終端會生成不同的Openid）。

我們使用talkingdate來做數(shù)據(jù)統(tǒng)計，我們就需要遵守他的規(guī)范，羅列出要統(tǒng)計的頁面，要統(tǒng)計的點擊事件，并且遵守他的使用規(guī)則，我們需要為每一個埋點設定一個英文名，需要一個ID，需要一個對應的中文名。

除了在引用第三方系統(tǒng)時會有標準化的概念，其實我們在設計時也在潛意識的遵循一些“標準化”的規(guī)則。

• 為什么我們在設計底部菜單時，只允許最多5個按鈕呢？
• 為什么我們的“搜索”都會用新的一個頁面來做呢？
• 為什么對于內容列表，我們都會有加載更多和刷新的功能？
• 為什么點擊用戶的頭像，就會跳轉到對方的個人主頁？

其實這些都是我們現(xiàn)在，可“標準化”下來的做法。

我們將這些“標準化”的現(xiàn)象歸結于所謂的“用戶習慣”卻說不清楚他為什么是“用戶習慣”，我們很清楚這些是基礎的做法，但卻說不清楚，為什么要這樣做。與我而言，這一系列的現(xiàn)象，既不是“用戶習慣”也不是所謂的“基礎”，而是一種標準化的運用方式。

對于有編程背景的產品經理可能更容易理解，這就像代碼語言里的“語法”或者“封裝”，并沒有過于華麗的解釋，只是某種標準的應用，只是我們包裝了一層華麗的詞藻，結果弄得自己也說不清楚了。

對于標準化而言，是一種技能的沉淀，需要長時間經驗的積累，我們通過反復的做同一件事情，摸索到這件事情的規(guī)律，找到他的共性，就將他沉淀下來，在需要用時，便可以直接使用。

這就導致產品經理的培訓成為了一種可能，你并不需要花費與我相同的時間，只需要遵循我的“標準”，在解決相同問題時，由于我們遵循了相同的“標準”，我們的結果便是相同的。

對于研發(fā)而言，一年經驗和十年經驗的開發(fā)相比，如果遵循相同的“標準”解決相同的問題，結果也必然是相同的。可能這會讓大家有所爭議，是因為我們會習慣性的被時間所欺騙，比如一年經驗的開發(fā)不可能和十年經驗開發(fā)結果相同。

我能理解大家的想法，但還請注意我所提到的前提：遵循相同的“標準”解決相同的問題。

我們的差距很多時候體現(xiàn)在遵循的“標準”不同，一個功能的實現(xiàn)方法有許多，十年和一年相比，所使用的標準必然是不同的，這就會導致差異的產生。

這樣也許會讓大家更好的理解。

一年經驗的開發(fā)，和十年經驗的開發(fā)，使用相同語法，打印“helloword”結果相同。

在這個命題下，十年經驗是否和一年經驗沒有區(qū)別了？因為他遵循了一年經驗所遵循的“標準”

標準化的趨勢

我已經告訴大家一個成長的捷徑，如果你是剛入門的產品經理，遵循5年經驗的“標準”，在該標準所能解決的問題上，便不會與其有太大區(qū)別。

這可以是一種成長的捷徑，但更重要的卻是推進行業(yè)的進步，其實我們的社會，乃至人類史都是不停的演變，繼承，積累，“標準化”的一個過程。

我們不斷的將自己的經歷，演變成一些“標準”，而后被其他人繼承，后者則在我們的基礎上繼續(xù)經歷，積累更多的信息，然后演變成新的“標準”。

仔細想想，我們的生活中隨處可見關于“標準化”的現(xiàn)象。

我們都知道1+1=2，卻不再探索為什么1+1=2，這是一個標準，我們在這個標準上繼續(xù)積累，得到了2*2=4，形成了一個新的標準。

如果每一次的科學發(fā)展都需要將前人的“標準”都重新推演一次，我們的時代就會止步不前。

我們在做移動互聯(lián)網(wǎng)產品經理時，也遵循了相同的原則，比如我至今尚不明白“互聯(lián)網(wǎng)如何實現(xiàn)”的，未來我也不會去研究如何實現(xiàn)互聯(lián)網(wǎng)。

我們只需要在前人所演變出來的“標準”上，進行應用，進行積累，從而形成新的“標準”。

我相信，未來已來，在極小的面積里，已經有與我相同觀念的前輩在做這件事情，將自己的經歷演變成“標準”，并將這些標準傳遞給身邊的人，我也很期待產品標準化時代的來臨。

因為，標準化的意義遠超我們慣性思維的認知和預測。

產品標準化的意義

幫助新人快速成長，只是“標準”的諸多意義之一，現(xiàn)在，我們來探討一下，如果產品經理有標準，我們所處的這個行業(yè)，我們所想要將 事業(yè)，夢想，未來所寄托的行業(yè)會是什么樣的。

1.我們的工作效率會更快。

標準的應用會讓我們的工作效率更快，甚至出現(xiàn)數(shù)十倍的差距，這是因為標準的演變需要長時間的積累，而一旦形成標準，我們就會處于應用狀態(tài)，幾乎不需要思考，不需要反復，直接使用即可。

內容列表被廣泛的運用到許多產品里，如果我們把內容列表的需求演變成一種“標準”會出現(xiàn)什么結果呢？

在未來的工作中，如果遇到“列表”型的需求模塊，我們便可以直接將已經標準化的需求直接用于項目中。

這大概只需要幾分鐘的時間，而現(xiàn)在呢？每當我們遇到列表時，都需要重新設計，重新撰寫他的需求文檔，這個過程都會重做一次。

2.極大的提高我們的輸出質量

標準化的過程，需要我們解決許多問題，積累許多次的實驗，這就導致被標準化下來的方法論或者某種意義的技術，具備很高的穩(wěn)定性，輕易不會出現(xiàn)問題。遵循這樣的標準，必然會提高我們的輸出質量。

這就好比在開發(fā)過程中，我們使用了一套非常成熟的SDK，這套SDK足夠完善以至于我們在使用的過程中，不會出現(xiàn)Bug，我們想要的功能，也都被很好的兼容了。

反之，并不穩(wěn)定的標準，就類似于一套粗糙的SDK，不僅僅有許多的BUG，還會有代碼冗余，兼容成本高，增加我們的使用成本。

任然是內容列表，標準化以后，我們在任何一個項目里使用時，都會直接使用一套完整的基于列表的需求文檔，幾乎不會有遺漏和缺陷。

即便出現(xiàn)了缺陷，只需要在相應的標準之上建立新的標準，下次使用時，就不會再出現(xiàn)相同的錯誤。

3.催生專業(yè)的產品經理工具，減輕工作負擔

作為產品經理而言，我們能使用的專業(yè)工具有那些呢？思維導圖并不是我們的專業(yè)工具，其他角色也可以使用，word ，excel，ppt也是如此。

真正的產品經理工具大概只有axure這類的原型圖繪制工具了，相比開發(fā)行業(yè)的各種編碼工具，項目管理工具，實在過于缺乏了。

而一旦我們出現(xiàn)了標準，便會涌現(xiàn)出一系列以“更快，更方便，更強大”為命題的工具性產品為我們所服務。

工具方向的產品經理，應該非常了解這三個詞語，畢竟幾乎所有的工具，都離不開這三個詞。

比如我們來做一款能夠在畫原型圖的時候，自動生成需求文檔的工具可好？

這是個美麗的構思，不過在現(xiàn)在是不可能實現(xiàn)的，因為即便是需求文檔，我們目前的環(huán)境也尚未將其演變出“標準”

即便是產品經理最基礎的技能“需求文檔”也任然停留在“概念”階段！

難道，這樣不是很奇怪嗎？

4.催生“專業(yè)”產品經理

現(xiàn)在的產品時代，誰能說自己“專業(yè)”呢？缺少統(tǒng)一的“標準”，那么專業(yè)便也無從提起。

我們所謂的專業(yè)是指對某個行業(yè)的專業(yè)程度，同時也是對某種技能的掌握的熟練度，一旦產品經理涌現(xiàn)出大量的“標準”，我們就會催生出更多的“專業(yè)”產品經理。

我詳細不論大家是處在什么階段的產品經理，都會對下一個階段感到陌生，以至于我們很難觸碰“專業(yè)”，入門的產品經理面對各種花式技能，有用的，無用的，現(xiàn)在用的，將來用的，社交領域的，工具性質的，無從下手，3年產品經理面對產品使命，用戶痛點，市場面積，運營策略，迭代策略手忙腳亂；5年以上的產品經理又會受到商業(yè)模式，產品矩陣，市場戰(zhàn)略感到筋疲力盡。

誰也不敢說自己是專業(yè)的，因為不管是那一位產品經理，我們都只是部分技能專業(yè)，部分技能初級。

而正是這樣的一個行業(yè)，我們甚至連自己所具備的技能都無法清晰的描繪出來，并且相同的名詞在不同的產品經理身上所體現(xiàn)出來的意義，還既有可能是完全不一樣的。

缺少標準的現(xiàn)在，何以專業(yè)自居呢？不僅僅是自稱，甚至無法將“專業(yè)”作為自己的成長目標，因為實在太不清晰，太模糊了。

現(xiàn)在的我們，真的很難想象，“專業(yè)”的產品經理，到底是什么樣的可如果“標準”形成的未來，我們大概就都有了一個明確的成長方向，先學什么，在學什么，學會后如何使用。

我們將會在一條很明確的路上健步前行，沒掌握一個“標準”就能直接投入到實際使用中，每到了一個瓶頸，就去學習相應的“標準”，然后繼續(xù)前行，直到我們自己積累了足夠的材料，就會形成我們自己的“標準”。

每一位產品經理，都在摸索自己的方向，探索自己的方法，卻忘記了人類發(fā)展至今最大的工具，便是“知識的繼承”。如果沒有繼承前人的知識，我們現(xiàn)在任然在鉆木取火。產品經理的行業(yè)已經發(fā)展了十余年，許多技能已經具備“標準化”的雛形。

你是否做好迎接產品經理“標準化”時代的到來？

#專欄作家#

枯葉，近6年經驗的產品經理，人人都是產品經理專欄作家。擅長社交，社區(qū)，細分群體挖掘。微信公眾號：枯葉咖啡館。

本文原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。