非廢話前言

上一篇我們聊到產品經理需要做需求與問題定位，而且這通常是關乎產品最終生死的關鍵步驟，如果還沒有看的話請務必進行簡單了解，戳這里閱讀 - 產品經理與產品設計 - 需求與問題定位。

這篇是本篇《產品經理與產品設計》專題的第二篇。整個文章框架大概是下面這張圖的邏輯，有一定經驗的產品經理可以直接參考腦圖版本

如何使用合適的技術與平臺

本篇我們要說的是：產品經理如何選擇合適的技術與平臺去解決問題。首先我要說的是“You should not focus on this（你不應該專注于這個問題的解決上）”。但是解決這個問題仍然可以幫助產品經理作出一款令人尖叫的好產品。因為好的產品離不開合適的技術和平臺（這里的平臺是指選用什么樣的前端與用戶交互，使用什么樣的后端支持數據的運算）

正文

使用合適的技術與平臺

• 輸入：需求與問題
• 輸出：選用的平臺（包括前端，后端，系統關聯關系和數據模型）

輸入

你需要首先非常清晰的了解這個產品（或產品群）要解決的需求和問題是什么。圍繞問題的用戶，場景和問題，我們進行思考。

如何選用平臺

選擇合適的前端

請按照如下順序一次回答這些問題，它們會幫助你最終引導你應該選擇什么樣的前端與用戶交戶。

在回答問題之前，我們首先要認識到，我們需要一個盡量快捷輕便的端口去解決用戶的問題，并且與用戶互換必要的信息，進行必要的交互。

邏輯上某些公司會傾向于選擇APP作為與用戶溝通的首選，因為APP的用戶留存率會最高，粘性最強，便于挖掘用戶價值。There we go！我們又發現了一個典型的以自我為中心而拋棄用戶利益的產品設計。簡單的試想，如果一個手機站頁面就可以解決的問題（比如火爆的性格測試），你非要讓用戶下載一個APP才能完成，是不是競爭對手只要抄襲你的產品設計邏輯并且選用用戶更加方便的前端去與用戶交戶就可以產生競爭優勢超過你了呢？（當然如果你有某些無法替代的壟斷資源的話，請盡情的xx用戶來榨取價值吧。我相信這樣的資源本身是越來越少的，或者至少不是廉價可以得到的。）

1. 你的用戶需要頻繁操作嗎？ 是：轉問題2 否：轉問題3
2. 是否需要用戶在戶外（指陌生的不固定地點）頻繁操作？ 是：轉問題4 否：轉問題9
3. 是否工具類？ 是：轉問題12 否：轉問題14
4. 是否需要用戶大量連續操作，且對相應要求很高？ 是：方案1 否：轉問題5
5. 是否對操作實效要求很高（參考超市收銀機場景）？ 是：方案3 否：轉問題6
6. 是否存在連續的數據收集需求？ 是：方案3 否：轉問題7
7. 是否特殊變態的關注用戶體驗（如講逼格，講情懷，講格調） 是：方案1（優先考慮IOS） 否：轉問題8
8. 是否AR/VR？ 是：方案1 否：方案2
9. 是否涉及到在線支付的主流程？ 是：轉問題10 否：轉問題11
10. 是否考慮圍繞支付場景搭建產品？ 是：方案4 否：方案8
11. 是否2B（或有穩定的用戶群長期使用）？ 是：方案5 否：方案6/方案7/方案8
12. 是否需要巨大的計算量（本地，如圖像和視頻處理）？ 是：方案1 否：轉問題13
13. 是否需要復雜交互完成任務？（請結合使用場景選擇） 是：方案9(maybe)／方案11 否：方案10/方案12/方案13/方案14
14. 是否新聞類或資訊類？ 是：方案13/方案9/方案6 否：轉問題15
15. 是否電商類？ 是：其他第三方電商渠道與體系（自建渠道使用方案13/方案6/方案7/方案9） 否：方案N

方案1: APP Native
方案2: APP Webpage
方案3:（單獨的智能硬件） + APP Native
方案4: 圍繞支付場景：考慮支付寶付款碼->移動刷卡機->微信卡包->公眾號+webpage->小程序->不插電／半插電工具類
方案5: PC客戶端
方案6: webpage App（如PWA）
方案7: Android Instant App
方案8: 圍繞主流程偏向實體的產品設計，如門店設計或者單獨的終端機器
方案9: 微信小程序
方案10: Chrome插件
方案11: Mac/Windows桌面程序
方案12: Mac/Windows導航程序（偏插件）
方案13: 公眾號+手機站頁面
方案14: HTML插件（如嵌入頁面的這種）
方案N: 你是否應該想想原始的郵件或者電話營銷就可以滿足你與用戶之間的溝通并解決用戶的問題了呢？這些渠道可以有效控制你的成本在微乎其微的程度上，你也許只需要一個簡單的數據庫進行CRM的簡單管理，有大量的開源服務商提供類似服務，每年成本在幾千塊左右。

PWA

選擇合適的后端

選擇后端我只想說，請讓你的技術團隊選擇盡量輕量級，可以支持快速迭代和變化的架構。其他的架構選擇有待補充吧，只知道大家都在聊Reactor的大前端框架blablabla。承認確實是我目前信息和能力有限，歡迎大家補充。

系統架構

選擇與哪些系統需要如何發生關系通常是你的技術leader需要進行考慮和設計的內容。作為產品，你至少需要做到的是“了解”。why? 兩點原因：

1. 可以幫助你了解你的產品受制于哪些其他的系統和產品。你需要認識它們的負責人
2. 幫助你了解哪些系統的更新可能會影響到你的產品，并提前進行風險的控制。保持信息同步。

我建議產品經理至少在大的產品功能上線或者迭代后，與技術leader溝通，更新自己手上的系統架構圖。這些圖通常長這樣子的，不懂的話要勇敢的去問，因為這很正常。（例如這個xxx server是干嘛的，負責什么的呀？）

系統架構圖樣本

數據模型和API

如何選擇？

如果你需要長期頻繁的關注分渠道的流量數據？你需要對接GA或者百度統計。畢竟它們是大廠出品，全世界的網站都在用，支援性也比較完備和可靠。數據相對可信。

如果你需要多個維度的串連到一些敏感的業務數據（如分析某個行為動作與交易金額的關系）？你需要自己構建一套盡可能簡單的打點系統和體系。你的團隊需要自己組建數據并將它們存放在你們的數據倉庫中。

如果你需要特別關注用戶的過程行為數據？你可以嘗試對接Mixpanel。訪問它們的官網你就懂了。Mixpanel可以非常專業的分析這些過程數據并產出有意思的結論。

如果你需要針對不同的用戶群進行分析？大部分的數據統計工具（如友盟。。）都支持標記用戶群體。你需要的是一個健壯的能夠準確標記用戶屬于哪個群體的算法和邏輯。

如果你需要對某個頁面進行感性的熱力圖分析？Crazyegg是個容易上手的不錯的工具

以上