先引用下PONY对于产品经理的要求

以下这段是pony在若干年前在腾讯产品暨技术峰会上的讲话稿：我们希望的产品经理是从技术晋升而来的。

为产品做设计最难的是订优先级和先后次序。判断能力的好坏不能写个报告统计下流量证明就完了。这是非常错误的，我们要看用户是不是需要这个功能。

所以我希望我们的产品经理在产品设计之初就想得透彻一点。产品经理需要投入更多的关注度，关注度不一样，结果出来的很不一样。任何产品都有核心功能，其宗旨就是能帮助到用户，解决用户某一方面的需求，如节省时间、解决问题、提升效率等。

很多产品经理对核心能力的关注不够，不是说完全没有关注，而是没有关注到位。核心能力不仅仅是功能，也包括性能。对于技术出身的产品经理，特别是做后台出来的，如果自己有能力、有信心做到对核心能力的关注，肯定会渴望将速度、后台做到极限。但是现在的问题是产品还没做好。

比如前段时间的网页速度优化，优化之后速度提高很多，真不知道之前都做什么去了？让用户忍受了这么久，既浪费时间又浪费我们的资源。

不抓，都没人理，很说不过去。所以说我们要在性能方面放入更多精力。

谈到核心的能力，首先就要有技术突破点。比如做QQ影音，我们不能做人家有我也有的东西，否则总是排在第二第三，虽然也有机会，但缺乏第一次出来时的惊喜，会失去用户的认同感。这时候，你第一要关注的就是你的产品的硬指标。在设计和开发的时候你就要考虑到外界会将它与竞争对手做比较，如播放能力、占用内存等。就像QQ影音，它的核心性能和速度都超越了暴风影音，所以推出之后发展的势头将会很好。

硬指标选择上其实也有很多选择，如网络播放、交流、分享，这都是很多的思路。但是最后都砍掉了，我们就是要做播放器，因为这是用户的需求。并不是所有人都需要高清，但是高端用户需要（这个后面口碑创造会再提到）。只有硬指标满足了，用户说，我这个破机器，暴风影音都不能放，QQ影音能放。就这一句话：口碑就出来了，用户知道你行，口碑要有差异性。

核心能力要做到极致。要多想如何通过技术实现差异化，让人家做不到，或通过一年半载才能追上。

很多用户评论QQ时说用QQ唯一的理由是传文件快，有群。那这就是我们的优势，我们要将这样的优势发挥到极致。比如离线传文件，以邮件方式体现就是一个中转站，即使是超大的文件也不困难，关键是要去做。虽然真正使用的用户并不一定多，但用户会说，我要传大文件，找了半天找不到可以传的地方，万般无奈之下用了很烂的QQmail，居然行了，于是我们的口碑就来了。

要做大，你首先要考虑的就是如何让人家想到也追不上，这么多年在IDC（互联网数据中心）上的积累我们不能浪费，高速上传、城域网中转站，支持高速地上传？？可能又会发现新的问题，如果不是邮件、在IM（即时通讯软件）上又该怎么实现。

我们的目的是让用户感到超快，飞快，让用户体验非常好，这些都需要大量技术和后台来配合。

产品的更新和升级需要产品经理来配合，但我们产品经理做研发出身的不多。而产品和服务是需要大量技术背景的，我们希望的产品经理是非常资深的，做过前端、后端开发的技术研发人员晋升而来。好的产品最好交到一个有技术能力、有经验的人员手上，这样会让大家更加放心。如果产品经理不合格，让很多兄弟陪着干，结果就会发现方向错误是非常浪费和挫伤团队士气的。

再来说下我自己的理解，这个例子特别适合给初期产品经理理解

首先作为产品经理，不是一定要求你懂技术，但是逻辑一定要严谨清晰，这是作为产品经理最起码的尊严，才能得到开发的尊重，不要让开发经常帮你补充逻辑上的缺陷。个人感觉，程序员最大的优势就是能够把非结构化的交互文档进行结构化处理，举个例子，你给的交互稿是这样子：

但是在程序员眼中是这样子的（类图我快忘光了，有错误请大家指正）：

在程序员的世界里，他需要关注
“持卡人”和“卡”的关系，一个人有几张卡，包括1：N(1对多)，1:1（1对1），N：1（多对1），N：N（多对多），持卡人和卡之间的依赖关系（通过哪个id来关联）。
每个持卡人有多少的属性，比如姓名，性别，头像，生日，证件类型，证件号码，手机号码；每个卡有多少属性，比如医院名称，卡号，卡类型。
除了列出交互设计上标出的元素，还需要知道每种元素的数据类型，id是int，姓名是varchar（20），生日是datetime 。

所以你要做的事情就要在交互稿上标记出持卡人和卡的关系，每个持卡人包含的属性，不同属性的长度（比如支持多少个字符），所以上述交互稿需要补充的交互细节：
1，持卡人信息：包含头像，姓名，性别，头像，生日，证件类型（身份证，军官证，护照，准生证，无身份证），证件号码，手机号码。默认头像区分男女。
2，每个持卡人可以持有多张卡。
3，证件类型：完成身份证填写，自动计算生日和性别，并填充出生日期和性别输入框，同时可以修改。如果无法计算生日和性别，需要用户手动填写。
4 ，姓名长度判断
a）长度不够、长度超或者为空，则提示“姓名长度为2-30个字符，支持中英文”
b）否，下一项判断。
3）手机号判断
a）手机号为空，提示“手机号不能为空”，停留在原界面；
b）手机号格式错误，提示“请输入正确的手机号”，停留在原界面；
c）反之，则进行下一项判断
或者用表格列一下各个元素的数据模型和约束条件

上面这个例子可能我列的并不一定最严谨，通过这个例子可以看出，我们在写需求文档的时候，其实很多底层逻辑要先梳理清楚的，然后在提需求。技术思维和产品思维上的差异非常大，技术关注0和1的同时，同时会从底层去考虑实现方案和细节，产品经理关心的则是不同场景下的最优解决方案，两种思维集合起来，能够帮助业务梳理的更加清晰，同时能够提供更高性价比或者投入产出比的产品方案。

2不懂技术怎么办呢？

并不是所有人都是计算机专业出身，即使是计算机专业出身的，可能底层很多逻辑也不清楚，那如何在这种情况下降低技术沟通成本呢？结合我自己的实践提供几个建议。

一图胜千言

有时候一个复杂的产品业务逻辑需要表达时，除了必要的文字阐述，尽量能通过图的方式表达出来，图能看清整个脉络和模块，还有业务路径一目了然。图片是最直观的表现手段，如果不能通过图来让其他人一目了然我们要表的业务，那就别想用一大段话去表达了。平常大家看到的业务流程图或者走查图就是一个很好的体现，能够帮助我们理清楚整个业务环节，和每个节点需要注意的点，通过图你会发现跟技术会有更多的话题。

读API

结合当下流行的产品，花一点时间去了解他背后的产品机制，比如目前最火的小程序直播，当别人都在屏幕前评头论足的时候，我们是否可以去了解下微信直播的底层逻辑，打开他们的直播接入文档，了解下直播具备的扩展性，而不是去找技术问直播是不是可以嵌入红包，微信，公众号等。其实这些在一些API接入文档里面都有，不要以为这个是技术同学需要去了解的事情，我们也同样需要。另外读API你会发现很多有意思的点，能够帮助你产生更多的业务联想能力。

保持好奇心

现在市面上产品已经很多，很多我们在用的产品，业务已经不再仅仅停留在视觉层面的感知了，而是更多在背后运行，这个时候就需要我们保持一个好奇心，去更多的去学习和探索来，比如信息流推荐，AI识别，智能语音等等。同样的，别人刷抖音是看抖音，我们刷抖音是看他们的广告推荐规则。我把这个定义为好奇心。了解多了之后就可以在未来的业务执行中有参照物，心中有料，产品不慌。

对技术敬畏

“我不管你们怎么实现，反正xx已经实现了”虽然这是一句调侃，但是我们很多时候会陷入这样的误区，别人能实现的，为什么我们不能做到。对技术敬畏，这个“技术”不仅仅是我们的开发同学，而且是技术方案。当我们需要实现某个功能时，或者采用的时候，这里需要区分对待，业务逻辑是否一致，然后再上升到技术层面。

目前能想到的就是上面几点，其他的后面想到了再补充。产品经理的认知半径不应该局限在表现，更多的是了解他底层的业务逻辑，最后想说作为产品经理，不是一定要求你懂技术，但是逻辑一定要严谨清晰，具备理性的分析，梳理清楚业务逻辑，尽可能的把能预见到的问题先于技术之前考虑清楚，降低与程序员，测试同学反复确认的沟通成本，不要经常给自己挖坑，长时间坚持坚持和磨合之后才能得到开发的尊重，不要让技术同学经常帮你补充逻辑上的缺陷。

最后说下我最真实的想法，产品经理其实最应该懂得是用户，懂技术也是为了更好的为技术同学提供服务，毕竟他们也是我们的用户。

关注公众号【子凌不语】，带你领略不一样的产品打怪之路，原创文章还有红包哈哈

子凌关注公众号「子凌不语」，免费加入互联网创业者社群