1. 更丰富的产品设计工具

通常我们的产品设计工具有文档、流程图、交互设计。但其实还有更多更好用的工具等待我们去发掘。对技术思维的了解，能够为产品经理提供更多更直观的工具去进行设计。例如：

• UML类图（不需要太精确）能够替代名词定义，释清对象之间的联系。
• 用例能够帮忙厘清用户需求，分解特性点，也能方便产品经理体验 DEMO 和进行 sanity 测试。
• 时序图能够帮助产品经理整理子系统和外部系统的调用关系，估算成本、优化策略。
• 状态机能够让关键对象的状态以一种无比清晰的方式表达出来，让整个项目的人一看就懂。
• 在面对稍微复杂的特性时，伪代码能让产品更好地与研发沟通，梳理并发现问题。

最重要的是，以上这些工具的学习成本都不高。

2. 对运算、通信、存储等成本更加敏感

很多产品决策其实是商业决策，网络通信是否快速、服务器能否HOLD住产品需要的计算能力，这些成本因素也可能决定着产品能否活下去。产品设计的策略可能对实现成本产生巨大的影响，产品经理需要懂得如何优化资源，用最聪明的方式去解决问题。

懂技术的产品，会对这些成本因素更加敏感。这样的产品经理需要对网络通信、数据结构和算法有一定的知识积累，甚至会进行时间复杂度和空间复杂度方面的估算。

其实，这些因素也会影响用户体验，特别是外部调用较多的场景。如何优化整个网络请求的时序、如何平衡同步和异步的流程、如何通过交互设计隐藏由于技术限制而产生的体验缺陷，这些决策都能大幅提高产品设计质量。我在做MIUI云名片，以及短信识别机票信息（在一个界面中使用了大量外部网络请求）时，对这点的感受非常强烈。

3. 了解设计模式

基础的设计模式，如工厂模式、单例、代理、适配器、观察者模式等等，我认为是产品经理的必修课，非常实用。了解这些设计模式，让我们能对产品的实现方式、难易程度和可扩展性有初步的估算。

然而设计模式这个主题更吸引我的，则是「N大设计原则」（有些地方描述为 S.O.L.I.D 五大原则，有些地方则是六大原则、七大原则、十大原则）。这些原则，甚至可以提升到哲学层面，为各种生活决策、个人管理提供指导性的意见，在产品设计上甚至还有豁然开朗的感觉。

DRY原则告诉我们：「Don’t Repeat Yourself.」

单一职责原则（SRP）说：「每一个类应该专注于做一件事情。」

依赖倒置原则说：「抽象不应该依赖细节，细节应该依赖抽象；即针对接口编程，不要针对实现编程。」

又如开闭原则（OCP）：「Open for extension, Yet closed for Modification.」

而迪米特法则的那句「低耦合，高内聚」更是经典。

这些设计模式，都是经典。细细品味，妙趣横生。熟悉代码的应该比较好理解，不熟悉的建议找本书来研读。初步了解可以看看这个网站。

4. 快速搭建原型的能力

研发资源总是紧缺的，而产品经理总想做新东西。掌握初级前端技术的产品即可快速搭建一个可用的原型，说不定这样就能拿到投资了呢？

而且浅尝前端技术也并不难，HTML+CSS已经可以搞定大部分场景了，iOS 和 Android 开发也并不难上手。而且现在的傻瓜式开发工具也越来越多了，入门门槛也越来越低。况且，市面上还没有哪款原型软件能比得上用代码直接写出一个来。

5. 能够更清晰地把握系统的现状

工程师最讨厌产品哪点？改需求、乱评估工期，还有就是：不懂重构等技术调整对产品的意义，明明很重要的事情，却一直分配不到优先级。

这是产品经理对技术的无知导致的。

随着业务的增长，产品在后台和运维层面都要经过一些调整才能更好地支持业务发展，这些事情包括但不限于：制造开发工具以缩短开发流程、封装固定的业务流程以增加复用性、购买更多的带宽和服务器、优化性能、重构。

懂技术的产品经理能对系统的现状有一个大致的了解，并且在产品需要以上技术调整时，能够提供合理的资源和优先级支持，更能够帮助统计和表达技术调整对业务的贡献，避免让有价值的事一直沉寂在后方。

——————

说了那么多，最后有一个问题：产品经理懂技术，意味着需要自己会开发吗？

不。

不是因为产品经理不应该懂，而是因为今天的软件开发是一个巨大的工程：前端、后台、算法、运维等等，每一个环节单独提出来都是一整个团队的工作。没有哪个产品经理能够搞定这一切。我们所需要做的，是理解研发，并且帮助研发做得更好，减少沟通成本、提升业务效益。

至于有些人说的「技术思维和产品思维难以转换」，这只能说是能力问题。你看人家 ponyma，既是技术大牛，同时也能一秒钟变小白用户呢！