请把“产品经理”这后面的“经理”两个字去掉!

个角色作为进入互联网世界的暂时优先选择。

选择完后，想从宏观上细致了解现有的产品经理的角色到底是干嘛的，然后故意啃了一本死厚死厚的讲传统行业产品经理的书，书名是《产品经理的第一本书》，喏，就是下面图片这货：

当时看完，那真的是有种气吞山河的气势，原来产品经理这么牛掰，每天在都斡旋于各种部门之间、运筹帷幄产品“大”事件，想想毕业后要做这个，还有点小激动呢，自我心略膨胀啊，改变世界就在眼前。

到了工作之后才真正体会到，人家那本书说的是“传统行业”的“产品管理”，但是我们大多数人身处的却是“互联网行业”的“产品执行”，行业成熟度上就差了不是一个level，产品管理和产品执行更是相差了整整一个“经理级”辣么远…

一个“经理级”辣么远，到底是有多远？

我个人认为，能真正被称为产品经理的人，至少具备以下点：

1、熟练产品本身的工作：

1、熟练产品本身的工作：

从0-1为何开始？如何开始？（行业认知？竞品分析？…）

每个版本做什么以及依据？（是数据分析了？还是用户调研了？还是市场反馈了？还是补技术债？还是第三方合作了？…）

…

2、熟练产品迭代过程中涉及结合的运营（新媒体、投放…）、商务（第三方合作…）的结合点和大致工作内容；

3、熟练管理（团队人员管理？迭代版本管理？资源协调？…）

以上的熟练是真的熟练进而生巧，同时对自己的决策有把握。做一次二次那不叫熟练。

简单来说，就是知道如何带领团队做一款好产品，然后卖出去。个人认为，这个要求是极高的，没有长时间的积累是不可能的。

而现在市面上，因为“人人都是产品经理”这个口号（虽然本意是好的），但是确实也是把经理二字的意义拉低了。

然而小小年纪的我们，又不懂，“经理”二字无形中会影响我们对产品工作的认知，比如文章开始的知乎那个问题，多了很多不知道哪儿来的不切实际，少了很多应该有的脚踏实地。

没有日常对行业、对用户的一点点的积累和认知，怎么得出的目标市场、产品定位？

没有对产品细节、运营、商务的理解，怎么得出的目标成本、销售目标？

没有强有力的逻辑分析、交互理解，怎么来的需求描述、用户场景？

没有和其他部门例如运营、广告、商务的对接结合产品的综合考虑，怎么来的需求优先级？

脑袋里想的都是：我要做大事、我要立产品方向、我要写MRD…你能对你写的东西负责吗？

产品方向定错了，你担得起责任吗？

不要以为所谓的立项就仅仅是立项，如果通过了，还需要大把人和你一起做这个项目呢，说大了还得对和你一起付出的设计开发测试们负责呢，有时候你一句话人家就得改一天代码呢。

厉害的只是产品经理这个title，并不代表你自己厉害。台上一分钟，台下十年功，所有给出的好的产品方案，都离不开平时一点一滴的脚踏实地。

那么，接地气的产品又每天在做什么呢？

1、用自己的产品和竞争产品

作为行业产品的用户，会慢慢有用户的心态，同时心态还会渐变，整体对产品的理解会扩大一个维度，更加容易从用户角度上看待问题；

作为竞品的用户，可以从竞争对手的变化中，发现同行厉害的点或者验证自己想做没做但同行做了的效果；

作为自己的用户，会更清楚的感受到产品有哪些问题、需要优化的又是什么；

俺们选股宝团队里每天用时最久的是技术老大昊神（又称比特币矿主），常年排在用户每日用时榜前三，经常提出一些体验上的优化。对于这种技术老大，也是没sei了。

2、看用户唠嗑、和用户唠嗑

每天都会看看自己产品的用户群里在讨论什么，从用户的讨论中可以感受一部分的用户痛点、用户思维决策方式，从而可能有利于产品、运营；

在后台反馈或者用户群中看到有想法的用户留言或者发言，抓出来，和他们讨论，有时候能够爆发出一些有趣的东西；

3、看和分析产品运营数据

相比少数人的“我以为”、“我觉得”，我更相信广泛意义上的统计数据的力量。

数据会告诉我们：

用户更喜欢这里的内容，但是停留在那里的时间更久；

用户更习惯于从这里接受推荐，但是又有自己的使用路径；

这种推广方式用户不买账，那种活动方式用户更爱一些；

…

当然，数据可能会因为各种原因掺了假或者因为鸡生蛋蛋生鸡的循环而骗我们，但是，还是一样的道理，好好用就都有用。

4、管理需求池

暂未解决的bug、需要优化的部分、可以新增的功能…

产品本身的、其他部门需要的…

需要不断的维护和管理，方便了解产品现有状况和有利于列出下个版本的迭代需求list。

5、迭代中和开发、设计、运营的沟通

这个工作列出来好像看起来非常废话，但其实不然。

迭代初期：和开发沟通沟通需求、和设计师细节沟通和一次次确认设计稿…

迭代中期：和开发偶尔调整需求细节、和设计师沟通引导页、欢迎页、广告页、应用商店宣传图等、和内容运营讨论和确认活动…

迭代后期：和运营、内容最终确认活动相关入口和素材、和投放确认投放素材、和开发测试确认最后的版本情况…

以上的内容还不是全的，有些还是相互穿插的。除了这些之外，人不能保证自己一定没有疏漏的时候：

需求分析漏了一个判断啦、临时加的一个需求有问题啦、设计稿不符合android的特性啦（苹果爸爸大法好）、沟通问题导致开发人员没有做这个需求啦、设计素材缺了啦、临时有重要bug啦、打包版本打错了啦、证书过期了啦、产品从属关系有问题啦…

真正迭代开发的时候，什么事情都有可能出现，当然，可能大公司制度完善，开发时间长一些，可以一定程度减少这类事情的发生。但是，完美计划的完美执行，这几个字一定是个梦。

产品需要临时或者一直去协调这些东西，并不是一件容易的事情，尤其状况一起出现的时候。

6、和第三方合作

工作并不会像你预计的那样一步一步走，有时候经常是你想好了明天要做什么、下周要做什么、这个月要做什么，然后第二天立马就pia pia pia打脸。

这个第三方想跟我们合作，要去具体聊一下合作方案如何以及之后的技术对接；

那个第三方要跟我们用另一种方式合作，得评估下性价比；

那个想跟我们合作整一个定制版，还得考虑和自己产品的差异性；

花样不要太透哟哟哟…

打乱你一两天的工作优先级那倒还好，有时候合作力度大了，还可能会影响你整个月、整个季度的工作安排。

7、确定下个版本的需求及需求分析