非废话前言
上一篇我们聊到产品经理需要做需求与问题定位，而且这通常是关乎产品最终生死的关键步骤，如果还没有看的话请务必进行简单了解，戳这里阅读 - 产品经理与产品设计 - 需求与问题定位。
这篇是本篇《产品经理与产品设计》专题的第二篇。整个文章框架大概是下面这张图的逻辑，有一定经验的产品经理可以直接参考脑图版本
本篇我们要说的是：产品经理如何选择合适的技术与平台去解决问题。首先我要说的是“You should not focus on this（你不应该专注于这个问题的解决上）”。但是解决这个问题仍然可以帮助产品经理作出一款令人尖叫的好产品。因为好的产品离不开合适的技术和平台（这里的平台是指选用什么样的前端与用户交互，使用什么样的后端支持数据的运算）
正文
使用合适的技术与平台
- 输入：需求与问题
- 输出：选用的平台（包括前端，后端，系统关联关系和数据模型）
输入
你需要首先非常清晰的了解这个产品（或产品群）要解决的需求和问题是什么。围绕问题的用户，场景和问题，我们进行思考。
如何选用平台
选择合适的前端
请按照如下顺序一次回答这些问题，它们会帮助你最终引导你应该选择什么样的前端与用户交户。
在回答问题之前，我们首先要认识到，我们需要一个尽量快捷轻便的端口去解决用户的问题，并且与用户互换必要的信息，进行必要的交互。
逻辑上某些公司会倾向于选择APP作为与用户沟通的首选，因为APP的用户留存率会最高，粘性最强，便于挖掘用户价值。There we go！我们又发现了一个典型的以自我为中心而抛弃用户利益的产品设计。简单的试想，如果一个手机站页面就可以解决的问题（比如火爆的性格测试），你非要让用户下载一个APP才能完成，是不是竞争对手只要抄袭你的产品设计逻辑并且选用用户更加方便的前端去与用户交户就可以产生竞争优势超过你了呢？（当然如果你有某些无法替代的垄断资源的话，请尽情的xx用户来榨取价值吧。我相信这样的资源本身是越来越少的，或者至少不是廉价可以得到的。）
- 你的用户需要频繁操作吗？ 是：转问题2 否：转问题3
- 是否需要用户在户外（指陌生的不固定地点）频繁操作？ 是：转问题4 否：转问题9
- 是否工具类？ 是：转问题12 否：转问题14
- 是否需要用户大量连续操作，且对相应要求很高？ 是：方案1 否：转问题5
- 是否对操作实效要求很高（参考超市收银机场景）？ 是：方案3 否：转问题6
- 是否存在连续的数据收集需求？ 是：方案3 否：转问题7
- 是否特殊变态的关注用户体验（如讲逼格，讲情怀，讲格调） 是：方案1（优先考虑IOS） 否：转问题8
- 是否AR/VR？ 是：方案1 否：方案2
- 是否涉及到在线支付的主流程？ 是：转问题10 否：转问题11
- 是否考虑围绕支付场景搭建产品？ 是：方案4 否：方案8
- 是否2B（或有稳定的用户群长期使用）？ 是：方案5 否：方案6/方案7/方案8
- 是否需要巨大的计算量（本地，如图像和视频处理）？ 是：方案1 否：转问题13
- 是否需要复杂交互完成任务？（请结合使用场景选择） 是：方案9(maybe)／方案11 否：方案10/方案12/方案13/方案14
- 是否新闻类或资讯类？ 是：方案13/方案9/方案6 否：转问题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的简单管理，有大量的开源服务商提供类似服务，每年成本在几千块左右。
选择合适的后端
选择后端我只想说，请让你的技术团队选择尽量轻量级，可以支持快速迭代和变化的架构。其他的架构选择有待补充吧，只知道大家都在聊Reactor的大前端框架blablabla。承认确实是我目前信息和能力有限，欢迎大家补充。
系统架构
选择与哪些系统需要如何发生关系通常是你的技术leader需要进行考虑和设计的内容。作为产品，你至少需要做到的是“了解”。why? 两点原因：
- 可以帮助你了解你的产品受制于哪些其他的系统和产品。你需要认识它们的负责人
- 帮助你了解哪些系统的更新可能会影响到你的产品，并提前进行风险的控制。保持信息同步。
我建议产品经理至少在大的产品功能上线或者迭代后，与技术leader沟通，更新自己手上的系统架构图。这些图通常长这样子的，不懂的话要勇敢的去问，因为这很正常。（例如这个xxx server是干嘛的，负责什么的呀？）
数据模型和API
如何选择？
如果你需要长期频繁的关注分渠道的流量数据？你需要对接GA或者百度统计。毕竟它们是大厂出品，全世界的网站都在用，支援性也比较完备和可靠。数据相对可信。
如果你需要多个维度的串连到一些敏感的业务数据（如分析某个行为动作与交易金额的关系）？你需要自己构建一套尽可能简单的打点系统和体系。你的团队需要自己组建数据并将它们存放在你们的数据仓库中。
如果你需要特别关注用户的过程行为数据？你可以尝试对接Mixpanel。访问它们的官网你就懂了。Mixpanel可以非常专业的分析这些过程数据并产出有意思的结论。
如果你需要针对不同的用户群进行分析？大部分的数据统计工具（如友盟。。）都支持标记用户群体。你需要的是一个健壮的能够准确标记用户属于哪个群体的算法和逻辑。
如果你需要对某个页面进行感性的热力图分析？Crazyegg是个容易上手的不错的工具
以上
