产品经理应该多看数据,但绝不能迷信数据.pdfVIP

产品经理应该多看数据 ，但绝不能迷信数据 在一些情况下 ，看数据可以使决策更合理 ； 有时 ，完全根据数据决策又可能会导致别的更 严重的问题。 一个需求可能有多种的解决方案 ，产品经理该如何抉择 ？在定性分析每种解决方案的优劣势之后 ， 定量的数据分析可以给决策提供更多的参考。 例如 ，某产品目前的“审批”功能中 ，用户新建审批时根据组织架构选人的操作过程 ，如图1所示 ： 图1 目前用户通过组织架构选择审批人的操作过程示意图 其中 ，由于业务上规定审批人只能选一人 ，当用户选中一人后再选择其他人时会弹出t oast ，提示“ 只能选一人”。此时用户需要先取消原选中人 ，才能重新选择其他人作为审批人。 弹出t oast 一般用于提示误操作 ， 用户可能只是想换一个审批人 ，却被认为是误操作 ，体验并不 友好。为了改变这种不友好的体验 ，决定对此处的选人控件进行优化。经讨论提出了两种优化方 案 （考虑到未来会对接第三方的审批功能 ，现阶段仅针对前述的体验问题进行优化 ，不做业务层面 的改动 ）： 方案一 ：在目前根据组织架构选人方案的基础上 ，作如下修改 ：用户选中一人后再选择其他人 ，可 直接选中、同时原选中人自动取消 ，且无提示。如图2和图3所示 ： 图2 方案一中用户通过组织架构选择审批人时的操作过程示意图 图3 方案一中用户通过组织架构选择审批人时的操作流程图 方案二 ：取消圆形复选框 ，用户通过组织架构选中审批人后 ，无需点击“完成” ，直接选中并跳回“新 建审批”页面 ；当需要重新选择审批人时 ，再通过组织架构进入并更换。如图4和图5所示 ： 图4 方案二中用户通过组织架构选择审批人时的操作过程示意图 图5 方案二中用户通过组织架构选择审批人时的操作流程图 这两种方案都能解决上述体验不友好的问题 ，但各有优劣 ，分析如 ： 如果用户通过组织架构选择审批人 ，在不出现错选的情况下 ，与方案二相比 ，采用方案一时用户多 了点击“完成”这一动作。 若用户出现错选 ：采用方案一时 ，由于尚未点击“完成”、页面未跳回 ，只需直接选中正确的审批人 即可 ，无需再次通过组织架构进入 ，出错成本低 ；采用方案二时 ，用户需要逐级进入审批人所在的 分支 （如果审批人在第十级分支 ，则用户不得不点击十次才能进入 ），出错后的成本很高。因此 ， 若用户主要通过组织架构选择审批人 ，则方案一和方案二各有优劣。 如果用户通过搜索选择审批人 ，则两种方案下如果出现错选 ，用户均只需通过搜索即可直接重新定 位审批人 ，故出错后的成本相差不大。因此 ，若用户主要通过搜索选择审批人 ，则应优先考虑省了 点击“完成”这一动作的方案二。 那么 ，究竟应该选择方案一还是方案二呢 ？根据上面的分析可知 ，需要考虑两个因素 ： 用户在选择审批人时更多地通过组织架构还是搜索 ； 用户通过搜索选择审批人时出错的可能性大不大。 此时 ，如果能借助一些数据说明问题 ，方案的决策将会更合理、更有说服力。因此 ，尝试获取如下 数据 ： 1. “通过组织架构选择审批人”与“通过搜索选择审批人”这两种方法的使用次数分别占审批人选择总次 数的比例 ； 2. 用户“通过组织架构选择审批人”时的出错率。 根据获得的数据 ，可以更科学地进行决策 ，例如 ：若用户“通过组织架构选择审批人”的使用次数占 比较大、且出错率也较大 ，则采用方案一更合理 ；若用户“通过组织架构选择审批人”的使用次数占 比较小、且出错率也很小 ，则采用方案二更合理。 通过上述这个案例可以看出 ，数据可以帮助产品经理更好地做决策。但是 ，事物都有两面性 ，如果 一味迷信数据也可能会做出错误的决策。 以当前最火的IM工具微信为例 ，假设 ：统计发现 ，微信用户在点了“发现”Tab后 ，80%以上的用户进 入了“朋友圈”。基于以上数据 ，建议将“朋友圈”从“发现”中独立出来作为一个单独的Tab ，如图6所示 ： 图6 微信“发现”页面建议改版方案 改版方案是根据统计数据作出的 ，改版后“朋友圈”的层级少了 ，用户查看朋友圈的操作更方便了 ， 这似乎是一个不错的方案。 但是 ，该方案会带来一个严重的后果 ：没有了“朋友圈” ，“购物”、“游戏”这两个最赚钱的应用的流量 将会大大减少 ，这违背了微信的商业目的。也许正是基于这点考虑 ，微信并没有