to B产品杂谈

写在最前面

此篇是人人上看完20多篇关于to B产品如何设计/运营的专业文章的有感而写，很久没有写文字，因为的确写文字比较难坚持，看到很多博主从勤更勤更，到少更少更，到某一天再无更新。我也是在还没有自己专栏的时候就已选择了放弃。并且以前入门时候写的产品体验集，一些功能交互对比之类的，着眼点可能还是太表面肤浅，现在作为一个入行快2年的产品经理，自然而然发现自己的眼界更高些。

此篇可能主题不太明确，也没有图，不用太介意，更多的是读书笔记+自己工作中的经验感想拼凑起来，重点在于自己知识点的梳理。不过也深知从无到有的创新有多难，所以就在前人的基础上加点想法，也可以作为自己的小创新。也是写作需要一个着力点，不是凭空而想，后面写顺手了再写专题吧。

其实在工作过程中，会发现碰到一些问题觉得没有方法指导不知道怎么做才是对的，当时可能就是凭经验凭感觉处理，但是平时不注意，等到到别人文章里说起，才发现自己碰到的也是个共性问题，是有理论解决方案的。所以你会发现理论支持的重要或是参考其他优秀产品经理经验之谈的重要。在你没有依据的时候你会发现你自己说出的话都是虚的，也就是俗称的自我心虚，对自我的否定有多恐怖，你可能都抵挡不住开发的提问，威望也就难以建立。

另外，看了这些过来人的经验之谈，才发现我们老大很有大局观，这点我一直了然于心，有自己的产品价值观。但是也发现了之前有些我不太认同的措施是很有依据的，之前没认同可能是我知识浅薄，没有达到足够的高度来理解。我们老大虽然顶着项目经理的头衔，但也的确算是个大产品经理。

---

to B产品的定位

1、to B产品更多是一个生产工具，因为面向企业，企业需要借用你的产品提升生产效率。并不像C端产品一样，来实现一些人性的需求。提升生产效率永远都是to B产品作为一个工具存在的最高目标。

2、B端产品更像是在串链条，每个关键链条的环都很重要，缺一不可。一个企业的ERP系统就需要OMS\ERP\WMS\MRP\OA\财务等，缺了某个模块，竞争力就明显下降，因为线下业务就这么串联进行，缺了某块业务怎么进行。所以B端产品的重构上线时间周期就很长，都要等所有链条的环扣自己圈起来，跟别的环扣起来，还要做好润滑，才能上线给客户用。尤其注重和其他系统的协同和边界。C端产品更像是在搭积木，搭好几块重点的积木，这个产品就算完成了，后面可以继续再搭其他块积木，但不影响主要建筑的积木。这个点在某篇文章里看到，觉得很有意思。

3、to B产品更多是产品化和线上化。线上化，B端产品的需求来源于线下实际的业务场景，也就是有业务需求，只是我现在难以线下手工处理，需要借助线上化的产品来提升工作效率。产品化，我的理解产品化更多是通用化，每个企业对于相同业务的处理都不太一样，可能因为一些现实情况有所适应。但是作为软件方，我们应该提供通用的产品，至少是行业通用，而不是为单个企业设计的产品。

4、服务。服务的产品思维一定要建立，这非常有别于C端。付费客户的确比免费用户更有话语权。B端产品除了卖产品也是卖服务，决策过程很长，也就有了很多软件公司常有的其他岗位，比如售前/客服/实施/技术支持等，即使你不是最前线的服务人员，对产品业绩的负责，也要有服务思维。

to B产品和to C产品的一些区别

以下详述的框架一部分借用下某位大佬现有的框架http://www.woshipm.com/kol/435622.html

1、客户和用户。C端叫用户，B端叫客户，这个很有意思，因为我也是从C端转B端，以前叫惯了用户，现在改口叫客户。客户更理性，更多是一个组织，B端就是企业，工作就代表着严谨性，为公司决策和为自己决策本身的情感因素是不一样的。而用户就是更感性，更关注实现人性的需求。

2、用户需求和业务需求。C端的用户量很大，需求其实也很多，但是缺少很多需求收集渠道，很难了解到一手需求，用户也很难说出自己的需求，需求更多需要挖掘。而B端主要是业务需求，业务流程本身就存在，只是在线上，软件需要将线下已有需求系统化。但是B端终端客户还是个人，所以也算是通过业务需求间接满足用户需求，这也算是两者的某个共性吧。

3、串链条和搭积木。这个比喻我觉得还是很形象的，具体的我在前面定位里已经提到。

4、免费和收费。C端更多是免费，即使是收费也是增值服务多，因为一些盈利渠道可以是达到用户数量后的广告，商城4等。但是B端很多时候真的是靠收费，卖软件活着，钉钉算是个例吧。

5、产品和服务。to B的整个使用过程和决策链都很长，并不是说一个软件交到你手里你就会使用，所以很多软件公司都有服务部门，需要售前/售后/实施来支撑这一长时间的决策过程和使用过程。所以toB产品经理为了产品发展好，不仅仅为了产品本身，还要考虑产品后续的一整个服务过程。

6、本地和云端。对于这个概念我本来没有太多认识，但是反复听到一些客户说我们现在数据部署在阿里云上让他们很是担忧。毕竟万一出了什么事，政府一查数据就了然了。不想部署在本地，或许还可以摧毁数据库。数据安全的确是一些大企业重点考虑的问题。

7、渠道和资源。你会发现C端客户量动辄几百万几千万，B端客户要是要几万估计已经了不起了。在大用户量的背后很多时候是大资源投入运营，可能投钱在AppStore挂在排行榜上，你的下载量就蹭蹭蹭涨了。但是B端产品重在渠道，很少看到B端产品的企业投入很大资源在某个渠道上。渠道的多样性和深入性很有可能影响产品的推广，所以你也会发现很多软件公司都有自己的渠道商，的确重实施的软件线下渠道是一大重点。

8、垂直和通用。垂直领域做的深，通用领域做的广，这个大家都知道。现在很流行一些垂直电商，比如跨境网易考拉，蘑菇街，唯品会等。在to B产品上我觉得或许更需要综合考虑，要符合每个行业的共性，也要对个别行业做个性化设计，实现行业版本。

9、角色和决策。想象下C端用户的购买决策，可能真的只是个人的一时兴起。但是反观下B端客户，一个决策过程，不是一个人完成，是协同完成，涉及发起者、使用者、影响着、决策者、购买者。从了解到入驻到初次登录到选购产品是一个长时间的过程，这个过程要注意入驻要低成本入驻，比如说很多软件都是免费试用，以及在选购产品的过程中一定要加快决策者的决策速度，让整个周期变短，有更多精力面对其他更容易促成交的客户身上。

10、业务和数据。C端是完成业务，比如你完成一个购买流程。但是B端也是完成业务流程，但是更关注数据。你会发现很多客户切换软件都要把之前软件里的数据导入到新软件里，方便分析对比软件。但是业务产生数据，所以在产品设计上，也要遵守，先实现业务逻辑收集数据，再做数据加工。

to B产品对产品经理的要求

1、产品布局，这可以说是所有产品都应该思考的，但是很少产品经理有这大局观，更多的是执行，毕竟没有把产品当成自己孩子，也就不会为自己的孩子考虑未来发展。产品布局是个长远的计划，我们需要知道产品处于哪个阶段，处于哪个区间，上下级区间是什么，因为最后一定是要做平台化和一体化的。另外，to B产品都有个业务--数据--决策的过程，整个产品的迭代开发也要按照这个思路，也就是有了业务基础才会产品数据，有了数据，才会产生更高的价值。

2、调性。就是所谓的产品价值观，所有的产品由产品经理一手设计的，都会有产品经理本身的基调，也应该有，这是体现产品和人融合。

3、服务意识，前面好像提过了

4、对称交叉的产品技能。需要需求/商业/体验/技术交叉集成的技能。按理来说是所有产品所有掌握的技能，只是在to B产品里尤为突出，综合能力，因为客户+开发+市场+追求，很多因素促使你需要关注方方面面。

产品阶段

1、MVP阶段。MVP是最小可行化产品，其实就是做核心功能，这阶段的特点是敏捷开发，根据用户反馈，迅速响应，快速迭代，不断增补功能。这期间也需要做一些客户的成功故事，来为后面的增长阶段做案例准备。

2、增长阶段，实现客户增长。也就是当完全基础功能后，就要实现用户量的增长，来证明产品方向和产品价值。这阶段的特点是注重客户粘性，减少客户流失，同时产品在不断打磨。

3、变现阶段，实现商业变现。这也是to B产品必经之路，没有变现的产品是失败的产品。这阶段的特点是形成需求——产品实现——数据验证，数据验证驱动生成新需求的良性循环。

to B需求设计

重构

1、首先整理产品现有的各觉得的业务流程

2、再根据现有业务流程增删改查，重新整理出优化后的流程，这就是一个解构和重构的过程

3、之后就开始按照模块的原型设计

4、最后一点也很重要，给老板画大饼，让他投入资源支持你。

需求梳理框架

1、用户。定义用户，有些公司自己的后台系统，可能就是业务部门/老板，像ERP系统，用户就是各个企业员工。

2、场景。关注现在线下是怎么操作的，再想怎么转到线上系统化。并将客户需求拆分成很多小问题，穷举可能的场景。当时要注意客户的要求不是需求。

3、路径。各个角色的业务流程

定制需求

1、前期充分调研此VIP客户，在会议洽谈前列列举想问的list

2、多次会议沟通，每次会议都要有记录

3、整理成开发文档，需要减少开发量

4、需求变更也是常有，但是要发all

结语：

请多多包涵...