编辑导读：产品经理需要懂技术吗？这是一个永远有人在讨论，永远没有答案的问题。而作为一个从技术转做产品的人，本文作者在工作中总结了自己的一些感悟，比如技术型产品经理的定位是什么？产品经理对技术的了解程度如何划分？如何设计出一个架构合理的系统？本文对此展开分析，与你分享。

计算机专业+一年IOS前端开发转型产品，让我对技术的了解相较于一般的产品经理要多一些，平时也更多的承担技术强相关的系统方案设计工作，因此有一些我一直在不断反思，尝试给出更好答案的问题，比如：技术型产品经理的定位是什么？产品经理对技术的了解程度如何划分？如何设计出一个架构合理的系统？

本篇文章准备就这类问题尽量展开去讲，抛砖引玉。

一、技术型产品经理的定位

我对技术型产品经理的定位是：以用户需求为导向，充分利用现有技术及新技术的研究，为用户提供更高质量的产品。

这句话有两个要点，一个是充分利用现有技术，另一个是推动新技术的研究。

1. 充分利用现有技术

第一点强调的是什么呢？是扛需求、是推动业务落地的能力。所谓充分利用现有技术，核心要点是保证自己能够提出一个合理范围内的落地方案，既不畏首畏尾，让产品落了俗套，又不天马行空，完全不具备可行性。这才能叫可落地。

需求的来源有很多：竞品的新特性、领导的需求、自己的需求、合作方的需求等等，每个人站在自己的角度讲自己的想法。能落地吗，谁该做什么？这是技术型产品经理要问自己的第一个问题，他应该具有对全链路的把控能力，前端、后台、总控、意图、解析、对话，每个部分该承担什么？改动量如何？任务该如何拆解？存在什么依赖关系？

技术型产品经理需要兼具从用户和技术的角度看问题的能力。平衡技术实现与用户需求，把最初想法转化成真实可落地的实施方案，是技术型产品经理的一个重要的任务。

关于这点，我有一条约束自己的标准，这里分享出来，即：问题是否到我为止？换言之，我能否有能力成为所有问题的最后责任人？交付到我这的问题，要么我解决，要么我找人解决，我对最终交付负责。

2. 推动新技术的研究

第二点强调的是：预见性和解决未来问题的能力。作为产品经理，应当对整个业务的发展方向有正确的理解；作为技术型产品经理，应当对业务发展所需的技术有一个明确的认知。

因为我们可做、能做、还没做的事情太多了，都要做吗？显然不是。事情有个轻重缓急，作为产品经理，推动技术研究朝着未来业务最需要的地方发展就是自己的职责。

这一点要求我们根据业务的发展方向，明确什么是重要而不紧急的事，然后在条件允许的情况下，优先去处理它们。否则等到所有的事情都重要且紧急之后，那每天的工作会变成到处救火，且犯错的概率也会由于缺乏深入思考的时间而大大提高。

举个真实例子，我八月份提过一个需求，九月份上线之前，有个业务方的新需求明确依赖我提过的这个需求，而且还非常着急。如果等接到需求我再开始筹备，至少要将他们的上线时间推迟半个月。

关于这点，我同样有一条约束自己的标准，虽然自己暂时还做不到，但这里也分享出来，即：别人是否有机会向我提出问题？换句话说，就是我是否能够总是比别人先发现问题，然后推动问题在真正产生负面影响之前解决。

二、产品经理对技术的了解层级

我曾给出一个三层的划分，用于描述产品经理对技术的了解层级：

第一层：知道什么能做，什么不能做。也即知道所谓的技术边界。不论是自己提需求，还是承接别人的需求，你都能肯定的做出『支持』或『目前还不支持』的判断。

第二层：知道什么好做，什么不好做。也即，当产品需求超出了目前系统的边界时，或者说某需求当下『不能做』时，你有能力给出一个权衡了产品需求与系统改动量的初步技术方案。能做到这一层的人，可以说是一个称职的技术型产品经理了，至少有能力跟技术人员进行高效的沟通。

第三层：知道什么该做，什么不该做。也即，你知道系统中的每个模块的定位和意义，并有能力以业务需求为导向协助技术人员、甚至引导技术人员完成对系统架构的优化与改造，使其在未来能够更好的满足业务发展对于技术的要求。

第三层比较抽象，这里做一下解释。当业务场景较为简单且有限时，很容易出现一种情况，就是系统设计与业务严重耦合。实现一项业务功能的链路会很长，从头到尾涉及到很多模块，这块逻辑你做也可以，他做也可以，往往人们总是倾向于选择最符合直觉，看起来最直接的方案。但这样通常会造成模块间定位不清，逻辑分散的情况，当业务渐渐复杂起来，就不得不进行重构，否则就再难拓展。