产品经理时常需要与运营打交道，当有的B端产品经理把自己的精力都铺在运营工作上的时候，我们不免会疑惑：B端产品经理应该多关注需求分析，还是产品运营？作者结合一个故事与大家探讨这个问题，一起来看看吧。
“B端产品经理应该多关注需求分析，还是产品运营？”
在一次部门周会上，有位同事抛出了这个问题，引发了大家的热议。背景是该同事所在的供应链履约中台，最近的大部分精力都铺在一个供应链项目的运营工作上了，辅助业务方梳理业务规则、分析数据找方向、处理线上问题，好不容易抽出时间来写的几个需求，因为精力原因，思考的不够，有很多漏洞，在评审会上被技术同学diss了，导致他开始怀疑自己的工作似乎偏离了自己的初衷，正在走向一条偏离正轨的不归路。
B端产品经理是否需要具备运营能力，这是一个很开放的话题，也是很多日常繁忙的产品朋友们共同的遭遇，可惜没有标准答案，因为在不同公司，不同部门，不同阶段，不同的人的理解都会不一样。但是，在每个公司的每个现状，是能够找到明确答案的。本篇文章，木笔和大家一起详聊一下产品经理能力模型下的需求分析和产品运营这两项技能，希望能够给正在为此烦恼的朋友们一点思考和方向。
老规矩，先从一个故事开始讲起。
01 小Q的故事
3年前，小Q入职了一家新零售公司，负责供应链相关的产品工作，因为公司刚成立不久，业务和系统都在不断的探索和尝试，组织分工也不明确，产品和业务同属一个部门，大家都需要一起背业务指标，产品经理也需要分担一部分业务运营的工作，这对之前一直在大厂从事需求分析工作的小Q来说，是个很大的转变，具有挑战，但也足够兴奋，因为自己可以离业务更近了。
刚开始时，业务只是在小范围试验阶段，小Q配合业务的节奏搭建了一套很简单的进销存系统来满足业务日常的采购、库存管理和订单发货业务，这段时间，小Q最主要的工作就是每天泡在库房里，和业务沟通和梳理流程，然后整理成需求，和技术团队评审、开发，系统从0到1的搭建过程很艰辛，连续3个月披星戴月，几乎每个周末都在加班。
千呼万唤，系统终于上线了，业务也可以放开手脚了，开始在每个城市开设门店，小Q便开始和业务同事到各地出差推广系统和培训系统，顺便收集各方需求，这是小Q第一次做项目推广实施，发现和呆在办公室里写需求是完全不一样的感受，原来自己思考的很多场景和想法都是闭门造车，在现场并不是这样的，还是要多深入一线哪！
慢慢的公司业务越来越大，业务场景也越来越丰富，有更多的业务需求提交过来，需要高优支持，小Q又开始把主要精力放回需求分析上，不断完善系统功能，再推广应用到每个门店里，由于只是功能的完善，除了重大功能更新需要去现场外，其余时间只需要远程指挥即可，这样就可以节省更多的时间了。
就这样经过2年多的持续迭代以后，业务模式已经相当稳定，业务发展也到了瓶颈期，很难再有野蛮的增长了，只能通过精细化运营来寻找新的增长点。当前阶段，系统建设也趋于稳定，需求也不多了，小Q便开始和业务一起搭建数据运营指标，并把很多精力放到了分析数据和挖掘问题上，一旦发现了一个新的机会点，便立即付诸行动，快速验证，当然结果有好有坏。
做了很多的运营工作后，小Q发现，产品经理的成就感不光来自自己设计出了一套很受欢迎的系统，如果能够找到数据背后的价值，为业务赋能，更是一件成就感满满的事……
02 需求分析与产品运营
从小Q的故事里可以看到，产品经理的工作不是纯粹的需求分析，还有部分产品运营的工作。
在大部分的互联网公司里，产品经理和产品运营是同一个部门下的两个不同的岗位，产品经理负责需求分析，产品运营负责系统和业务相关的运营，大家彼此合作，一个像妈妈，负责生孩子，一个像奶妈，负责养孩子。但也有很多公司，需求分析和系统运营是不分家的，产品经理既要负责生又要负责养，负责到底。
通常在一个分工明确的公司里，产品经理和业务是分属不同的体系，产品经理的职责主要是针对业务方梳理好的brd产出prd，设计系统，没有过多其它的事情分散精力，产研配比在1：4或者1：5，即一名产品对接4到5名开发。这种情况下，产品经理只要关注于做需求分析，产出高质量的需求就好，不用关注业务的好坏（有业务方负责），不用梳理业务流程和规则（业务方梳理好了提过来），也不用管理项目进度和质量（有专门的PMO负责）。
在这样的工作环境里，需求分析能力就显得尤为重要了，因为这几乎就是我们工作的全部，工作成果好坏的评判标准主要是系统规划能力、需求质量的高低和设计的系统好坏，如果需求分析没做好，工作自然是不合格的。
而在另外很多公司，产品经理和业务是属于一个体系的，没有那么明确的分工，没有专门处理系统问题的人，没有梳理业务规则产出brd的人，也没有项目经理跟进项目，还没有专门的数据分析人员，这些事情大多都落在了产品经理头上，有些公司甚至还需要产品经理背业务指标，这样产品经理就天然具备了运营属性，除了完成需求分析和系统设计工作之外，还需要处理大量的运营工作，由于精力有限，产研比通常只能维持在1：3或1：2左右，有时可能更少。
需求分析工作相对比较聚焦，主要处理从需求调研到系统上线期间的需求相关事宜，核心精力集中在系统上线前。产品运营则要宽泛的多，除了需求之外的事情，都可以称为运营，包括但不限于梳理业务SOP、系统实施与培训、线上问题处理与跟进、线上数据分析、寻找业务机会等，核心精力集中在系统上线以后。
▲需求分析与产品运营工作分工
而根据运营的工作性质不同，产品运营又可以分为系统运营和业务运营两个方向：
（一）系统运营：偏系统方向，主要负责系统相关的运营工作，目的是为了让系统的运行更加顺畅，包含系统的上线推广、系统的培训、线上问题的反馈与处理机制、系统的策略配置与系统日常运维等；
（二）业务运营：偏业务方向，主要负责业务的推广和增长，目的是为了让业务能够更好的发展，包含业务规则梳理、运营数据分析、业务机会挖掘、推广方案制定与执行等；
在项目上线前，主要工作是需求分析，上线初期，系统运营工作居多（培训、推广、问题处理），上线稳定以后，就主要是业务运营工作了。如果在系统运营和业务运营过程中发现了新的问题或机会，会再回到需求分析阶段，如此循环。
▲需求分析与产品运营工作分工
03 系统思维与运营思维
需求分析需要用到系统思维，产品运营用到运营思维，系统思维和运营思维其实是两种非常不一样的思维方式。
系统思维的目标是更好的实现系统能力，所以更多的关注业务需求和系统架构，而运营思维则是为了更好的达成业务目标，更多关注业务数据和业务规则；系统思维非常注重结构化和逻辑，要充分考虑哪些功能可以抽象到一起，哪些功能适合解耦，以此保证系统的合理性和灵活性，方便未来扩展，而运营思维则更需要发散，只有先发散才有可能在不同的点子里找到解决问题的最优方法，一旦有了方法，就希望系统能够快速支持，以便尽快验证。
▲系统思维与运营思维
当这两种思维碰撞到一起时，产品经理既要兼顾系统的架构合理性和稳定性，又要能快速支持运营试错，矛盾就产生了，这也是很多产品经理和业务运营之间的矛盾根源，因为想要搭建合理的架构，就必然会牺牲一定的时间，没法快速支持业务。同时，想要无限满足业务运营天马行空的要求，系统就只能定制化开发，朝不保夕，bug不断，这当然是产品不能接受的。
所以，当产品经理和业务运营因为思维不同产生冲突时，就需要在这两种思维中寻找一个平衡点，这个平衡点就是业务目标。无论是产品还是运营，都是为了更好的服务于业务，尽早达成业务目标，大家应该以此为前提寻求最优解，用系统思维思考如何尽量在保证底层架构完整的前提下快速支持业务，用运营思维思考在系统可实现的前提下来解决业务问题，如果大家能够目标一致，很多矛盾也就迎刃而解了。
04 到底谁更重要？
了解了需求分析和产品运营的工作性质和工作分工后，我们再回到文章开头的那个问题上来，产品经理应该多关注需求分析，还是产品运营？虽然两者需要不同的技能，但并不是南辕北辙，对于产品经理来说，处在不同的阶段，需要的技能是不一样的，重要程度也有所不同，我们试着从企业业务发展的角度来探讨一下。
回到小Q的故事上来，我们把小Q的经历整合一下，便是一个完整的业务和系统的发展路径，大多数的业务都会经历起步期、快速扩张期、平稳发展期和稳定运行期4个阶段，产品经理身处其中，在每个阶段的贡献有所不同。
（一）业务起步阶段。业务在刚起步时，通常以试水和MVP模式验证为主，业务量没那么大，系统也只需要用最基础的功能做支持即可。这个阶段也是系统从0到1的基础建设阶段，产品经理在以最小模型支持业务发展的同时，还要考虑到系统未来的扩展性，比如业务的扩展、数据的扩展、功能的扩展、权限和角色的扩展等，以便后续业务做大做强时，系统建设能快速跟上，不会拖业务后腿。这个阶段就对产品经理的需求分析能力和系统设计能力要求较高，而对运营能力要求较少。
（二）快速扩张期。此时业务模式已经跑顺，系统基础建设也完成了，到了快速推广复制阶段，比如不停的开城、开仓，这个阶段需要的产品运营能力，产品经理最重要的工作是跟随业务扩张的节奏做系统相关的实施推广（前提是没有专门设立实施推广的岗位），做培训、整理SOP、并收集和处理推广过程中的问题等。
（三）平稳发展期。这个阶段业务推广已经基本完成，业务进入到平稳发展期，流程通畅，线上问题逐渐变少，产品经理的主要精力又会回到系统功能的迭代上来，需要不断完善系统功能以满足业务诉求，需要的主要技能又是需求分析能力了。
（四）稳定运行期。这个阶段的业务已经过了高速发展期，没有特别大的波动了，急需要通过精细化运营来寻找新的增长曲线，此时系统也趋于稳定，如果产品经理想要创造更多的价值，就不能只把心思放在系统上了，而是应该和业务一起去寻找新的发展方向，那就需要有业务运营能力了，分析数据、挖掘机会，然后再快速转换为系统需求，如此反复。
▲不同业务阶段的产品技能
无论身处哪个阶段，不管组织上如何分工 ，业务还是那些业务，问题还是那些问题，只是每个公司的分工方式不同，有的公司要求产品经理更加专注于需求分析和系统设计，有的公司则希望产品经理更加贴合业务，不希望产品和业务之间有那么明确的边界，但不管如何，出发点都是为了更加高效的发展业务。
我们需要知道一个真相，公司的背后是商业和资本，需要为资本方负责，所以组织分工的初衷往往是为了更好的达成业务目标，并不是为了让每位职场人过的舒坦，打工人们只能在资本方设立的规则下找到自己的价值，寻求自己的舒适区。
作为产品经理，我们的价值是持续的为业务创造价值，而需求分析和产品运营都是我们创造价值的方式，也是我们提升产品能力必不可少的技能，只是在不同的公司、不同的阶段侧重点不同，所以不要排斥，等我们把两项技能都了然于心以后，就能在不同的环境下都游刃有余了。
有时你认为的打杂，只是业务不同发展阶段的需要。
有时你认为的不务正业，正是你腾飞前的滑行时期。
专栏作家
木笔，微信公众号：供应链产品笔记，人人都是产品经理专栏作家，产品一俗生，深耕于供应链领域。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。