此篇是人人上看完20多篇关于to B产品如何设计/运营的专业文章的有感而写，很久没有写文字，因为的确写文字比较难坚持，看到很多博主从勤更勤更，到少更少更，到某一天再无更新。我也是在还没有自己专栏的时候就已选择了放弃。并且以前入门时候写的产品体验集，一些功能交互对比之类的，着眼点可能还是太表面肤浅，现在作为一个入行快2年的产品经理，自然而然发现自己的眼界更高些。
此篇可能主题不太明确，也没有图，不用太介意，更多的是读书笔记+自己工作中的经验感想拼凑起来，重点在于自己知识点的梳理。不过也深知从无到有的创新有多难，所以就在前人的基础上加点想法，也可以作为自己的小创新。也是写作需要一个着力点，不是凭空而想，后面写顺手了再写专题吧。
其实在工作过程中，会发现碰到一些问题觉得没有方法指导不知道怎么做才是对的，当时可能就是凭经验凭感觉处理，但是平时不注意，等到到别人文章里说起，才发现自己碰到的也是个共性问题，是有理论解决方案的。所以你会发现理论支持的重要或是参考其他优秀产品经理经验之谈的重要。在你没有依据的时候你会发现你自己说出的话都是虚的，也就是俗称的自我心虚，对自我的否定有多恐怖，你可能都抵挡不住开发的提问，威望也就难以建立。
另外，看了这些过来人的经验之谈，才发现我们老大很有大局观，这点我一直了然于心，有自己的产品价值观。但是也发现了之前有些我不太认同的措施是很有依据的，之前没认同可能是我知识浅薄，没有达到足够的高度来理解。我们老大虽然顶着项目经理的头衔，但也的确算是个大产品经理。
[title]to B产品的定位[/title]
1、to B产品更多是一个生产工具，因为面向企业，企业需要借用你的产品提升生产效率。并不像C端产品一样，来实现一些人性的需求。提升生产效率永远都是to B产品作为一个工具存在的最高目标。
2、B端产品更像是在串链条，每个关键链条的环都很重要，缺一不可。一个企业的ERP系统就需要OMS\ERP\WMS\MRP\OA\财务等，缺了某个模块，竞争力就明显下降，因为线下业务就这么串联进行，缺了某块业务怎么进行。所以B端产品的重构上线时间周期就很长，都要等所有链条的环扣自己圈起来，跟别的环扣起来，还要做好润滑，才能上线给客户用。尤其注重和其他系统的协同和边界。C端产品更像是在搭积木，搭好几块重点的积木，这个产品就算完成了，后面可以继续再搭其他块积木，但不影响主要建筑的积木。这个点在某篇文章里看到，觉得很有意思。
3、to B产品更多是产品化和线上化。线上化，B端产品的需求来源于线下实际的业务场景，也就是有业务需求，只是我现在难以线下手工处理，需要借助线上化的产品来提升工作效率。产品化，我的理解产品化更多是通用化，每个企业对于相同业务的处理都不太一样，可能因为一些现实情况有所适应。但是作为软件方，我们应该提供通用的产品，至少是行业通用，而不是为单个企业设计的产品。
4、服务。服务的产品思维一定要建立，这非常有别于C端。付费客户的确比免费用户更有话语权。B端产品除了卖产品也是卖服务，决策过程很长，也就有了很多软件公司常有的其他岗位，比如售前/客服/实施/技术支持等，即使你不是最前线的服务人员，对产品业绩的负责，也要有服务思维。
[title]to B产品和to C产品的一些区别[/title]
以下详述的框架一部分借用下某位大佬现有的框架
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端也是完成业务流程，但是更关注数据。你会发现很多客户切换软件都要把之前软件里的数据导入到新软件里，方便分析对比软件。但是业务产生数据，所以在产品设计上，也要遵守，先实现业务逻辑收集数据，再做数据加工。
[title]to B产品对产品经理的要求[/title]
1、产品布局，这可以说是所有产品都应该思考的，但是很少产品经理有这大局观，更多的是执行，毕竟没有把产品当成自己孩子，也就不会为自己的孩子考虑未来发展。产品布局是个长远的计划，我们需要知道产品处于哪个阶段，处于哪个区间，上下级区间是什么，因为最后一定是要做平台化和一体化的。另外，to B产品都有个业务–数据–决策的过程，整个产品的迭代开发也要按照这个思路，也就是有了业务基础才会产品数据，有了数据，才会产生更高的价值。
2、调性。就是所谓的产品价值观，所有的产品由产品经理一手设计的，都会有产品经理本身的基调，也应该有，这是体现产品和人融合。
3、服务意识，前面好像提过了
4、对称交叉的产品技能。需要需求/商业/体验/技术交叉集成的技能。按理来说是所有产品所有掌握的技能，只是在to B产品里尤为突出，综合能力，因为客户+开发+市场+追求，很多因素促使你需要关注方方面面。
产品阶段
1、MVP阶段。MVP是最小可行化产品，其实就是做核心功能，这阶段的特点是敏捷开发，根据用户反馈，迅速响应，快速迭代，不断增补功能。这期间也需要做一些客户的成功故事，来为后面的增长阶段做案例准备。
2、增长阶段，实现客户增长。也就是当完全基础功能后，就要实现用户量的增长，来证明产品方向和产品价值。这阶段的特点是注重客户粘性，减少客户流失，同时产品在不断打磨。
3、变现阶段，实现商业变现。这也是to B产品必经之路，没有变现的产品是失败的产品。这阶段的特点是形成需求——产品实现——数据验证，数据验证驱动生成新需求的良性循环。
[title]to B需求设计[/title]
重构
- 1、首先整理产品现有的各觉得的业务流程
- 2、再根据现有业务流程增删改查，重新整理出优化后的流程，这就是一个解构和重构的过程
- 3、之后就开始按照模块的原型设计
- 4、最后一点也很重要，给老板画大饼，让他投入资源支持你。
需求梳理框架
- 1、用户。定义用户，有些公司自己的后台系统，可能就是业务部门/老板，像ERP系统，用户就是各个企业员工。
- 2、场景。关注现在线下是怎么操作的，再想怎么转到线上系统化。并将客户需求拆分成很多小问题，穷举可能的场景。当时要注意客户的要求不是需求。
- 3、路径。各个角色的业务流程
定制需求
- 1、前期充分调研此VIP客户，在会议洽谈前列列举想问的list
- 2、多次会议沟通，每次会议都要有记录
- 3、整理成开发文档，需要减少开发量
- 4、需求变更也是常有，但是要发all
[title]产品经理沟通[/title]
首先，沟通要分人群，应对不同的人群，沟通的方式肯定就不一样，刚刚用平常对小伙伴的说话方式跟老大沟通，就被喷了》。。产品经理平常沟通中需要沟通的对象很多，毕竟一天可能大部分工作都在沟通，简单按照角色分个类，老板、直属领导、开发、设计、运营、客服、跨部门、客户、对外。下面着重讲下对领导、跨部门和对开发的沟通。
对老板和对直属领导
基本所有创业公司或者稍大一点的公司最大的产品经理就是老板吧。但是的确跟老板沟通的机会不多，可能每次沟通都是开评审会。平常老板可能就是直接指出你的错误，你去改就行了。但是一定要建立老板对你的信任，也就是提升自己的存在感，免得改个东西都不告诉你，那不是尴尬么。那直属领导跟老板还是有很多本质区别的，直属领导每天都面对，真的是工作伙伴，坦诚交流，可能会有一些摩擦争议，但是就事论事。经常有个问题是领导想做的不靠谱，产品经理估计都有点傲气，觉得自己想的就是对的。但是领导想的就是不靠谱的么，面对一个靠谱的领导做的一些你觉得不靠谱的决定，我们更多要确定是否真的不靠谱，因为很多时候我们没有领导那个层次的远见，没有站在领导的立场上思考，比如这个需求你看着价值不大，但是却是为了以后做铺垫，或者说你的业务理解还没有他理解的深等。当然可以一起坐下来评估一个需求从用户场景、用户数据、开发成本多角度考虑下，不仅仅单一角度或者是凭感觉，可能你会有新的理解。另外要看你有没有其他方案，你一味拒绝领导的方案还不如拿出另一个可行的方案出来力证。
对开发
经常有说开发和产品是死对头，经常撕逼。多从自身角度来看，有些地方做到位了就能减少很多撕逼。当然最好是开发就是我哥们，即使是女生产品经理也可以交开发哥们哈，的确很受用。
1、大度。这个真的要有，心态要好，不要觉得自己高高在上，怎么开发业务都不懂，问的都是傻逼问题，测试老是纠着细节逮着你。要知道撕逼解决不了问题，你赢了，开发还是觉得不信服；开发赢了，说需求这么不明确是不是给我挖坑。
2、明确需求。应该说80%的沟通都是因为需求不明确，但是需求的确不能完全明确，即使产品经理做到了完全明确（理想状态），开发理解也肯定会有偏差，所以沟通是必须的。但是作为产品经理的确还是要尽量明确需求，不能因为说忙着别的事情对需求思考深度不深，广度不广，导致对需求不明确。当然明确需求还分一些表达不明确，一些思考不全面。表达的就不多说了，语文水平需要提升。需求明确需要不停留在表面（明确数据的默认值、明确数据的边界值、明确数据的异常等），帮开发考虑的更多，多想想实现逻辑，即使不写代码；将多层次的主题进行分离，碰到复杂的逻辑，拆解成多个模块模块，理好模块之间的层次关系，其实就是复杂事情简单化；将所有事物相关联起来，这个就是考虑全面，有的逻辑不仅仅影响本身，牵一发动全身，要找到关联；整合主体寻找答案，就是要有大局观，眼光不仅仅局限于这个功能，还要站在更高的角度，比如整个模块，整个产品，整个系统，会给你一些新的思路，有些可能就没那么重要没必要太纠结了；将想法变为观点，就是思考清楚表达明确，不要含糊其辞，想法成熟后才成为观点，并且要对你的观点要信心。
3、讲产品故事。所有的开发都乐意听产品故事，从用户、场景、需求，开发人员开发一个功能，也不仅仅是做出来，他们也想这个功能能帮到客户，真正实现用户需求。也可以让开发人员对需求内容更了解透彻，减少后面重复沟通的次数。
4、讲自己故事。这点也比较受用，其实就是诉苦，告诉他们你为此多努力，他们就会给予必要的尊重。
5、提前私下确定。这点尤其适用开评审会前，先跟对应的开发小兵确定一遍你的思路，避免一些大方向的问题，导致评审会开不下去，或者纠正一些小错误、弥补一些逻辑。也可以让开发私下更了解需求内容，评审会也会更顺畅。
6、跟大牛沟通。很多大牛的确有些难以沟通，首先你可能都会有些自卑，觉得这问题会不会傻了，让大牛觉得你很不专业，评审会会不会被大牛喷。当然大牛都很忙，你不要在人家忙的时候去找，请注意时间交叉。也千万不要问第二遍，大牛普遍没有耐心，就算耐心也不想回答你第二遍问题。然后其实我觉得很适用的是你可以先问小兵，确定方向， 并再多了解一些信息，再找大牛沟通。另外也别怂，要有底气，要看法也要敢于提出来。
跨部门
跨部门沟通的确很累，驱动别的部门配合来一起做一件事情，要看双方的时间安排，可能我们有时间的时候人家没时间，即使时间凑在一起，大家也不是完整的就在做这一个项目，一般都是多个项目并行，所以跨部门沟通产品经理首先要协同时间组织开始，可能是一个项目也可能只是一个小交流。跨部门最主要的问题是职责不明确，每个人只了解自己负责的部分，那此时产品经理就需要主动去了解对方业务，要做到熟悉整个链路，而不是像开发一样只熟悉自己负责的业务。当发生问题，职责不明确的时候出来协调，保证有序进行，但是不要万事就找对方领导，当然实在不行只能找对方领导处理了，可能有时候还需要主动知会对方领导。另外跨部门追求结果，要不断追踪落地情况，避免没人跟踪停滞不前。
沟通技巧
当然，不管跟谁沟通都要讲究技巧，提升沟通效率，体现你的专业度。
1、一定要提升个人影响力，塑造个人品牌。不管是工作和生活，都要注意自己的形象塑造。你会发现当你塑造出自己的品牌后，也就是信任你，做起事情来对方就会更配合，事情流转就会更顺畅。
2、不要浮于表面，专注核心问题，直接给答案而不是问问题。
3、还有一个沟通中理解思考回复的心理过程，就是辨别问题点—自我思考—快速架构一个想法—精准直奔主题。快速理解别人的观点，定位问题，然后利用现有知识库快速思考，架构出这个问题的一个解决方案，然后精准表达出自己的想法。但是这个心理过程每个环节都很难难度哈，也就是所谓的理解能力、自我思考能力、反应速度、表达能力。
That’s all.
文：任无忧/任性的产品仟（i-product）
首席增长官CGO荐读产品运营：
更多精彩，关注：增长黑客（GrowthHK.cn）
增长黑客（Growth Hacker）是依靠技术和数据来达成各种营销目标的新型团队角色。从单线思维者时常忽略的角度和高度，梳理整合产品发展的因素，实现低成本甚至零成本带来的有效增长…
本文经授权发布，不代表增长黑客立场，如若转载，请注明出处：https://www.growthhk.cn/cgo/product/14801.html
微信扫一扫 
支付宝扫一扫 
