不少其他岗位的同事与产品打交道时，总以为产品的工作很容易做，甚至有人就因为这样直接转岗。但转过来后才发现，想做好产品经理，其实也不是那么容易的，需要经历这三个阶段。
如果你也做过产品的甲方（这里主要指b端），也就是产品业务需求方，你是不是常常觉得“好像产品经理这个活儿我也能干啊”？
没错，我就带着这个错觉信心满满的转行做了产品经理，后来我发现，从产品甲方到产品经理，大概都会经历3个阶段：
这一阶段通常是转行前到成为产品经理的前3个月。结合我的职场心路历程来说，在互联网二线厂做了1.5年的B端产品业务Owner后，产品0到1、1到n的经验攒了不少，尤其是如何给产品找bug、如何提优化需求、如何验收需求、如何培训产品使用，这些经验，基本都可以平移过来赋能产品经理的身份。对新接手的1到n阶段产品，能很快发现存在的问题（毕竟是新用户，对那些初次使用没看懂的功能设计，基本等同于交互不清晰），一副磨刀霍霍大展拳脚的架势。
这一阶段是发生在作为产品经理经历第一个成规模的迭代时。首先是需求评审时来自研发的轰炸。复杂的功能，肯定涉及前后端的多重交互，对于中途接手的产品经理新人来说，是很难分辨出哪些逻辑是接口实现的，而这些接口依赖的字段又是不是现成的？涉及增改字段的，这个需求的耗时就会拉长。这时会发现梳理出来1个需求，最终实现能拆分出5个以上子需求来。
就算是评审基本通过了，实现过程中表面上轻易一改，动辄就与历史逻辑、在先功能冲突，一些藏在代码中的隐形逻辑就会跳出来阻止，让人不得不接连感慨“居然还会这样”。最终为了赶上线时间，不得不接受研发给出的退而求其次的实现说辞：这次先这样，下次、下次再说。
这一阶段是发生在入职一年后。逐渐开始恍然大悟原来过去的逻辑虽然不太符合你自己的习惯，但也确实有存在道理，一些自以为的优化点，实际上可能是干掉了一些既有功能。如果说总结几条从产品甲方转型到产品经理的tips，我认为要做好以下几点：
1.讲好故事。“需求”的英文翻译是“story”，每创建一个需求，其实就是在讲一个故事，包括这个故事的背景、故事发生的场景“6个W”要素、故事的主人公、故事能升华的意义……作为故事的叙述者，要把故事给研发讲明白，让他们也能充分认可这个故事的逻辑；要把故事写清楚，这样无论何时回顾才能清楚；要把故事给用户讲动听，相比于“我告诉你这个功能能支持xxx”不如强调“你在xx时会用到这个功能，你因为要xx遇到不便时这个功能能帮你xxx”，把“我有什么”转化为“你需要什么”的讲述。
2.要有边界感。需求中一个检索词的长度、屏幕划词的范围、展示的最大条数等等，均需要考虑极值情况；需求的实现有边界，同样一个迭代的版本也要有边界，我的经验是，如果新功能点已经能在最核心的位置A实现，对于可加可不加的位置B、C，新上线时就尽量不加——这样才能尽量控制工作量和bug率。
3.懂业务、懂业务还是懂业务。作为B端产品，不论是需求方还是产品经理，往往直接对接的人都不是真正的用户，这也是B端产品工作的痛，总是跟真实用户有距离，通常是凭借几个场景的画面去想象使用场景。问问自己，你真的用过这款产品吗？你要真的让自己带着用户真实使用意图去操作一遍，才会感知到这款产品的好与坏，注意：不要用测试数据、不要用臆造的使用流程、不要浅尝辄止的操作。
今日分享完毕，祝愿大家都能顺利转型！
本文由 @Mini耀 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。