新闻动态
NEWS CENTER
NEWS CENTER
2020-04-13
首先强调一点，SaaS 产品服务的是购买决策人。
因为很简单，他们才是购买 SaaS 产品客户，而那些一线的执行人员，并非决策人员，优先满足他们不会带来任何商业价值。
因此从客户企业和自身公司考虑，产品经理首先要判断决策人是谁，以他作为中心向四周发散来解决问题。
但要注意，这里并不是说忽略使用者的体验，而是要想办法做到平衡。
举个例子：
某企业区域负责人会要求督导巡检上报执行结果，可以理解为写日报的这种方式。
但实际上，有的督导一天会巡检多家门店，也就是他们会巡检完成一家门店，写报告然后提交，然后再巡检下一家门店。
那么对于这个问题，你会如何解决呢？
最简单的方式就是做个写日报的功能，然后让督导每日完成即可。
实际上你可以想象，这个功能上线后一定会增加他们的工作量，导致巡检的降效，执行人员的抱怨。
而如果从业务场景和问题的角度去分析，我只要让上级负责人能够看到执行结果即可。
因此对于这个需求，最后的解决方案是在 PC 端选择任务抄送人，完成后抄送人会收到报告和数据统计的结果。
这样区域负责人不仅可以选择性的查看，同时督导也不需要每天写巡店报告。
SaaS 产品需要按照业务流程排列需求优先级，在「02 知彼，判断需求的价值」中已经提到。
这里再借助 Kano 模型做详细说明。
（1）必备型需
这类需求属于对方工作流中不可或缺的基础，对此重点不是要不要做，而是要怎么才能做好。
举个例子：
通常来说，企业管理的方式一般是自上而下，这也是产品目前的核心流程。
但由于这次疫情，会存在自下而上的汇报，也就是除管理者下派的任务，底层执行人员会根据店内情况做问题上报。
首先这个需求符合产品定义，其次结合业务场景，它的价值是能补充业务闭环。知道很多企业，会要求门店人员即时上报门店情况，并做到信息留档。
对此我们的处理方式，先基于疫情做了一个「疫情上报」，放在 App Banner 位，做初步功能验证和迭代调整，而后续可以作为新功能正式上线。
（2）期望型需求 + 兴奋型需求
通常会伴随着兴奋型需求一起提出，而我们要考虑这个需求能否解决对方关键的业务问题。
毕竟对于 SaaS 产品来说，收入的途径主要还是靠产品能否卖的出去。
而除此之外的需求，可以从影响面和 ROI 两个维度去进行排序。