对于To B产品经理来说，关心和了解业务，不仅仅是为了更好的完成业务方交代的需求，更是一种自我发展的需要，一种机会。身虽在幕后，心要在台前，To B产品经理关心业务很重要。
今天遇到一位之前做To B产品的小伙伴，曾就职于某二手车交易公司。她提到了一个蛮普遍的情况，可能很多产品经理会遇到。
xx这样的公司，产研基本是执行底层。之前每天和业务pk，最后基本都是业务说了算，毕竟他们最后承担车卖不出去的后果。
产品每年也没几天在店里实地卖车，你要说个靠谱的提议，很难，能比运营、销售更懂卖车么？
可能会遇到这种情况的产品经理，包括但不限于：
a）做To B产品的
b）负责公司中后台系统的产品，但又跟业务结合的比较紧密的，例如电商中的营销系统、物流相关的系统，或者销售所用的CRM系统
c）小公司中面向老板的产品经理（=_=你懂得）
那在这样的情况下，难道产品经理只能天天被业务方按在地上摩擦？
01 产品经理的段位
先打个岔，我们来聊聊产品经理的段位。如果非要按某个标准一分为二，产品经理大致可以这么分：
在需求相对明确的情况下，提出产品方案并且执行落地
这两个段位的区别，如果从结果上讲，就是能不能为业务结果负责；而从能力维度拆解这个结果，则是两个基本步骤：一是分析问题的能力，这基于对业务的了解和洞察；二是解决问题的能力，这一步大多数时候看其产品工具箱中是否储存了足够多的工具，仍不能解决的话，就要看创造力了。
所以，这里想要说明的是：对业务的了解和洞察，是会深刻影响到产品经理的发展的，是可能成为分水岭的。
在最近的招聘中，这一轮大概面试了30+产品候选人，不敢说拥有这种能力，哪怕有业务意识的也是为数不多。
PS：严格说来，这两个段位上面还隐藏着一层，那就是能够灵活利用各种手段、整合各种资源，最终实现业务目标的人，但能做到这一点的人，虽然title可能还叫产品，但实际已经是业务的负责人。
02 原则：身虽在幕后，心要系台前
上面已经提到了对业务了解的重要性，所以现在要回答文章开始的问题：如果我是偏B端或者偏中后台的产品，我需要那么关心业务么？
答案已经显而易见了：关心和了解业务，并非仅为了更好的完成业务方交代的需求，而是一种自我发展的需要，一种机会。如果有了这种自驱，才能避免“没有时间”、“没有机会”了解业务这样的借口。
从另外一个视角看，假设B端产品经理的直接用户是业务方，那么对产品的同理心也提出了更高的要求：能否把自己代入到业务方的视角，换位思考如何去面对真正的用户？
03 一些更具体的方法
当原则已经对齐，在有了对业务的了解的前提下，在跟业务方的接触中，如何体现产品经理的价值呢？这里有一些之前实践过的方法，难度从易到难排列：
（1）在需求相对明确的情况下，站在业务的视角，给出更能达成业务目标的方案或者优先级
这一条相对比较容易做到。如果能做到这一点，业务方也会跟产品经理之间建立信任，因为双方的目标和利益更容易一致，会感觉彼此在一个频道上沟通。而有了信任基础，可能才能做后面的事情。
（2）做架构师，做通用方案
这个指的不是做技术上的架构师，而是基于对业务的深入了解，从业务方提的零散需求中，能够抽象出共性，能够用一套灵活可配置的解决方案，一次性解决多种问题。而这恰恰也是大多数运营的短板。
熟悉电商的产品应该有所耳闻，营销的玩法是花样繁多，比如很多双十一的玩法不亚于蜀道难。但这并不意味着一切都不能复用，每个营销玩法都要从轮子造起。
比如，所有的营销玩法，都可以拆解成两部分：营销规则，权益。规则就是大家常说的玩法，而权益就是你遵守了玩法之后可以得到的东西。
所以对营销的第一层抽象就是：记录用户的行为和数据，如果命中了规则，则给予用户相应的权益。而营销规则，也是可以穷举和抽象出来的，当然限于篇幅就不细说了，有机会单独说一下。
这几乎是对于B端产品经理的最高要求，也是在不超越职能边界时产品经理所能做的极限了，因为如果能推动业务方一起来落地，在事实上，你已经成为了那个能够实现业务目标的人，title还重要么？
最后，如果你也有好的建议，可以下面留言分享给大家吧！
