从快播庭审聊聊产品经理要不要懂技术

因为好友曾经在快播公司工作，任职产品经理，曾主导几个快播的核心产品，在他快速成长时期，快播出事了。。。所以，我这两天都有在关注快播庭审。

庭审中发生了一些有趣的事，甚至有人整理了一份快播语录，站在同行从业人员的角度，我倒不是抱着娱乐的态度关注此事，毕竟这是围绕一个互联网软件产品持续发酵的事件，对产品设计人员应该也有所启发。

不过庭审中一些细节倒是值得关注：

张克东：如果达不到一定的码率，快播软件就会启动缓存服务器开始加速；达到了码率，就会自动断开。

法官：软件它为什么会知道？它是机器人吗？

审判长问：文件加了密，你为什么不解密？

审判长：我觉得你们这个110系统功能也不是很复杂啊，技术难度很简单嘛。屏蔽的网址很好改吧？一天可以改100个？

审判长问张克东：你是搞技术的是吧？从你了解来讲，画面拦截能不能达到？

特意截取的这几个问题并不是为了嘲笑法官和审判长在互联网技术领域的无知（术业有专攻，况且审判长两天的表现来看还是相对中立客观的），而是这些问题可以引起我们对日常工作中一些现象进行思考。

如果你是产品经理，可能以上几个类似的问题你或多或少曾经问过响应你需求的程序员；如果你是程序员，你或许经常被产品人员问到这样一些无知的问题感到十分厌倦。

所以，今天聊一个老生常谈的话题：到底产品经理要不要懂技术？

曾看到网上流传着若干小马哥语录，具体是不是小马哥所说也无从考究，「提需求就好，没有什么技术实现是不可能的」，「产品和服务是需要大量技术背景的，我们希望的产品经理是非常资深的，做过前端、后端开发的技术研发人员晋升而来。好的产品最好交到一个有技术能力、有经验的人员手上，这样会让大家更加放心」，「很多产品经理对核心能力的关注不够，不是说完全没有关注，而是没有关注到位。核心能力不仅仅是功能，也包括性能。对于技术出身的产品经理，特别是做后台出来的，如果自己有能力、有信心做到对核心能力的关注，肯定会渴望将速度、后台做到极限。」...

当年QQ空间甚至有一条铁律：任何页面从Loading到呈现给用户，不可以超过3秒，不重要的数据可以使用异步加载。

如果你是产品经理，如果不懂技术，你可能不知道一个页面从输入网址到最终打开，发生了些什么，用什么来量化打开速度，什么速度是可以被接受的。

当然本文也不是说非技术出身的同学做不了好的产品经理，而是想通过快播庭审中发生的一些话题，阐述自己的观点：

产品经理基于对事物的系统、全面的认知做出产品根基，然后在此根基之上，利用对人性、事物的认识设计出一个个的产品功能。而如果你懂技术，能让你有更系统的认知、更经得起推敲的产品结论，以及做出能够落地的产品设计。

有点儿虚，举个例子说人话，如果要从零开始做一个APP，产品的根基就是后台系统、运营系统、基础数据上报、异常处理及现场收集、消息推送、APP基础功能、用户协议条款等--对事物的系统、全面的认知。

如果产品经理懂点技术，那提的需求就不至于是天马行空、空中楼阁。你会关注并理解技术实现方案，更好跟产品需求进行串联，评估产品需求最终实现程度。

如果产品经理懂点技术，可以让你准备更加充分，对话更平等，在跟程序员沟通时能提高对话效率。比如程序员说，你这个不能这样设计，如果X个人有Y个身份标签，那么展现时复杂度就增加许多，笛卡尔积啊！！！且不说存储上和检索上慢不慢，就界面展现也不好放啊。。。还有简历这么大，那么多用户，到底要不要用CDN、分布式存储？

这时候你可能会问「笛卡尔积」是什么？「CDN」是什么？「分布式存储」又是什么？程序员还得费劲巴拉跟你解释，你还不一定听得懂，这时候你们的沟通就可能是低效的。

如果产品经理不懂技术，在与程序员进行可行性分析对话时就处于知识储备劣势方的位置，你辛苦构想的产品思路，可能就会被一句「这个实现不了」、「这个太麻烦了，做不了」打回，这时候你们的对话就不是平等的。

如果产品经理懂点技术，可以让你的产品视野更加开阔，说不定一些有意思的技术创新，就可以用到你的产品上。比如NFC、二维码、摇一摇、重力感应、多点触碰、3D touch 、Beacon基站、人脸检测与识别等等名词，你大概知道当中几个是怎么回事，干什么用的？快播事件庭审中反复提到的分布式存储、黑名单白名单模式、码率加速、加密与解密、文件HASH编码、自有协议（如快播的QVOD://josdffsdfsdfdsfdf）又理解了多少？

至于懂技术能增强你的逻辑严密性、更了解程序员更容易合作之类的就不赘述了。很喜欢@邱岳 所写产品经理就是「让正确的事情相继发生」，做产品的人懂技术，思考问题更全面些，自然「正确的产品决策」就更有可能「相继发生」。不然你所设计的产品架构三天两头功能变更就要求技术架构做大演进，技术人员不砍死你才怪？

不服，那你告诉我技术人员口中常说的「笛卡尔积」是什么？