世界太大了，大得我们对与世界的认知不断提高，焦虑感也会不断提高。降低焦虑的方式要么是不再去感知世界，活在自己的个人世界里；要么是提升自己，能够迎接更多的挑战和机会。我选择后者，你呢？也相信阶段性的总结和复盘对于个人的成长是有帮助的。
作为一个B端产品经理，踩了很多坑，总结了一些经验希望大家在做项目的时候能够绕过去。
具备可预见性的业务性的能力
你能够知道公司未来3-6个月的业务是什么，会有怎么样的变化？现有的产品是否能够支撑，如果不能够支撑还缺少什么？
有两个重点，一个是如何知道3-6个月后的业务，1、领导战略会后告知成员公司未来有什么业务计划，这种也是最常见的；2、经常和其他部门产品去唠唠嗑，聊聊大家最近的项目和未来的规划，这也是产品能够做的；3、如果有统筹的项目组PMO部门，一般PMO部门每日会有站会，站会是我们了解各端业务线最新的项目进展和规划的地方，大家务必能够参加就要参加，这样对于现有系统有哪些缺失的能够很明了，后续研发的压力也会少许多，大家都会轻松一点。不过有人可能会问，如果涉及到其他的部门的依赖性需求，其他部门的产品不应该告知我们吗？理论是是应该告知我们，但是后台系统极其复杂，很少有产品能够有视野和机会去了解各个系统，就算能够了解不同系统，也很难去深入系统的细节当中去，与其寄希望于其他产品给我们提业务支撑的需求，不如自己去跟进。
第二点，如何判断现有的产品是否能够支撑，这个需要产品对之前的产品逻辑非常的了解，当然这也是身为一个产品必须的，有几个小窍门能够帮助大家更好的去了解现有的产品。1、画出现有的产品的业务流程泳道图，清晰的知道产品逻辑依赖了哪几个系统；2、画出各个系统间的数据流转图，各个系统之间依赖的接口是如何走的，系统之间传了哪些字段，不同功能的规则依赖于哪个字段；以上两个方法能够清晰的帮助大家理出现有的产品逻辑，特别注意的一点是，如果有什么不知道可以问目前系统的研发同学，所以伺候好研发同学很重要，他们对你生气没耐心，我们也要阳光的微笑。
需求上尽量考虑灵活性和通用性
B端产品更偏重于业务支撑，即要满足高速变化的业务需求，所以对应的后端产品应该及时支撑业务，但是后端产品每次改动会涉及到多个子系统的关联，以及各种耦合和依赖，导致产品每次前进一部其实需要花费很大力气，那么产品的通用性和灵活性显得尤为重要，这样一个功能只用开发一次，而不是业务方每次提需求都得改，不停的改轻则导致整个项目组很疲惫；重则进度跟不上业务线的节奏，影响公司的业绩。
先说说灵活性，灵活性在业务层面意味着高度的配合业务的发展，在产品层面意味着可配置，即一个功能能够支撑业务方各种变态的要求。
比如也无妨说下个月为了冲刺业绩，优惠券功能能不能改下，优惠券有效期扩大到30天。产品经理听到这，先思考三个逻辑，为什么要做，有什么价值?现有的功能是否能够满足业务方的需求?以后是不是还会有类似的需求？如果答案一定是要做，有业务价值，且未来可能会多变，那么需求中最好将有效期变成一个可配置的变量，以防以后30天变回5天，5天变回20天。
通用性，则代表着产品经理对于业务的理解是否够透彻，对于规则的抽象是否合理以及正确，不能A场景一套规则，B场景一套规则，优秀的后台产品应该能够相处一套规则同时兼容A和B两套场景，则代表着产品的通用性。比如说如何评价一个用户对一件商品的需求程度，可以是加入了购物车代表有需求，也可以是购买代表知道有需求，也可以是搜索代表有需求。如果单拎出一个规则去做，是正确的，但是其实是描述的不同童工和准确，好的产品应该是能够描述一套通用的规则去判断，比如根据用户行为，不同的行为有不同的权重，这样 才是一个通用的可复用的规则。
用最小可行性产品去验证大功能
后台产品最忌产品大改，因为不知道会发生什么，依赖的系统实在是太多了最，可怕的会导致线上事故。所以比方说有个大功能大作，为了防止线上事故，以及考虑用户的习惯，可以遵循下C端产品的MVP概念，即做一个最小的可行性产品，功能不要太复杂，能实现一部分大功能能实现的价值就可以了，然后去看数据做验证，如果数据还OK，那后续可以继续在这之上进行迭代，这样线上事故的概率会小很多，用户的接受度会一级一级变高。否则上线了大功能，整个项目组的人吭哧吭哧做了一两个月，最后上线发现数据不行，用户也怨声载道，对于产品经理的压力就会非常大。
清楚数据的流转，才能够了解问题的本质
每个不同的后产品其实是不同业务的数据集合，比如说订单，订单在后台当中是由不同的字段组成，比如说：订单号、产品、价格、物流状态等，不同字段组成了一张叫order_list（订单表）的表。对应的，后台不同系统之间的，互其实是数据之间的交互，有数据的地方就有功能存在。比如业务方有一个需求是每个订单应当支持用户获取物流信息，那么首先考虑物流信息这些数据在哪，物流信息可能在物流系统里，然后再考虑我们需要给物流系统什么信息，物流信息传给我们什么信息，如此深入到系统底层，很多产品问题能直接看到本质，追溯到源头。
下图是某教务系统的数据流程图，一定注意的是，数据流程图一定关注外部实体，如教务人员和学生，外部实体是数据起始和结束的端点，也就是说，外部实体发起数据或最后接收数据。在设计功能时，要关注”端到端“的流程，从而树立一种大局观，防止自己陷入细节之中而跑偏。
用户体验重要吗？
后台产品用户体验重要吗，当然重要，但是不是优先级最高，优先实现功能为主，体验其次。所以后台产品一般不会配备UI，因为UI能产生的价值接近于0，因为后台产品普遍用户是企业内部人员，产品UI再难看，再难用，用户也必须要用。但是但是，如果产品太难用了，对于产品经理的咨询压力会比较大，业务人员会有各式各样的问题问你，一天别干活了，专门回答大家的问题吧。更深层次的问题是会导致人效降低，后台产品的目的之一就是为了提升人效。有人说可以培训啊，永远不要指望培训能够把所有的人都培训到位，能够良好的使用系统。
所以建议大家在后台产品的不同阶段去完善不同的内容。产品的初期，保障系统可用性即可，页面差点没关系，只要产品内的数据是准的就行。过了这段时间之后，数据足够准了，用户也能够清楚使用产品了，用户会自然而然开始提一些易用性方面的优化，所以后台产品也要对交互有些理解，当然也有些后台产品确实手残，可以参考下阿里的开源后台“ant design“的设计，不会做，抄总能抄得会，而且前端的样式都是有源码，前端同学直接拿去用就可以了。另外后台产品重逻辑，所以实现功能的大部分工作在后台工程师，不同的交互对于后台压力是不同的，他们会经常基于自己的实现立场给一些不同的交互建议，产品经理务必要有自己的产品感，即对未来的产品长什么样要有画面感，且对于易用性（效率）的的优化和后端的实现的成本要有一杆秤。
以上是自己关于如何做好一个B端产品的总结，欢迎指点纠正。
想要了解更多产品知识可以关注我的知乎：远川，也可以关注我的微信号公众号：产品小蜗牛，里面有一些我转载的认为还不错的文章以及我自己整理的一些方法论，希望能帮助到大家。
作者：远川，B端产品经理，科技男和文艺男结合体，白天工作，有灵感的晚上就码字，很喜欢深刻的东西，也很喜欢喝酒聊天，没事干的话就看看书、跑跑步和滑滑雪。
