本文是作者对业务主导、产品经理话语权、成长方向的一些看法，如果你也有这方面困惑，不妨看看~
一、决策权
鄙人不才，刚巧就是在业务主导的公司里做产品经理，而是偏业务线的产品经理，还做超过了3年。所以对于这个问题应该是有发言权的。
在业务公司做产品时，最大的质疑就是，你都没有决策权，你还算产品经理吗？
这个事我是这样看的：首先来说，没有决策权是复杂条件造成的，并不能完全把这个锅甩给业务主导。举个例子来讲，自上而下的决策机制，也会导致产品经理失去决策权，一切都领导说了算嘛反正。
那么真实的场景是什么样的，产品经理真的失去了决策权吗？首先把一个产品立体来看，底层是业务逻辑，只不过很多C端产品的业务本身就是产品团队或运营团队。所以他们会有很大的决策权，并且很多时候都直接合并为产品运营岗，就是为了决策权不分散。
二、业务逻辑
底层之上，是产品逻辑。产品逻辑和业务逻辑什么区别呢？举个例子来讲，对于一个智能招聘系统来说，HR团队是业务团队，他们背负了招聘率、差评率等等好多指标，也决定了招聘规则和流程。也就是说这套业务规则是业务团队掌控的，统称为业务逻辑。
而业务逻辑，会成为产品经理的一道命题作文题。也就是说，你的想法再多，再正确，不能超于命题之外，否则也是零分的。
那么产品逻辑是什么呢，在这个业务框架下，产品经理究竟能做什么呢？
首先第一点就是，要抓住业务这个命题，确定你的中心思想。也就是说，你的一切产品逻辑，都是为了业务指标的提升而设计的。
如果业务要提高招聘率，你就要把投递简历的渠道同步变得极其强大，把整体招聘系统的效能提高到极致。但这个时候，就衍生了两个问题：
其实往往来说，业务指标和产品团队的指标就是不太符合的，并且产品经理往往对业务指标不太敏感，这就容易造成产品经理和业务的互相不信任。
从业务的视角来看：你这个产品经理可有可无啊，我底层逻辑已经给你了，你还跑出来做拦路虎，这不是影响业务吗？
而从产品经理的角度来看：你的底层逻辑虽然有，但是缺乏产品感，很多东西没有用户体验，商业和数据价值也不够，肯定需要完善啊！
这样一来一回如果没有对齐口径，就会加深两方的误会，那么解决方法是什么呢？
鉴于这是一个天然的冤家问题，我们就只能采取缓解化解的手段，而不是硬钢。老实说，在业务主导公司内部，任何试图抢占主导地位的团队，最后好像都很惨。
所以化解的角度来说，就是多找业务谈心，把他们的诉求当作自己的诉求，把他们的指标变成自己的指标。如果遇到方案上的摩擦，一定要不卑不亢。如果你选择卑微，那你得不到业务的尊重，他们会更加觉得你可有可无。如果你太亢进，对方又会觉得你越界，扮演了拦路虎。
不卑不亢这个境界，是我们具体情况具体分析才能达到的一种状态，所以在这里只能给一个方向，毕竟这个状态很多产品经理做了10年都没有达到。
2. 业务逻辑我想改变怎么办？
这一点其实可以算作一个命题，也就是科技转型。我一直认为，科技转型不是要转变为科技驱动，而是科技的数据思维、产品思维能够内化到业务团队当中去，变成业务决策的一大因子，这样才能起到科技驱动的作用，才算完成了转型。
业务仍是主导，科技也无需和它互相替代，只不过更加加深了底层的合作。
对应到这个问题来看，就是产品经理要尽早主动地参与到业务的决策当中去，贡献出自己的意见。这点实现起来其实特别难，举个例子讲：业务一般会提交很多需求给到产品经理评估、落地，这个时候其实产品经理的时间已经被占满了，如果再介入业务，工作量上讲其实是超量的。
为了解决这个问题，一般科技转型都会提出一个办法，叫做“拥抱业务”。拥抱业务指的是，科技人员向业务团队靠拢，但怎么靠拢呢？是直接取消产品经理，研发直接对接业务吗？不是的。
拥抱业务绝对不是减少流程和环节，而是把所有的职能业务化。比如：产品经理更多地参与到业务决策，而RD更多地参与一些产品经理需求分析的工作，这样环环相扣，大家就把业务的工作量逐层承接传导到了研发层面。而业务多出来的时间，可以用来了解研发团队。这样一个工作量的平移，就可以带来整体科技元素的比重，以及产品经理参与度的提升。
所以老实说，有几个命题一定是正确的：
只会产品、技术、设计但没有某个领域业务深耕经验的产品经理是无价值的；
在没有科技转型战略的业务型企业，产品经理想靠个人努力站主导地位是不现实的；
产品文化和工程师文化到最后都是回归业务，C端个别如搜索等领域技术本身就是业务。
三、产品逻辑
那么产品经理能做的是什么呢？
首先从日常工作流程来讲：
其实跟做C端一样，也是了解业务。只不过C端的业务就是流量运作，包括增长和留存还有转化。而B端就是了解这门生意是怎么运作的。而研究流量运作，最重要的就是看数据、做分析、想方案。而研究一门生意，要看的不仅仅是产品数据，要做的还有业务数据指标和业务场景访谈、用户调研。
鉴于此，我们工作的形式就有差别。做C端产品时，要多看数据多分析。做B端产品时，要多调研访谈。之前做C端时，我几乎每天80%的时间都在看数据，写文档。现在做B端，我几乎要花大半天时间调研问题再找人办事。所以千万不要认为只有写文档才是正事，开会和聊天可能更重要。
最重要的是需求运作模式就完全不一样了：
业务主导的研发团队来说，因为业务支持都是P0级别的第一时间响应要求，所以业务提出一个需求，只需要跟领导汇报，然后强压给研发团队即可。而产品产出的需求，需要内部上级汇报、总监汇报，再由总监和业务老大碰，碰完之后再跟业务自己提的需求PK。
支持需求和自发需求相比，一个是一级汇报，一个是四级汇报，时间周期和效率都没法比，所以产品经理觉得累，觉得自己想做点事情非常难。
但这样有没有好处呢？好处就是产品经理的沟通技巧要求非常之高，业务主导公司是一个很好的提高沟通技巧的环境。对于四个层级的汇报，你要准备不同角度的材料，再充分考虑好每层级汇报可能的后果，可能的需求变更和修改时间，最后来算算自己的需求什么时候可以上线。这样流程下来，一个好的方案一定是具有很高价值且经过多方打磨的方案。
总结
所以我提了一个问题，产品经理到底是决策者还是执行者？
我个人倾向于后者。我觉得决策其实没有我们想象的那么重要、那么必不可少，而执行的过程也没有我们想象的那么固定和不可操作。很多时候命题命好了，能不能挖到价值才是你的本事。
最后给大家一点建议：决策和执行都只是形式层面的人为区分，所以我觉得产品经理最重要的不是决策也不是执行，而是迅速搞清楚团队的所需，然后补充上去。这个补充的形式可能是产品规划、项目管理、微决策或是会议组织，但只要是能提升用户体验和商业价值的活，都值得一做。
那么产品经理的核心竞争力是什么呢？
我觉得就是迅速切入一个行业、一个团队的能力，这个能力需要很高维度的思考模型、很深层次的经验来支持。所以日常我们一定要关注每一个项目，不断问自己能不能做到更好。
实践永远是最重要的。产品之术之所以有这么高粘性的关注者，就是因为我不是为了写而写，脱离了实践的写作和命题，本身对于自我和他人都是没有帮助的。只有从实践中的总结，才有个人特色，才有经验价值，才能形成输入和输出的闭环。
所以遇到任何问题千万不要第一时间拿自己的现有知识去套，这样只会让你陷入想当然和不理解，但多实践、多感受、多摸清楚问题后，才能看到真实的世界，这个时候再总结思考才有意义。
以上是我对业务主导、产品经理话语权、成长方向的一些看法，如果你也有这方面困惑，不妨参考尝试一下，也可以随时和我交流。
与君共勉。谢谢！
