毫不客气的说，现在B端产品比C端产品好混多了！这里指的好混，并不是指业务的难易，而是指机会的多少。
B端产品与C端产品最明显的是在于业务形态的状态，你面向的核心需求天差地别，这就导致了B端的做事方法逻辑与C端是存在一定的差异的。
题目名为“啰嗦总比误解强”，是我在做B端产品的感悟。这里的啰嗦并不是真的指“无用多余的东西”，而是指在落地过程中，一些在C端看来很别扭的东西，在B端看来，是有用的。
本文会分享两点，聊下B端产品在工作时是如何“啰啰嗦嗦”的。
注释：对了，我是从一个入行2年的集团IT的角度出发去聊的，(｡･∀･)ﾉ
在需求沟通上
B端产品一般均为降本增效用，所以服务对象一般均为业务人员。这就导致了B端的需求较大一部分是来源于业务。
产品初进入B端领域后可能会不适应，这种不适应来源于不掌控。你以为你是来呼风唤雨的，但实际却感觉自己像是个需求接收器。
这就是明显的心态没转变而已。
首先，作为产品，其实很少会有机会深入市场去调研的，市场规律、作用方式、协同方式等都是业务熟悉的领域；
其次，顶层设计决定下层建筑，能提需求的业务一般都是业务负责人了。产品上线后，无论是教，还是用，都是麻烦着业务；
最后，业务部门通常是印钞机，而IT部门则是吞金兽，作为产品的你可能就是在喝着业务的血；
一个在前中后期帮你打辅助的金主爸爸，提需求实属正常！
注释：此外，作为一个1~3年的PM，是很难对产品的走向有自主权的
言归正传，为什么要在需求沟通上与业务“啰嗦”一点？
因为你需要将需求分析透彻，就需要了解业务的问题、期望和最终价值。
当拿到业务的SB后，你需要去鉴别是否足够清晰、完整。
我不是在骂人，SB全称为StoryBoard，即为用户故事背景板，里面需要包含为什么提出该需求，你期待如何解决，解决后对你有什么意义？
在得到完美的SB后，有些B端产品经理就直接拿去写需求文档，做方案去了。但如果不是小需求，我十分建议“啰嗦“一下，做多一步：输出细化方案。
所谓细化方案：可以理解为介于需求文档与原始需求的用于进一步确定的方案。
将你对于需求解决的流程、理念、方案用文本的形式呈现出来，并用它再于业务确认一次，确保脉络没风险。
其实很多人拿到原始需求后，是会进一步沟通调整的，只是这些动作并不会沉淀下来作为一个文档存在，觉得口头沟通更加有效率与便捷，但这其实非常不利于责任厘定以及确认交付的。
直白的说，这“啰嗦”的一步，增加了双方工作量的一步，是你不背锅的一步。
在产品设计上
原本做C端产品的时候，由于面向的是消费者，所以用户体验会放在一个较重的位置，这样留下的毛病就是：注重美学。
但B端不一样，“弄这么好看还不如好用点”、“你工期快点就行，不用那么好看”，“你这个我就不懂什么意思”。
无需精致，简单粗暴更适于B端法则。
这是一个优惠券设置页面，设置完门槛后，需要设置投放范围，而为了让业务更能理解不同条件的的意思，我在下方做了行文本提示。
消费者一次性下单所有指定商品，方可使用优惠券
这样看起来没啥毛病，但最后完成方案时，这个提示我加多了一句话：
消费者一次性下单所有指定商品，且达到消费门槛，方可使用优惠券
增加这一句话的作用目的在于减少业务的误解，虽然“啰嗦”了点，但有效。
可能举的例子不太恰当，但我想说明的是：在产品设计上，宁愿“啰里啰嗦”的提示到位，也不愿出现1%的误解。
什么是成功的B端产品？
重点在于为开发方带来收益，为使用方解决问题。
而产品体验、视觉呈现，只能作为第二级别的评判标准。
对于企业，好用比好看有用。
