对于To B产品经理来说，关心和了解业务，不仅仅是为了更好的完成业务方交代的需求，更是一种自我发展的需要，一种机会。身虽在幕后，心要在台前，To B产品经理关心业务很重要。

今天遇到一位之前做To B产品的小伙伴，曾就职于某二手车交易公司。她提到了一个蛮普遍的情况，可能很多产品经理会遇到。

xx这样的公司，产研基本是执行底层。之前每天和业务pk，最后基本都是业务说了算，毕竟他们最后承担车卖不出去的后果。

产品每年也没几天在店里实地卖车，你要说个靠谱的提议，很难，能比运营、销售更懂卖车么？

可能会遇到这种情况的产品经理，包括但不限于：

a）做To B产品的

b）负责公司中后台系统的产品，但又跟业务结合的比较紧密的，例如电商中的营销系统、物流相关的系统，或者销售所用的CRM系统

c）小公司中面向老板的产品经理（=_=你懂得）

那在这样的情况下，难道产品经理只能天天被业务方按在地上摩擦？

01 产品经理的段位

先打个岔，我们来聊聊产品经理的段位。如果非要按某个标准一分为二，产品经理大致可以这么分：

1. 以产品为手段，能够达成业务目标
2. 在需求相对明确的情况下，提出产品方案并且执行落地

这两个段位的区别，如果从结果上讲，就是能不能为业务结果负责；而从能力维度拆解这个结果，则是两个基本步骤：一是分析问题的能力，这基于对业务的了解和洞察；二是解决问题的能力，这一步大多数时候看其产品工具箱中是否储存了足够多的工具，仍不能解决的话，就要看创造力了。

所以，这里想要说明的是：对业务的了解和洞察，是会深刻影响到产品经理的发展的，是可能成为分水岭的。

在最近的招聘中，这一轮大概面试了30+产品候选人，不敢说拥有这种能力，哪怕有业务意识的也是为数不多。

PS：严格说来，这两个段位上面还隐藏着一层，那就是能够灵活利用各种手段、整合各种资源，最终实现业务目标的人，但能做到这一点的人，虽然title可能还叫产品，但实际已经是业务的负责人。

02 原则：身虽在幕后，心要系台前

上面已经提到了对业务了解的重要性，所以现在要回答文章开始的问题：如果我是偏B端或者偏中后台的产品，我需要那么关心业务么？

答案已经显而易见了：关心和了解业务，并非仅为了更好的完成业务方交代的需求，而是一种自我发展的需要，一种机会。如果有了这种自驱，才能避免“没有时间”、“没有机会”了解业务这样的借口。

从另外一个视角看，假设B端产品经理的直接用户是业务方，那么对产品的同理心也提出了更高的要求：能否把自己代入到业务方的视角，换位思考如何去面对真正的用户？

03 一些更具体的方法

当原则已经对齐，在有了对业务的了解的前提下，在跟业务方的接触中，如何体现产品经理的价值呢？这里有一些之前实践过的方法，难度从易到难排列：

（1）在需求相对明确的情况下，站在业务的视角，给出更能达成业务目标的方案或者优先级

这一条相对比较容易做到。如果能做到这一点，业务方也会跟产品经理之间建立信任，因为双方的目标和利益更容易一致，会感觉彼此在一个频道上沟通。而有了信任基础，可能才能做后面的事情。

（2）做架构师，做通用方案

这个指的不是做技术上的架构师，而是基于对业务的深入了解，从业务方提的零散需求中，能够抽象出共性，能够用一套灵活可配置的解决方案，一次性解决多种问题。而这恰恰也是大多数运营的短板。

熟悉电商的产品应该有所耳闻，营销的玩法是花样繁多，比如很多双十一的玩法不亚于蜀道难。但这并不意味着一切都不能复用，每个营销玩法都要从轮子造起。

比如，所有的营销玩法，都可以拆解成两部分：营销规则，权益。规则就是大家常说的玩法，而权益就是你遵守了玩法之后可以得到的东西。

所以对营销的第一层抽象就是：记录用户的行为和数据，如果命中了规则，则给予用户相应的权益。而营销规则，也是可以穷举和抽象出来的，当然限于篇幅就不细说了，有机会单独说一下。

（3）给出业务洞察，及相关的业务方案和产品方案

这几乎是对于B端产品经理的最高要求，也是在不超越职能边界时产品经理所能做的极限了，因为如果能推动业务方一起来落地，在事实上，你已经成为了那个能够实现业务目标的人，title还重要么？

最后，如果你也有好的建议，可以下面留言分享给大家吧！

作者：树上的男爵；公众号：认知脱困（ID：OldWangNextDoor）

本文由 @树上的男爵 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议