产品经理经常都会犯一个错误。这个错误可以无限展开。很多产品经理在做称不上有错的、但未必是正确的事情。
作为产品经理，有个大前提是大家经常聊的，就是产品经理的工作内容不是标准化的。这意味着什么呢？一样规模的团队，类似的产品，同样岗位的产品经理却有可能在做完全不同的事情。
你用 Teambition 来协作，他用 Excel；你画高保真的原型，甚至在墨刀上做出来，他可能只是在本子上画画草稿；你更关注管理层的战略决策和方向，他则关注用户的体验和场景需求…… 最后产品，却都做得出来。但哪个方法更好，常常没人去理会。
这就是源于刚才说的前提，对产品经理并没有严苛的规定说要做什么，那大家就往往依着兴趣、依着团队氛围、依着习惯去做了。
我曾经意识到自己在做的未必是最应该做的事，是我整理自己过去几个月的工作内容，发现有一些的确有用，但如果换做别的事情，可能会更有用。或者换句话说，实现一个目的，有很多方法，但我往往会选手边最容易想到的，而不是最好的。
这个错误衍生出来会有很多表现：
1. 事必躬亲
诸葛亮是劳模，凡事事必躬亲，但最后结果是蜀国无大将。朱元璋废掉丞相，也是凡事自己处理，期望集中皇权，但后代都难有他勤奋，终于还是设立了内阁。
产品经理要处理很多除了产品设计之外的很多杂事，但未必都要事必躬亲。无授权领导这个词用得很好：作为产品经理，要把团队资源调动起来，为自己负责的产品服务，但不要用下命令的方式。
在协作中遇到什么没人做的坑，先不要着急去填，想一想这种坑谁来填会更得当、未来怎样填坑会更合理，然后想办法跟别人一起处理。如果你先自己去弄了，那以后这些活就都会是你的，看似让自己的工作更充实，还表现出了大无畏的填坑精神，可是最后结果也就是做了很多不该做的、浪费了应该做更有意义的工作的时间。
2. 做重复劳动
产品经理应当对自己的工作内容也有设计思维。在做的这些事情，是不是每次都花费很多重复劳动？有没有更高效的解决方案？
产品设计上，有时做的功能要考虑逻辑一致性，所以每次都花大量时间去观察跟之前的功能会不会有冲突。但如果有时间把整体逻辑的规则缕清楚，生成一份逻辑一致性的规范，那以后就可以对照着来了。文案的一致性也是如此。
协作时，很多方案的修改通知是在微信群里发的，每次发送和确认过程都很繁琐。如果有时间让大家都用上哪个协作工具，自动发送通知并记录已读回馈，所有人都能节省大量时间。
3. 只关心过程，不关心目的
有时对过程的过度关心，会导致很多形式主义。
比如听说有种文档格式非常好用，以后所有文档都这么写，觉得这个做得足够专业，但未必真适合团队。比如听说用 Axure 画高保真原型，所以也不管不顾当前产品的进展，就硬是用最复杂的方式来做设计。
产品经理的任何工作都是讲目的的，文档是为了跟开发协作和留作记录，那就保证在你们项目里协作和记录都可以良好运转就行了。
或者再举个夸张点的例子，做用研访谈时，没必要完全按照之前的大纲来。如果发现每个访谈对象纠结的点都在提问范围外，那就扔掉大纲，把这个问题搞清楚。甚至发现问题已经确定搞清楚，剩下的访谈也都可以不做了。
产品经理尤其不要沉浸在每天八九个小时的工作充实感上，觉得「我忙了一天了」。充实感应该来自于真正产生的收效上，「我今天确定了几个需求，输出了几份文档，解决了几个问题」。
暂且只说这么多吧。产品经理要对自己正在做的和已经做的时刻警惕，最好有规律地复盘，看自己的工作内容是不是合理、做的事情是不是真的有用。作为有用的判断，通常就是让产品变得更好了，这一条而已。
记住，要经常问自己这个问题：
