做To B产品时，会接到很多利益相关方的需求，如果没有深入调研用户，做出的产品往往差强人意。那么在做产品时，我们遇到了哪些问题呢？
1、做决定的是高管，而不是用户
为产品买单是公司老板，他们会从追求效率和追求投入产出比方面去要求产品，而实际使用者的基层员工考虑的是用户体验，领导不会了解员工在具体工作中遇到的痛点，但决策权在领导手中，这种矛盾的存在，会让我们在To B产品的设计中偏离目标用户，为老板而设计。
另外，设计公司的Boss也会影响设计。之前参加过腾讯优测的线下沙龙，讨论的时候，问产品经理是否会做用户调研，某位产品经理提到，公司很多需求来自领导，时间紧迫的情况下，领导让干啥，就着手做啥了。这种现象也很普遍，重大决议来自高管，产品都在围绕着高管的想法开展。还记得《虎妈猫爸》中，罗素带领的游戏团队遇到决策问题，意见双方针对未来的方向争执不已，另罗素很头疼。胜男的话提醒了他，不忘初心，最终的解决方案是做市场调研，让用户和数据说话。
2、没有获得用户的真实需求
每到晚上8点，女儿总会喊：“妈妈，我想喝奶！。”一直以为“喝奶粉”是女儿的真实需求，直到有一天，女儿想喝奶粉的时候，我说：“妈妈买了面包，很香，吃点面包吧。”女儿答应了，吃得津津有味。突然意识到女儿不是真的想喝奶粉，而是饿了。小孩子不会说饿，什么解决了她的问题，她就要什么，思及用户，用户也不知道有什么好的解决方法，只能按当前的经验和观点去理解，这也是为啥会有“更快的马”的回答，所以在做需求时，要多问几个“为什么”，深挖用户背后的目标和动机！
另外，还要考虑公司的规定。例如，做资金计划系统时，访谈提报者什么时候完成资金计划时，回答很不一致，上午的、下午的、晚上的，总体上提前一天完成次日资金计划。这样我们在做时间限制的时候，很容易截止到前一天的24:00点。实际上公司有规定，次日计划提报时间截止到前一天的17:00点。为防止时间固定死，带来麻烦，此处可以考虑截止时间可系统设置。
3、需求不全面
To B产品会涉及到跨部门协作，部门人员只会从当前的工作职责角度去看待问题，如果只调研一个部门，难免管中窥豹。拿项目审批为例，调研了提报者、评审人、评审记录员。提报者会说我们完成风评报告，然后提交运营部过会评审。评审人会说我们需要依据提报者提交的材料，评审项目。评审记录员说，评审人都是公司高管，会上评审是常态，高管喜欢会上决议，不会到系统上做评审。那对于评审管理来说要考虑不同角色的需求，线上系统既满足风险评估报告的制作、必要资料的上传、提交项目，又要满足项目的评审。评审人是高管，高管是否喜欢线上操作，评审的终端是否有要求？对评审记录员来说，要完成线上评审的整个过程，评审结果是否需要文档备案呢？解答这些问题，都要清晰工作流程，并深度挖掘各个角色在事件中的职责。
4、业务多变，导致需求变化
公司业务重心是煤炭供应链金融服务，煤炭这种产品很特殊，很难标准化，随着时间、空间的变化，价值和形态也在变。在项目执行的过程中，也有很多变数，比如合同价格的变化；付款方式的变化；港口变化；货权转移；仓库的变化等等。另外，供应链金融服务的模式也在变化，由单一的仓单融资、代采和应收款融资延伸至复合模式，模式变化会影响后续的物流、结算、收付，在系统中如何处理这些变化呢？所有这些变化对系统的设计有一定的挑战性，更多的要考虑系统的延展性。
从最初的业务管理战略需求，到现在的金融服务平台，每一点需求变更，我们都会和业务部门沟通，了解业务的运作方式，处理方式，再研究对系统的影响，所以做To B产品，也是在考验业务的熟悉程度。
5、产品定位变化
产品都有一个既定的目标，为什么做，解决用户的哪些问题？带来哪些价值？最初规划金融项目管理系统时，仅针对内部用户使用，随着业务规模的扩张，上游客户、下游客户和金融机构都成为了潜在的用户，产品的定位也从原初的“管理项目”变为了“煤炭供应链服务平台”。在用户和定位改变的情况下，系统也在迭代和延展，这样造成的问题是系统维护成本高，另外为兼顾定制性和扩展性，往往来不及考虑用户体验。
在真实的场景下，我们遇到的困难会更多，为避免走过太多的坑，始终牢记MVP，产品轻量化，先解决主要业务痛点，再考虑是否所有的业务场景都能线上化。
网友评论