如何利用case进行产品优化?
在工作中,产品经理经常会遇到重复类似的case,不过每次的解决方案都是治标不治本,占用了产品经理大量的时间与精力。而本文结合这一现象,总结出了如何更彻底地解决单点case与系统case的方法。
上周我发起了一个投票,大家最想了解的topic是:如何从杂乱的case和数据中提取优化点。
遇到case,常见的思路就是先定位原因,再设计方案。难的是如何更科学的定位问题、更彻底地解决问题。
被动解决单点case
小林正在准备会议需要的数据,运营同学小贾就急匆匆地跑过来。
“小林,你咋不看消息?同一个用户签合同,价格差了不少,快看看什么问题?”
“不会吧?”小林心里不信,但还是认真在看小贾扔过来的case。
“赶紧处理一下吧”小贾很是急促,“一线正忙着签单呢!”
“可能是重签合同手机号不一致,我找研发查一下”小林赶紧拿着手机去找研发。
这样的场景是不是很熟悉?很多产品经理每天都会花很多精力在类似的case上,初入职场的同学更是常见。
那么例子中为什么会出现价格不一致的case呢?
因为在之前的产品设计中,价格是通过合同中的手机号进行获取的。因此,同一个用户,签了2次合同,获取了两次价格。用户使用了两个手机号,因此被视为两个用户。
类似的单点case, 大多是因为需求设计有漏洞,测试时也未曾覆盖完整的场景。需要我们优化产品方案,根本性解决问题 。
俺么如何设计彻底的解决方案?具体如下:
因为同一个人可能拥有多个手机号,因此按同一个手机号定义,会出现手机号不同,就被视为不同用户。
在同一个用户才对应同一个价格的设计下,显然不合理。
有些朋友说,那就同一个身份证号,这总不会错吧。但真的可以吗?
如果丈夫签完合同信审不通过,需要换妻子签合同呢?是否也会面临价格不一致的问题?
看起来, 真实场景中,我们需要定义的是同一个合同,而非同一个用户 。这可能是最初设计时被忽略的点。
你需要重新思考,两个合同如何才能被视为一个合同?
用两次的合同号进行关联?只要重签的合同id与之前的合同id在系统中进行关联,就可被视为同一份合同?从而享受同一个价格优惠?
好像问题到此为止了。真是这样吗?
你就不好奇:为什么要重签合同?
是不是买卖双方在合同的后续流程中遇到了问题,需要更改合同内容。但是更改合同内容需要重新签订一份新合同。而需要更改的合同内容又可能影响了价格的获取。
既然如此,是否可以考虑在合同流程中,用合同中填写的手机号进行优惠券申领,领取后自动计算合同价格?而不是把申领价格优惠和签订合同两个流程断开后再进行匹配关联。
设计彻底的解决方案,需要打破砂锅问到底——case真正产生的原因是什么?这样真的可以解决问题吗?
在最初设计时,调研清楚线上真实的闭环场景,列清各节点可能出现的情况。
在产品方案中进行针对性的优化,大概率可以规避掉上线后的case频发。
单点case需要具备批判性思维,追求根本性解决问题。
主动定位系统case
一大早刚到公司,小嘉就开始例行监控盘点。嗯,整体数据表现比较稳定。
“小嘉,你看看这个宝马3,价格有点异常啊!”
“还有这个五菱宏光,怎么放了这么久还没有卖掉?”
“对了,昨天那台东莞的奥迪A4L,到底怎么回事?”
“……”
突然一下子,微信窗口跳出小蔡的夺命连环@。小嘉整个人都不好了。
这些问题无非就是那些原因,都给她解释很多遍了。每次换一个case,同样的问题又会被再问一遍。小嘉耸肩表示无奈。
看到这里,你不禁会问:小嘉如何确认这些问题都是之前的原因呢?
小嘉也没那么确定,只不过查的次数多了,自然重复原因的复现概率比较大。
另外,小嘉还有更重要的事情要做,怎样才能从这些工作里面解脱出来呢?
这类看似散乱无章的问题, 其实都可以通过定义一套指标解决。系统地归类case,就可以帮助小嘉和小蔡清晰地定位问题 。
在上面的例子中,就 可以考虑设计一个价格水平的指标,以及在不同的业务节点中指标的计算逻辑 。
这里需要深入思考:
- 价格水平在业务中的真实含义是什么?
- 在这样的指标定义下,什么是good case、normal case和bad case?
- 它们分别对应了业务上的什么场景?边界是什么?
- 这样的归类合理吗?
其次, 拉取出不同类型的case详情,通过单个分析、同类整理等方法,梳理清楚他们产生的原因 。good case需要持续跟进占比变化,normal case需要转化为good case,而bad case必须尽可能降低其占比。
最后 设计一个可视化的工具,支持不同场景下的查询、解释和监控 。
这样,小蔡发现异常问题,就可以在查询工具中进行查询,知道宝马3的问题是什么类型的badcase,以及产生它的原因是什么。
小嘉也可以监控不同case类型的分布和变化,并针对不同问题的比例和优先级,进行方案优化。
最重要的是,小蔡和小嘉的合作更愉快了。
系统性的定义一套指标,就像科学家设计的关于世界观的拼图;互相依赖,自成体系,不断修正。
重要的是,可以从中更全面地找到不同case之间的关联,在边界范围内考量问题,从而优化整个体系。
批量case需要拥有创造性思维,能系统地定位问题。
写在最后
实际的工作中,很多单点case即便知道根本原因,受限于优先级、资源限制和改造ROI,解决方案往往也只是停留在表面,做一些浅层修复,缝缝补补又三年,万不得已再重构。
而系统性定位问题,需要设计非常合理的指标体系,并定义好badcase的边界条件。很多case按照不同的公式,可能一会good,一会bad。
一个好的建议是,不妨先run起来,根据实际的业务表现,不断调整指标的定义和公式逻辑。
关于系统化定位的例子涉及工作内容,没有详细展开。感兴趣的可以私聊。
作者:蹭蹭,公众号:走南闯北小黑妞。
本文由 @蹭蹭 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自PEXELS,基于CC0协议
作者暂无likerid, 赞赏暂由本网站代持,当作者有likerid后会全部转账给作者(我们会尽力而为)。Tips: Until now, everytime you want to store your article, we will help you store it in Filecoin network. In the future, you can store it in Filecoin network using your own filecoin.
Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: