《决胜B端》读后感
大概是在18年左右的时候知道有这本书，当时在一家教育公司就职，跟这本书的作者所在的公司一定程度上算是竞对。也算是阴差阳错了解到作者。后来由于个人职业转型，干了三年多的教育产品后转型到电商产品，tob的方向。于是乎，开始恶补B端相关的产品知识。以前看堃哥公众号文章，感觉还是比较晦涩的，一方面是因为有很多专业术语，另一方面自己接触B端仍是浮于表面。但这本书相对来说就好很多，比较通俗易懂。拖延症下看了下来，总体感觉还是有点收获的。接下来就简单分享一下我在阅读过程里的体会和收获吧。
01
B端产品和后台产品
以前粗浅的主观认为B端产品和后台产品是同一个东西，也没有细究这两者之间有什么区别。然而细品之后，发现差异还是蛮大的。
一般来说B端产品的定义是为企业提供服务或解决业务问题的产品形态，其对象是企业、组织。自身通常是一套完整架构的系统，比如CRM系统、OA系统、仓配系统等。
而后台产品，更偏向是对产品体系的层次划分。从名词上也不难发现，后台称呼的出现，意味着一定有一个前台产品形态。后台是为前台产品提供基础服务或支持的产品形态。比如电商的订单系统，为前端的支付业务提供服务。
其实上述的定义区分，仍然是比较简单和宽泛的区别描述。除此之外，也还有很多其他泛B端的产品形态，比如SaaS，ERP等更重商业属性的产品形态。
总结一下：不论哪种产品形态，需要注意的是，对产品形态的边界有一定的了解，然后在进入这个领域进行产品设计的时候，尽可能去熟悉和掌握这种产品形态和其他形态的异同点。毕竟在实战过程中，能用他山之石攻玉也不失为一种避坑的好办法。
02
B端产品建设指标
堃哥给出了很完整的B端产品建设方法论。从发现问题-->方案设计-->执行优化 完整的闭环，可谓是非常之详细。其实对于产品新人或者发展瓶颈期的产品人，还是比较需要这样有实践参考意义的方法论的。尤其对于一个0到1建设的项目。可以帮助厘清思路，快速启动。
然而，我想对于大部分人来说，完整经历一个项目的机会并不多，很多时候是在已经有的系统上进行产品迭代。这时候，不是不会做事情，而是越做越茫然。当然这跟没有大型实战成功经历是有一定关系的。不知道自己这样设计好还是不好，常常会给自己造成困扰。这时候有人可能会说，可以用数据，用指标衡量。关于这点，杨老师也有单独在公号文章中提到B端产品很难定义效果。比如基础服务的产品，如果在中台系统里，可以用接入的系统数来作为考核指标，因为基础服务存在的意义就是为其他系统赋能。再比如SaaS产品，最直接的应该是转化和续费指标，因为这能直接带来商业效益。其次可以从功能模块PV,UV,NPS 等使用和满意度指标中去考量产品的合格与否。
03
B端产品建设实践
背景：
今年双十一期间，供应商端出现了一个较为严重的问题，用户在后台发布商品时，类目下的各种属性为空，导致无法发布商品。换句话说，商家无法通过后台功能上款，可见这是多严重的问题。究其原因是类目下属性内容均从TB接口获取，TB由于双十一对部分接口进行了限流，才导致这个问题。说来也是惨烈，这么底层的基建，核心业务的信息都依赖于三方平台。可谓是将命运的咽喉，交于他人之手。
过程：
由于项目已经发展了相当一段时间了，大刀阔斧改动势必会对核心业务产生影响，存在较高的风险。所以这次采用的方案是两步走，先单独搭建一个类目库，再由这个基础库去支撑其他核心业务场景。梳理业务的时候，按照低耦合的思路，把类目、属性、规格区分成单独三个模块进行设计，再分别在属性、规格中关联到某一个具体类目。这里就用到了ER建模的方法，类目、属性、规格之间的关系，其实还是蛮好分析的。一个类目下可以有多个属性和规格，每个属性也可以在不同的类目下存在。比如男装T恤下有品牌、面料等属性，同样的女装T恤也会有相同的属性，甚至是更多一些的属性值。于是输出如下关系图。基于这个模型结构，再去设计表单页就会觉得比较得心应手了。
当然，其中也是有一些细节要提前考虑的，比如同一个属性/规格在不同类目下如何区分；比如同一个属性下的属性值数量过多如何处理。这些都是后续需要注意的点。
后续：
项目启动后，便开始了日常的项目跟进环节。产品侧当然在启动前就预先想到，底层类目搭建完之后的应用场景。首先当然是对于发布商品的改版优化，接入本地搭建的类目库，属性以及规格，不仅可以方便运营同学进行类目/属性管理，同时不仅仅局限于单一的服装品类，支持向其他行业伸出业务的触角，并且用同一套底层来兼容。其次，商品类目本地化之后，为前台的商品搜索提供了新维度，给搜索关键词和类目词/属性词/规格词进行制定匹配规则，一定程度上也能提升搜索匹配准确率，摆脱了单纯依赖商品标题进行搜索匹配的现状。
总结一下
B端产品相较于C端而言，确实更依赖于对软件设计原则的了解和掌握，甚至对于软件架构设计的要求是比较高的。俗话说没有吃过猪，难道没见过猪跑吗。做B端产品确实还真是不吃过猪肉，不知道猪肉有哪些做法和吃法。不同做法必然导致不同的使（食）用体验。从B端产品可行性和扩展性角度来看，在下厨前就熟知做法是必要的，毕竟前期架构是否合理会对后期产品建设产生决定性作用。Anyway，作为初入B端的我来说，深知还有很长的路要走，但是所幸已经在路上！与各位共勉！