開發工程師的產品素養

星爺的九品芝麻官里，有這樣一段很經典的台詞：「貪官奸，清官要更奸！要不然，怎麼斗得過貪官！」

以這段台詞開篇，絕沒有想要挑撥產品與開發內鬥的意思，只是想表明一個觀點：「優秀的工程師有時要比產品經理更了解產品的流程和細節！」開發工程師如果是兩耳不聞窗外事，一心埋頭寫功能，很難在互聯網公司有好的發展。只有既懂產品，又懂開發的人，才能更出色的完成自己的工作！接下來我們就聊聊工程師應該有的一些產品常識。

抄襲並不可恥，但姿勢要對！

我們工作中經常會遇到這樣的場景，產品經理給工程師描述一個有些複雜的需求，工程師還不是很理解，產品經理就掏出手機，打開一個第三方的應用說：「我要的功能就是這樣啦...」

這並沒有什麼問題，模仿成熟的功能並在此基礎上進行改進，是很好的起步方式。但是抄襲的時候要想明白，抄來這個功能是不是真正滿足了你們用戶的需求？這個功能為什麼做成現在這個樣子？如果只是單純的照搬別人的功能，不做任何思考，就不知道這麼做是為什麼，迭代的時候也就不知道該如何改進了。

我經常用上圖來回答一個常見的產品問題：「為什麼同樣的功能，在別的APP上反響很好，而我們做了就完全沒人用呢？」

這張圖想表達的是：企業家雜誌的封面人物，西裝都穿的筆挺筆挺的，非常有氣質，為什麼我們一穿西裝，哪怕是定做的，也無法達到這樣的效果？這都是背後這一排排的夾子的功勞呀！只看到別人表面上的光鮮，看不到別人背後付出的思考和努力，是永遠做不出同樣的效果的！

差的抄襲是不假思索的把產品經理自己喜歡的功能或者是公司希望用戶使用的功能，一股腦的塞給用戶。用戶不買帳還一臉委屈的說：「我把我能想到的都給你們了， 為什麼你們還不喜歡呢！」這樣的產品經理常常被自己的努力感動，卻很少打動用戶...

而好的抄襲應該是在深入分析自己產品解決的問題、使用的場景和用戶特點的基礎上，不斷關注有哪些新的功能可以更好的為用戶創造價值。當年微信在強關係高頻次即時通訊工具的基礎上，引入類Path的朋友圈玩法，既滿足了發布者表達（炫耀）的需求，又滿足了朋友之間相互了解近況（窺視）的需求，從而做到了野蠻生長， 成為了目前的流量巨獸，吞噬了手機超過一半的電量和流量！反觀Path，因為沒有足夠高頻的功能來支撐它培養用戶進行社交的習慣，最終慢慢被人遺忘...

很榮幸有機會和幾個騰訊的產品經理深入交流過他們「解構」一款競爭對手產品的過程。首先，他們會從「界面-交互-功能、用戶需求-使用場景-心裡訴求、核心策略-關鍵數據-迭代過程」等角度一層層對競品進行拆解分析，然後重新設計這款產品，再將重新設計的產品與競品進行對比，看看那些地方相同，那些地方不同，不同的地方是新方案更好還是原方案更優再擇優選取，最終才能做到青出於藍的效果，這才是正確的抄襲姿勢嘛！

曾經有個產品團隊「解構」我做過的一款應用，把我們所有的功能和頁面全部重新製作了成了一個帶完整交互原型文件，做的比我們自己的原型質量還高（我們是一步步做到最終的形態的，所以原型文件很零散），我直接就跪了...

好的產品迭代策略，應該是在保持系統可用的基礎上，持續改進和迭代

移動互聯網產品開發是一件風險非常高的事情，沒有一個人能夠僅僅憑藉自己的天賦就做出完全符合用戶需求的產品，只有通過將產品投放到市場上，從用戶的行為和反饋中收集信息，然後不斷的改進和迭代，才能以最小的成本找到正確的方向！一群人關在小黑屋裡閉門造車，上線之後就風靡世界的時代，早已經一去不復返了！

上圖中造汽車的例子，本質上要解決的問題是「幫助用戶通過更省力的方式達到目的地」。

第一種迭代策略是構想好最終目標，然後一個組件一個組件的疊加（造完輪子造底盤，造完地盤造頂棚，然後裝車門，但是發動機裝進去之前，永遠不能動...），直到汽車被造出來之前，沒人知道那東西有什麼用！也許等汽車造出來之後，會因為太過超前無法被大眾接受，而更加有可能的是，汽車還沒造出來，大家卻因為遲遲看不到希望，已經早早放棄了。

第二種迭代方式則不然，過程中的每一個版本都是可以解決用戶的問題，每一次迭代都是對前一代產品的升級（用滑板變滑動摩擦力為滾動摩擦力，加入方向控制系統的滑板車降低了學習門檻，增加輪胎直徑的自行車提高了速度，引入發動機的摩托車更加省力，將人包裹在內的汽車大幅提高了舒適度和安全性！），用戶的需求在一次次的迭代中被更好的滿足，團隊也能夠在用戶的使用行為和反饋中，不斷的獲得改進和迭代的靈感，從而更容易取得最後的成功。

第一次看到這張圖的時候，就深深的認同第二種迭代的策略！產品經理在做產品規劃的時候，往往需要進入一個理想的狀態，暫時忽略的所有的限制（技術、資金、用戶量、運營能力等），設想出產品達到最佳狀態的時候該是什麼樣子，這是一個很自然的過程，也是產品經理該具備的基本的能力。但是當真正落地執行的時候，一定要從理想狀態走出來，保證過程中的每一個版本都可用，每一次迭代都是從一種可用的形態進入另一種可用的形態，這才是最好的改進和迭代的方式。

忽略使用場景去解決用戶需求，大多是隔靴搔癢。

普通的產品經理通常是從需求出發，結合用戶的特點去設計功能滿足用戶的需求，而往往會忽略用戶使用功能的場景。這樣設計出來的功能往往是差強人意，很難給用戶驚喜！

微信搖一搖識別歌曲這個功能，剛開發出來的時候，我記得是以卡片的形式給出歌曲的名字和演唱者，點擊卡片進入歌曲的詳情頁並開始播放。這樣的功能設計確實解決了用戶想知道當前環境里聽到的歌曲是什麼的需求，但是，還能不能做的更好？

最近一次使用這個功能，當歌曲被成功識別後，直接進入了歌曲詳情頁，然後將歌詞快速滾動到環境中歌曲播放到的位置，再同步滾動！！！中文歌看著歌詞就能跟著唱兩句，英文歌還能看到英文歌詞對應的中文翻譯，方便的了解唱的到底是什麼！！！我瞬間就被這個功能擊穿了，太牛逼了，這才是優秀的產品經理嘛！

這就是充分的考慮了用戶在使用這個功能時候的場景（這首歌挺好聽的嘛，叫什麼？誰唱的？是快唱完了，還是剛開始？這首外文歌唱的是什麼？），才達到了給用戶驚喜，甚至擊穿用戶的效果！

沒有配套推廣和運營計劃的新需求，基本沒戲！

普通的產品經理最喜歡設計出一個功能，就催著開發加班加點的做出來上線，然後祈禱美好的事情自然而然的發生...美好的事情哪兒那麼容易發生呀！

產品、推廣、運營，三者的關係是相輔相成的，產品解決的問題越高頻剛需（操作系統、微信等），推廣和運營就越輕鬆；如果產品的研發門檻較低頻次又不是那麼高（打車、外賣等），那就需要在推廣和運營上發力來培養用戶習慣，建立門檻。

哪怕是做個以傳播為目的的功能，也要根據它的傳播能力計算出需要的啟動流量，杜蕾斯的營銷創意再好，沒有幾百萬的粉絲，也很難做到每條創意都在朋友圈大量傳播，更別說臉萌、足記、冰桶挑戰了，他們在啟動的時候一定都是配合非常全面的推廣和運營策略（從哪些人群啟動，需要多少啟動用戶量，配套哪些媒體的報道和推薦，出現快速擴散的趨勢之後，要不要在配套的刷個榜單等），才能做到刷爆朋友圈的！

要相信數據分析，但是不能迷信！

數據分析在產品改進和迭代的過程中是非常重要的，它能讓我們更好的看到產品各項功能的使用情況，更好的進行決策，而不是全靠拍腦袋來做決定。

但數據有時候並不是那麼的客觀準確的，記得在某本講產品的書上，看到了這樣一句話：「數據分析得到的結論就像穿著比基尼的美女，露出來的地方確實很性感，但是遮住的地方才是關鍵所在！」我非常認同這個觀點，數據分析只能體現出部分情況，想了解全部的情況，用戶調研是必不可少的。

我們基於微信服務號做的一款產品，從數據統計平台看到提交註冊信息頁面的流失率高達70%以上，當時看到這個數據的時候嚇壞了，認為是提交註冊信息頁面做得過於複雜，導致用戶不願意註冊從而造成了大量的流失。所以就開始大刀闊斧的刪減提交註冊信息頁面需要填寫的內容（去掉了名片上傳、延長了簡訊驗證碼的有效期等），從接近十個欄位刪減到只需要填寫四個欄位，然後繼續觀察統計平台註冊頁面的用戶流失數據，卻沒有任何好轉，這流失率每天得損失多少註冊用戶呀！直到後來我們邀請了幾個新用戶來測試產品，在旁邊觀察他們的操作，才發現真正出問題的原因是我們註冊完成頁面沒有和後續的功能打通，變成了一個孤立的頁面，而微信想關閉當前的頁面需要向前返回一次，才會出現關閉按鈕，這就導致一大批成功註冊的用戶，為了關閉當前頁面，只好返回到提交註冊信息頁面在關閉，從而被統計成了註冊提交頁面流失的用戶！雖然是虛驚一場，但是這個案例告訴我們，數據分析一定要結合產品場景和用戶行為，才能得到正確的結論。

產品應該是一切可以解決問題的方法，而不是一定要開發APP或者WEB

前段時間被黑的很慘的那句「我有一個絕妙的創意和一個靠譜的團隊，就差一個寫代碼的了！」，充分暴露了說這話的人完全就是個缺乏技術常識的外行，他缺的一定不是一個寫代碼的人，而是一整套技術體系！

同時這句話也暴露出了另外一個問題，就是很多的產品經理過分的依賴開發，認為只有通過開發APP或者WEB才能檢驗自己的想法是否可行，這也是不對的。

當有一個想法的時候，首先應該做的是尋找一切可以利用方案去測試自己想法的可行性。比如傳統企業想做電商，那就先去天貓開個店，看看自己線上的推廣運營能力能不能把銷售量做上來，而不是先開發個漏洞百出的電商網站，陷入各種技術的泥潭！等真的在天貓把銷量做起來了之後，再考慮為了減少被天貓分去的利潤，慢慢建設自己的電商網站，然後通過在非自有渠道的商品包裝中投放自有渠道的代金券來進行轉化，成功率要高的多。

我們之前幫一家酒店集團做官方APP的時候，做了一個入住用戶評論的功能，在收集了一些入住的評論之後，產品經理就來找我說能不能做個評論的智能語義分析系統，從用戶的評論中分析出哪些是正面的評價，哪些是負面的評價，哪些是針對基礎設施的評價，哪些是針對服務的評價等，再將這些分類後的評論信息推送給酒店的經營者。

需求確實是好需求，但是我反問了產品經理一個問題：「你們每天能收集到多少條評論？」

產品經理：「少的時候幾十條，多的時候一百多吧。」

我：「去招個實習生人工分類吧，又快又好，比我們短時間那開發出來的語義分析系統靠譜的多，而且還能出去吹這是通過生物智能識別技術實現的！等每天的評論數過千了，我們再來做語義分析系統吧，現在就開發不是在用大炮打蚊子嘛！」

在網上看到的一個例子，一家酒店前台向單個入住的客人推薦他們的超級大床房（2.4米寬的床），客人聽了之後都很有興趣願意嘗試一下，整體的入住反饋都很好。這家酒店是怎麼做到的呢？他們只是把沒賣出去的標準間里的兩張1.2米的床，拼成了一張2.4米的大床，然後換上2.4米的床上用品...太智慧了！如果這家酒店一定要走標準的流程，真的去採購2.4米的大床，最後如果客人的反饋良好還行，如果反饋不好，那這些2.4米的大床不全白買了嘛！

所以說，產品應該是一切可以解決問題的方法，先用現有的資源儘可能的去測試方法的可行性，而不是過早的投入昂貴的研發資源！研發資源應該是在方法確認有效之後，提供更好的體驗和更高的效率。

不知不覺又啰嗦了這麼多，這篇是之前《產品經理的技術素養》的後續，這樣我以後出去分享的時候，工程師為主就講《開發工程師的產品素養》，產品經理為主就講《產品經理的技術素養》，這樣我這個既不怎麼寫代碼，又不怎麼做原型的水貨，就很難被打臉了，哈哈哈！

作者：Leap

Ruby開發者，系統架構師，鷹漠旅行CTO，產品經理，連續創業者...

歡迎關注公眾號「譜曰」，第一時間收到我最新的分享。