浅析：B2B端产品的设计理念如何落地一个需求？
为什么B端的需求这么难做？（1）产品架构复杂，功能庞大 往往B端系统数据结构比较复杂，而事故严重度又比较高，对产品经理考虑的严谨性要求比较高 （2）用户思维和客户思维的转化更难 往往产品经理刚入门的时候，会去在意用户的体验性，考虑交互、样式和用户心理；但是到了B端，价值 》流程 》体验，如果过分考虑体验，那么就本末倒置了。B端的业务，产品经理很难站在用户的立场思考问题，因为你很可能不是这个场景下的使用者。 （3）难以深入理解业务和市场 如果B端的产品经理不能深入理解业务和市场，在你聊需求的时候，你可能跟客户都是牛头不对马嘴。B端产品经理对自己的要求，永远是要比客户更加懂业务！ （4）客户角色多，需求描述不清 客户角色多元，需求提出方可能并不是系统的使用者。管理者提出的需求可能会干扰需求的优先级决策；很多B端产品经理无法区分关键角色，从而对需求的本质判断不正确 是不是所有的需求都值得做？其实今天想讨论的并不是需求值不值得做的问题，这个问题大到足够再写一篇《B端产品系统如何规划》。 但是并不是所有提出的产品需求都需要去做，或者说需要马上去做的。举个产品社区经常讨论的问题：拼多多是否应该去做购物车？ 讨论价值的时候，我们需要不断的反问几个问题。
需求的价值 暂时把它称为提问法，我觉得产品经理在讨论需求价值的时候，一定要有问到底的精神，等一层一层揭开后，答案就很明显了。 拼多多可以不做购物车，因为购物车的价值在于给予用户思考周期和囤货的选择，而拼多多的商业模式是以商品聚人，打造拼团的紧迫模式，用户的思考周期越短越好。就算不做购物车，拼团的主流程仍然正常进行，所以商业模式决定拼多多目前可以不做购物车。 确定要做一个需求之后，我要做什么？我拿一个小需求举个例子。曾经听过团队中的新人产品经理与客户沟通需求，需求的大概是做一个停车场的访客车辆管理系统，我们的产品经理“便秘”式地跟客户了解需求，想到一个问一个，双方沟通非常的累。
类似这样的对话，一直在上演着。 B端产品设计步骤
（1）明确使用场景 遇到上述场景的时候，其实是没去思考场景。 就访客车的需求，我们先理一下，什么时候会用到访客车辆管理功能。
（2）确定核心价值 核心价值：做一件事的根本需求，核心目的。 我们之所以先去不断推演功能的使用场景，是希望能从使用场景中得到功能的核心需求。 比如我们发现上述场景中，访客车辆管理最重要的目的是减少/取代停车场保安登记车辆信息的需求。想的再全面点，就是车辆信息的登记管理、进出记录统计、异常处理（车辆停放问题，紧急需要联系访客车主）。 而不是访谈中关心的免费、收费功能。 （3）参与角色、端、子业务 我们在上一篇文章中已经聊过角色、端和子业务了，现在我们看看怎么把他们带入我们的产品设计。 参与角色：访客管理可能涉及到的角色有：业主（拜访对象）、物业（设置访客权限的人）、访客（有访客需求的人）、保安/收费员（登记核实的人）。 产品设计到的端：按照不同角色，对应到系统不同的端。物业需要在管理后台设置权限（PC），业主和访客可以在用户端（H5或小程序）、保安/收费员智慧收费终端（移动端或PC）。 涉及到的子业务 ：
子业务是越全面越好 （4）流程与异常 已经明确了功能设计的角色、端和子业务，在画图之前还有一部必不可少的工作：理流程。 之所以要强调必不可少的原因是，我发现越来越多的产品经理不愿意或者不会这一步了，其实与C端不同的是，B端太重业务，业务的复杂度决定我们是绕不开流程图的。 举一个访客自助登记的流程作为例子：
主流程
流程图（泳道） 流程图要点：
（5）信息结构图 看产品群里很多刚入群的新手总是提问信息结构图是什么，大家还是简单一点理解，就是按页面为单位，把页面上的元素都列出来。 我觉得产品结构图是必要的，2个原因：
（编辑：通辽站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
