3个方面聊聊：ToB产品经理的“修炼功法”

　　笔者是一名ToB的产品经理，入行以来负责过OA、HR、财务等业务。在此，浅谈三点ToB产品经理的工作方法“修炼功法”，和大家分享。
　　一、表象与本质
　　无论是ToC产品经理还是ToB产品经理，我们都需要通过用户提到的业务还原出用户的使用场景，从而把握到需求的本质，这就是我所说的通过“表象”挖掘“本质”。
　　而ToC产品经理往往比较容易成为自身产品的用户，比如：滴滴的产品经理会用滴滴来打车，可以从用户的角度去把握需求的本质；但ToB的产品经理有时候就不一定是自身产品的用户了，比如：曾策划过HR、财务功能的我，就不是人事专员、出纳或者会计。
　　那么ToB的产品经理怎样可以更好通过“表象”把握“本质”呢，我认为比较有效果的两个方法如下：
　　1。善于追问用户
　　用户想吃榴莲，那么“想吃榴莲”这件事就是表象。我们要追问用户“你是不是饿了”，用户回“是的”，那么“用户饿了需要饱腹”就是本质。
　　这个时候，我们就需要思考“榴莲真的能饱腹吗”，而生活常识告诉我们“榴莲吃完很快会饿，饱腹效果一般”；接着，我们进一步思考“有什么可以代替榴莲的而且饱腹效果比较好，又成本比较低的食物”，我们想起了面包。
　　然后继续追问用户“那你能接受面包吗”，用户回“可以接受”。对于用户而言，面包比榴莲更能饱腹，面包更满足用户的需求。对于软件服务商的我们而言，榴莲需要几十块钱甚至上百块钱，而面包只要几块钱；我们提供面包，可以更低成本实现用户的需求，从而创造更大的利润空间。
　　所以，通过“想吃榴莲”表象，我们提供了“面包”这个更能满足用户本质需求的解决方案，最后软件服务商和用户皆大欢喜，实现了双赢。
　　2。成为你所策划的功能的职能人员
　　刚接手财务需求的时候，理工科出身又没有从事过财务工作的我问身边的同事“为什么凭证要借贷平衡”，然后我被狠狠嘲笑了一番。于是我决定自学财务知识，以及试着体验财务人员的工作。
　　比如：财务人员耗时比较长的工作“录凭证”，我体验到了手工录凭证的低效。参考excel、word等办公软件，我们知道快捷键能一定程度提高我们办公效率，然后我们丰富了录凭证的快捷键功能，尽可能覆盖到财务人员通过快捷键更快录入凭证的各个使用场景。
　　但是，在提倡“自动化办公”的时代，手工录入凭证的效率还是太低了，我们有没有可能更进一步提高生成凭证的效率呢。于是我们策划了“业务自动凭证”，通过业务单据自动生成凭证，进一步解放财务人员。
　　对于ToB的产品，我们的价值之一就在于通过提高员工工作效率更好降低企业人力成本。而体验职能人员的工作，我们能理解工作中繁琐耗时的地方，然后我们去解决。
　　二、通用性与个性化
　　ToB产品拥有比较多样的用户群：按照企业规模划分，可以分为大型企业、中型企业、小型企业、微型企业等；按照行业划分，可以分为制造行业、餐饮行业、金融行业、软件行业等。而用户群的多样性，就意味着客户业务的多样性。
　　如果我们根据每个企业的个性化使用场景单独开发，那么我们的开发成本是非常高的，我们的BOSS是不可能同意我们这样处理的。因此我们需要从业务的多样性抽象出需求的通用性，同时满足各个企业的个性化使用场景。
　　比如：我之前策划HR功能，关于“超过假期余额之后，员工能不能请假”这个小点，一些管理比较严格的公司要求“超过假期余额之后，员工用完目前的假期额度了，就不能发起请假”，而一些管理比较宽松的公司则允许“超过额度之后，员工可以请假”。
　　因此，我策划了假期余额控制强度设置，分为“不能请假”和“预警提醒”。管理比较严格的公司，他们可以设置“不能请假”这个控制强度，他们员工用完假期额度之后就不能发起对应假期类型的请假审批。
　　而管理比较宽松的公司则设置“预警提醒”这个控制强度，当员工用完假期额度之后发起请假审批，负责审核的上级或者人事专员点击“审核”按钮的时候，系统弹窗提醒审核人“该员工假期额度已用完，是否继续同意”，他们了解该员工的特殊情况之后依然可以同意该请假审批。
　　通用性和个性化并不是完全矛盾的，我们能抽象各个企业的个性化需求为通用性需求。同时作为SAAS领域ToB产品，我们所强调的个性化配置，一定是可视化配置的，用户能直接根据企业管理情况设置，而不是软件服务商用代码特殊处理的。
　　只有这样子，我们的产品才具有真正的通用性，满足更多的企业使用场景。而当同一个功能被更多企业使用之后，根据边际效应，分摊到单一企业的研发成本也自然会下降。目前ToB企业都在尽可能平衡“通用性及个性化”，在提高收入的情况下控制成本的快速增加，从而创造盈利的可能。
　　三、一步到位与快速迭代
　　企业付费了几十万或者几百万，都希望一步到位享受到合同所签订的所有软件服务。而理想是丰满的，现实是骨感的，现实中会因为“客户上线时间提前”、“软件服务商研发资源不足延期”等原因，我们没有办法实现一步到位交付所有功能。
　　比如：我今年担任一个餐饮项目的项目经理兼产品经理，客户因为该餐饮行业季节性变化的原因会有“旺季”和“淡季”，客户必须赶在“旺季”到来之前上线才能实现更好的盈利，同时客户旗下门店非常多，从而导致整体按时交付压力很大。
　　我们决定采用敏捷开发的方式，先上线不影响客户营业的功能，再上线优化点。于是，我到客户公司调研，挖掘客户的业务流程，从做售货单到生成营业报表，形成一个闭环，这就是最小可用产品MVP。
　　那么我们必须一步到位上线售货单及营业报表等功能，只上线一部分，客户是用不起来的。等上线之后，客户正常使用了，我们再打通收银机，做到系统自动生成售货单，从而迭代产品进而提高员工工作效率，获得客户的认可。
　　我们需要一步到位最小可用产品MVP，满足客户正常的业务操作，同时快速迭代进一步优化操作体验，提高客户满意度。
　　最后，产品是需求、设计、开发等职能人员基于客户的需求而达成一致意见的最终产物。需求的来源是客户，我们必须充分和客户沟通，掌握一定的方法论从而和客户达成双赢的方案。
　　关于ToB产品经理更多的“修炼方法”，我会继续总结然后和各位同行分享，本文如有不正之处，也欢迎各位指教。