应用场景：

产品转型、认知升级

参考观点：

#业务、流程#

• 专业类的业务逻辑比较难理解

• 当业务没规划，要进行产品规划，且自己定OKR，是痛苦的

• 如果不先理解所对应的整个业务，根本无从下手，一环扣一环

• 业务逻辑容易了解， 但是并没人能抓住核心业务，多数业务来自甲方，需求也未能把握，缺少B端的方法论，在做C端的时候会做一些需求列、 需求池等，但是自从做了B端，没怎么做这些，缺乏B端方法论理论知识与实际业务能力问题

• 各种角色流程要考虑清楚，比较繁琐

• 整体的页面样式，交互不是重点，更多的时间是花在了业务梳理上，权限问题要慎重考虑长远考虑，否则后面需要改的话会影响很多方面，研发用的时间也长

• 最重要梳理好功能流程和业务流程，要闭环。原型要说明白规则和事项，避免开发怼，适时的跟进开发的进度

• 我现在负责的是物联网方面的B端产品，不仅要考虑各个角色之间的业务流程，还要考虑到硬件传输数据原理，客户提出硬件方面的需求，一定要多问客户为什么要这么做，因为之前没有经验，没有考虑到硬件，前段时间做的需求都是错的，现在在亡羊补牢

• 业务复杂，环环相扣，最头疼的是不确定的时候动某一个功能其他功能也会涉及到变动

#需求#

• 不要只看用户说什么，要站在业务流程的角度看他们真正需要什么，只有自己把业务逻辑弄清楚才是王道

• 做B端产品时，需求不明确真的很痛苦，总是要一遍又一遍的修改，对于客户来说，做出来成品才知道符不符合自身的需求

• 老板看啥都有市场，导致产品一个接一个，根本来不及迭代已有产品

• 用户嘴里说的，跟他们做的真的是2回事，哪怕用户告诉你他希望怎么样，最后他还是按照自己的习惯来做事

• 面对单个客户需求，经常要考虑通用化解决方案。虽然方便其它客户也能使用，但导致有些功能，并不契合

• 即使是甲方领导私下聊的需求也要落实到邮件确认，不落实到文档，不确认的都可能被丢锅

• 接触不到直接的业务需求方

• B端需求繁多，今天要这个明天要那个，所以说每次会议一定要出会议纪要，并且双方确认过的，不然到时候背锅的还是你

• B端产品更像一个功能翻译机，需求传声筒

• 业务梳理和理解是必须的   根据客户需求必须每一次都有所创新 还要看客户 有些客户是真的…

• B端业务理解能力要强，同时要抽出需求反应实现的点，不然提一个需求做一个会导致产品项目化，而不是通用化

#沟通#

• 对外沟通能力需要很强，才能更好达到目的

• 职能部门间需要平衡项目利益，避免踢皮球。另外，由于是业务导向，技术部门在组织架构上虽然挂在各大职能部门同一层级，但业务人员经常性直接找到技术叽里呱啦，很是不爽，需要强有力的制度来规范、制约

• B端对逻辑能力和沟通能力的提升是很大的

#经验#

• 缺少行业经验与方法论

• 任何时候都不能停止思考

• 很难找到竞品参考，因为B端产品基本都属于定制产品，很少有公开的产品可以参考

• 目前做的医疗B端。B端比C端，更注重效率、逻辑，用尽可能短的路径实现功能。B端不像C端那么注重视觉交互，因为B端用户量少，会有培训，即使有些地方交互不合理，但更容易适应

• B端对界面要求并没有太高，用户体验不看重，只要重视效率。很多表格类的页面，研发自用复用

• B端钱多事少需求比较明确清晰（短期），C端钱少事多需求紊乱业务流错乱（长期）

#结果#

• 实际做出的产品，跟用户实际使用场景千差万别。

• 难的是做一个平衡的各种行业都能用的通用系统

总结：

一个人可以走得很快，一群人才能走的更远。 每个人有一句没一句的互动起来之后，真的领略到 众人拾柴火焰高 的道理，谢谢大家每天坚持一起成长。

业务上：需要熟悉业务，重业务逻辑，需要考虑全局，业务流程较繁锁，对专业知识要求高，需要多了解行业知识

需求上：前期最好做好用户画像，要对用户足够熟悉。需考虑多样化场景，避免需求只能单方面客户使用

沟通上：内外部都要做好沟通，避免内部背锅，外部耍赖，工作流程上讲究协同，最好要闭环。原型要说明白规则和事项，避免开发怼，适时的跟进开发的进度