前段时间刚看完杨堃老师写的《决胜B端——产品经理升级之路》，让我这野路子出身的B端产品经理，产生了新的认知。如果你也打算投身B端，我建议你可以看下，看完后，说不定你就想放弃了呢。
一本书看完后，还能剩下什么？脑子里记住的是知识点还是概念？我认为这都不重要，重要的是它能够带给我们什么样的启发。
下面就来说说我自己的感悟。
01
B端和C端，真的不一样
首先我们需要明确一点的就是，C端的那些套路很多并不适用于B端。所以如果想从C端转B端，你至少需要知道下面这些。
竞品分析层面：C端更多的是通过体验、研究竞品就可以；B端更多的是要了解每个企业的实际状况。
需求分析层面：C端重视的是人性、心理的把握；B端重视的是实际业务过程中的痛点。
产品设计层面：C端重视的是前台的视觉、交互、用户体验层面；B端重视的是后台的逻辑处理、业务流程层面。
研发推进层面：C端只需满足核心痛点，不断迭代升级；B端要满足最小闭环和可用性，每次升级都需要兼顾以前。
当然了，做产品的方法论都是一样的，只是在方向上有所侧重。做B端，从转变观念开始。
02
架构是必备技能
在这之前，关于产品架构的掌握，像我这样的执行产品经理，是不会过多参与的。但在实际过程中，我们又没法忽视架构的重要性。
我们做B端产品的，其实更多的是提供一整套解决方案，那了解企业的现有框架就是第一步。
以我们之前所做的数据中台来说，前期我们就需要对企业的情况进行摸底。包括企业的现有业务如何、都有哪些模块构成、数据收集是否完备、数据结构是否科学，数据抽取是否方便等等。
这个过程，其实就是分析每家公司架构的过程。这个工作，有些公司是架构师完成，有些公司是项目经理完成，有些公司是销售完成，有些公司是产品经理完成。
我个人觉得，作为产品经理，无论是不是我们来做这个事，我们至少都需要知道这个架构，这样能够提升后续我们产品设计的效率。
当然了，架构的搭建不是一蹴而就的，不同阶段会有不同的战略，不同的战略就会有相应的调整。
没有最好的架构，只有彼时彼刻最适合的架构。
03
懂一点技术，还是挺好的
关于产品经理到底要不要懂技术，这个争论一直都在，只不过一直有两种不同的声音。
产品经理懂技术：在产品设计的时候，会过多的考虑产品实现难度问题，而忽略产品的功能性。
产品经理不懂技术：在和开发沟通的时候，容易被忽悠。
以我个人的经验来看，上面两种情况都是非常极端的。我个人就是不懂技术的，在和开发沟通的时候，也没有被忽悠。我身边也有懂技术的产品，他们设计的产品，在易用性上也完全没问题。
只不过，如果产品经理懂技术，最起码可以和开发在同一个频道进行沟通。
还记得我之前在做一个定时发送短信功能的时候，我是从用户的角度来解释，开发则是从技术的角度来解释，结果是沟通了10分钟，我完全听不懂对方说的是什么，最后我只能说“我要的就是这样的效果，你怎么实现我不管”。
现在想想，如果我能懂一点开发思维，是不是就不用这么费劲了。
所以，产品经理要不要懂技术？如果能懂，那肯定是加分项。如果真不懂，那就把问题想简单点吧。
04
个性和共性是难题
做B端产品，我相信都会遇到企业个性化需求的情况。做还是不做，这是个问题，而且还是个难题。
在企业数量不多，需求不难实现的时候，我们按照客户要的做就完了。
可随着企业数量越来愈多，需求实现越难越难，甚至各家企业的需求存在矛盾的情况下，如何权衡就成了最大的问题。
个性需求，如果更深一步探究，多问问其他企业，也许就可以提升为共性需求。
举个例子，有个客户提出的原始需求是“下单页面的字段太少，我要加如下几个字段……”。这看似个性的需求，我们深挖下去，这个需求就是“我希望可以自定义下单页面的字段”。
解决了个性需求如何满足，那如果需求是冲突的，又该怎么解决呢？
请看下面的例子，也是我们实际遇到过的。
客户A：师傅上门后，不允许用户取消订单；
客户B：师傅上门后，允许用户取消订单，但是需要扣除上门费；
客户C：师傅上门，允许用户取消订单，并且不扣除上门费。
在刚接到这样的需求的时候，我们花了很多时间来讨论，考虑到以后还会有其他客户提类似的需求。我们最后的方案是：将这些内容做成可配置项，让用户自己去选择。
看似个性的需求，其实背后都隐藏着更大的共性需求，等待着我们去挖掘。
一些想说的话
对我这样的野路子产品经理来说，掌握方法论一直是心里的一道坎。
有些套路，我们只知道要这么做，但不知道为什么这么做。而市面上绝大多数的书籍和培训都是关于C端的，B端的真是凤毛麟角。
如果当初年少的我，能够早一点懂得这些道理，现在是不是能够做的更好？
尾巴
B端不易，且行且珍惜