作为产品经理，你可能会忽视哪些实际上很重要的“小事”？

举个例子，产品比较小的时候，需求可以有很多，面临的方向也可以有很多，大家都在进行不断的调整。这个时候，有可能会因为某些因素（公司要求产品盈利等等），而出现你原本安排好的下一版需求没办法做了或者需要推迟做，要优先做其他的。可能这个时候你已经做完了所有的需求分析，一旦改变，那么就要赶时间做新的东西了。

这个时候，你该怎么办呢？

我其实理解很多人会因为个人原因去拒绝这种变化，大家都是人，怎么会不明白呢？

但是，做产品人不可以这样，因为有可能会因为你的执意，导致团队在做错的事情。

这个时候，需要考虑的不是个人增加工作量的问题，而是对整体产品好不好的问题。如果确定对整体产品比较好，那么就该摒弃个人的负面情绪，顺势好好的执行下去。

这样做的好处：

对整体产品好、对团队成员好；

顺便锻炼自己的应变能力和心脏承受能力。

▍要把锅背起来

产品经理是需求的开始，也是需求的结束。只要上线了，那么就说明你是允许这个上线行为的。

如果上线后程序有大bug了、某个功能被用户骂死了等等，产品经理都要学会去负起责任，如果负不了责任，那么至少要先把锅背起来。

要端正自己的态度，不要出问题就赖开发码太多bug了、测试不给力什么的，毕竟，你才是最终决定上不上线的人。

这么做的好处：

团队对你有信任感；

个人学会承担也是一种极大的成长。

▍灵活看待制度

举个例子：一般公司都会规定版本上线的时间。但是如果App临上线前发现了一个大bug或者比较影响体验的bug。那该怎么办呢？是推迟上线，等修复后再上线呢？还是不管三七二十一，制度说要上，那就上呢？

不同人有不同的选择，但是出于对产品的考虑，是不是选择前者更为好呢？

一上线就bug反馈papapa，崩溃率papapa，用户差评papapa，这真是你要看到的结果吗？

你这个时候再去因为这些papapa去修复、去重新再上一个新版本，这又是多曲折。

当然，我并不是鼓励不遵守制度，而是说要灵活的遵守制度。毕竟，情况是复杂滴，人是活滴。

▍执行想法：成功落地本身比想法更重要

很多人会说，“我想法多”、“我思维活跃”，但是想法多真的有你想象中那么重要吗？

想出来了，那之后呢？总要执行的吧。如果执行不了，那么你的想法就等于什么也不是（当然，这里排除光靠想法去融资的，毕竟你的执行就是找到了人替你的想法买单）。

不要不看重想法，但也不要把想法看的太重。真正创意意义上的想法，我认为注定是少数。而绝大部分的产品经理，你要清楚，你也许是暂时没有这个能力的。

你觉得我看死了你的能力？并没有。所有的创新其实哪里是凭空想出来的，都是基于对大势或是对环境或是对行业或是对用户的深刻理解，没有一定的经验是出不来的。我个人是不相信偶然事件的。

既然，暂时无法做创新，那么就该把当下的事情做好，在执行的过程中积累，为未来做准备，同时，从结果论上来说，也对结果负责了。

▍节操不要太高，但底线一定要有

很多产品经理很唾弃产品之间相互借鉴这件事，不管三七二十一，看你产品长的差不多就说你像素级抄袭，这其实是很呆逼的行为（电商都长一样，你能说他们抄袭吗？）。

我不是为了反对这些人的想法而反对，而是说：

借鉴什么功能、适合用什么形态来展现，这些都是需要根据不同产品的特色去选择的、去体会的。即使是借鉴，也是做了大量的思考和改良的。而这个差别，就是有些产品能够借鉴成功，有些不行。

跨界的借鉴从行业上来说更具有意义。

如果正向的解释你看不懂，那就从反向想一想：目前这个互联网上，有什么产品功能或者产品形态是真正意义上没人做的吗？如果真的没有，那么你赶紧拉帮人去创业吧。

既然是已经存在的事物，那么人家坑都帮你踩平了，你何不借鉴一下现成的东西，再根据自己产品的情况去改良一下呢？还非得自己去全部踩一遍坑才满意吗？

大家都是成年人了，就不要相信什么抄袭可耻了，应该认为借鉴有益才对；

大家都是成年人了，也不要太执着于自己的爱豆是乔布斯了，并不是人人都可以是乔布斯。

以上，对于“产品借鉴”的看法，是为了说明在很多事情的思考上，并不需要一板一眼，能够解决问题的方法就是好方法，而不需要给自己设定一条无形的线，这个不可以做，那么不可以做。那样，你会把自己给累死。

虽然不需要那么有节操，但是底线还是要有的。违法乱纪相关的事情还是不能做滴，这个就不多加赘述了。

好啦，暂时想起来这么多，如果觉得有补充的，可以在评论中告知哇～

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!