很多传统企业转型互联网公司，都在逐渐组建自己的研发团队。这类公司一般都是在业务转向线上的初期，雇佣外包公司快速搭建系统，搭上020转型的第一班车。随着业务的发展，公司系统逐渐变大，系统也在外包公司手里遇到的问题越来越多，最常见的就是沟通效率低下，迭代速度慢，数据安全性无法保障等。
遇到这样的瓶颈期，老板们大致有两种选择，一种是收购当时合作的外包公司，或者把当时项目组的研发挖过来，作为自己的it部门；另一种就是独立组建自己的研发团队，重新开发产品。 这样的公司里的研发团队，领导的思维还是重业务，重线下运营，在互联网团队的管理、研发的业务流程管理上没有经验，所以在这样的环境下做产品经理，很容易做成“需求分发型”产品经理。
需求分发型产品经理
“需求分发型”产品经理的工作方式基本是业务驱动的，业务在系统实操中遇到问题，把需求提交到产品手里，产品把需求记录，然后转述给研发，等系统上线后，产品再给业务做一个培训，算一个需求的完结。这类产品经理对研发提出的问题，回答的口头禅是：我去问问业务。笔者亲自见过的，一个表的筛选项都是由业务来确定。这样的产品经理，换作一个愿意管闲事，能听懂业务逻辑的人都能胜任，就是一个需求的分发器，最多给需求排个优先级。
研发和业务的关系不仅仅是业务驱动系统研发，产品在这中间也不是单纯的分发需求。IT和业务的关系，是互相推动的，业务的增长，会推动IT系统更加完善的发展；IT的高逻辑性，反过来也会给业务带来更规范性的要求，产品经理就是其中最重要的一环。
产品经理到底是干什么的
概括的说，产品经理是整理需求，规划设计产品，最终把系统推进到上线使用的一个职位。如果把产品经理的工作比作一个黑箱，输入的只是一个需求，输出的是一个产品。比如，输入：打车不好打，我需要实现即时打车。输出就是：滴滴打车。产品经理工作中是理性与感性并存的。产品的竞品分析、数据处理等方面都需要强逻辑性去完成；产品的UI，交互等方面，则需要感性面多一些。
具体的说，产品经理日常的工作可以分成三个阶段：
需求分析
产品设计
产品落地
需求阶段，产品需要对需求进行处理，工作中会有各种“需求”，真需求，伪需求，来自客户的需求，来自领导的需求，研发反馈的需求...接到需求后，往往对需求进行梳理，会做一些业务流程图、角色流程图、需求分析报告等等，便于产品及研发人员更好的理解需求。同时，要与业务方沟通，确定每个环节的业务规则，比如要设计一个红包系统，就要先确定红包的发放比例，金额规则，中奖比例规则等等。业务需求大致就是以上三方面的内容：业务背景，业务流程，业务规则。
产品设计阶段，也就是传说中的“画原型”“prd”，这一步就是把业务信息翻译成界面信息，让抽象的业务转换成直观可视化的界面。这是产品的基本功，往往产品助理都是通过画一整天原型的锻炼中“上道”的，原型中的逻辑体现，边界值的体现，异常情况的体现等等方面都可以代表一个产品的逻辑水平。原型与需求文档即prd，一般是同时进行，prd文档中，跟随在需求分析后的部分就是原型部分，需说明原型的设计思路，页面上数据的来龙去脉，业务操作的场景等等，一切说明都是为了便于研发的进行，要达到让研发根据这份文档就能开始coding的效果。
产品落地，也就是跟进研发测试的阶段，研发中遇到的问题，产品需时刻沟通，研发过程中会遇到很多原型阶段遗漏的问题，要在落地环节不断完善，直至测试完毕系统上线投入使用。投入使用前，产品经理需要跟进产品的使用培训，一般是给业务人员演示培训系统，或是出产品使用文档/使用视频。
至此，产品经理完成了一个系统的从无到有的工作，绝不是时刻被业务推动，每个环节都需要产品用自己的专业性，推动系统的产生。另一方面，时刻做好业务和研发之间的桥梁，做最懂IT的业务员，最懂业务的研发人员。
产品上线后，产品的工作还实际上没有结束，产品经理需要对系统内产生的各种业务数据进行分析整理，对于不能直接拿到的数据，需要埋点跟踪，分析用户的使用习惯等，提出系统的改进方案，做迭代计划。同时随着业务的发展，一定有新需求的出现，这时候需要产品跟进新需求，结合分析结果，制定合理的迭代计划，继续推进产品。
