一晃，作了9个月的b端产品了，从最初满脸蒙蔽，到现在，感觉日子好快。做为一个曾经的c端移动端产品，天天跟人家掰扯用户体验，到现在，每天沉溺于流程中不可自拔，转变的自己都没想到的快。
不说废话了，啊哦，说说b端产品的我认为的那些重要的点吧，其实该先说说b端和c端的区别的，毕竟做了1年半的c端产品，但还是后续单开个帖子吧，又废话了，啊哦。
b端重流程，更多是逻辑上的东西，所以做b端，其实有些思维是有所谓的套路的。
1、who？
你做的产品是给谁的？b端更多面向企业的职能部门；是为谁做的？哪个部门的人在用，哪一撮人在用，譬如你做了一个客户管理系统，那么企业内有哪些部门要用么？这些要理清楚，首先销售一定要用，其次是销售审核，或者其他需要查看销售的职能部门，这时候，一个用例图就很有必要了，谁，在系统中需要做什么，都要写清楚，这个时候，要站在业务的角度去考虑实际场景，而不是系统该如何设计，考虑谁的时候，要考虑的是实际业务，系统是服务于业务的，不能天马行空去想。
2、what
有了部门角色，就要有实际的操作，谁在系统里面，需要做哪些操作，这个时候，可以画一个实际业务操作的流程图，譬如一个角色，新建一个合同，需要哪些人审批，这些人是什么角色，要完成这个操作，邮寄归档，等等。把一个人在系统里面的所有操作拆清楚。
3、生命周期
这个区别于c端产品的生命周期，b端的生命周期要看业务实体，譬如合同，从最初的创建，到最后的过期失效，经历了哪些步骤，每个步骤，都有哪些业务角色参与，每个角色做了哪些操作，这样整体去考虑，可以减少疏漏。
4、角色、权限、界面
每个b端产品，都有自己的操作角色，毋庸置疑，那么每个角色能看到哪些界面，是依据于他实际在业务中所要进行的操作，譬如一个销售助理，他在实际的业务中就是要给销售提交合同的，那么他的角色和操作权限，就是要考虑这个业务场景的，所以b端产品不是凭空出来的，要基于实际业务，但是不能被业务牵着走。
5、数据权限
每个角色在系统里面可以看到的数据范围是不同的，不是每个人都可以看到全部数据的，数据权限在b端系统是个很重要的东西，每个人能看到的数据要严格控制，作为一个销售a，是不应该可以看到b的数据的，否则就会存在数据泄漏的风险。
其实，主要要说的就是上面几点，只是一个思考方式，b端产品来源于实际的业务，但是不能完全按照业务来，更多的是，你要考虑，怎么更合理，需求来源于业务，但是不能被业务牵着走，所以，做我b端产品，企业的经营也是要学的，模式也是要学的，要更多的站在全流程的角度去考虑合理性，而不是只看眼前，不要为了做需求而做需求，也不要为了1%的场景而去放开99%的限制，多思考，多学，多问，如果连自己做的需求，是谁来用，业务背景是什么，现状如何，都弄不清楚，那就不要去浪费开发的资源了，做我pm，所有人都可以说，不是自己的锅，只有你不能，
