做产品两年,我学到的四件事

2019.09.09 53 Views 53 产品 扯淡

不知不觉正儿八经做产品两年了,title 也从「顾问」变成「经理」了。但是说来惭愧,似乎从来没好好复盘过。所以决定拾起我「年更」的博客,小诹一文,回顾一下自己踩过的坑,和一些不成体系的感悟。

1 场景,场景,还是场景

在做产品初期需求评审的时候,boss 经常会打断我,问我一些问题:为什么做这个功能?为什么要这么做?核心业务流程和场景是什么?有没有更好的方案?

我时常会被问的捉襟见肘,回答也经常被质疑。几经磨练后,我悟出一个道理:要立足于真实的场景去看需求。对于 PM 来说,可能「需求」是最重要的东西,然而所有需求都是基于用户场景的——用户是在什么场景下、如何使用你的产品,是产品设计师必须不断思考和牢记于心的一件事。

以那个著名的马和汽车的故事来说,其本意是想讲挖掘用户真正的潜在需求,但是仔细审视一下,这是一个典型的将「需求」和「场景」剥离的案例。

举例来说,有个用户来到马厩,说要在明天前赶往某地,需要一匹比平常更快的马。你总不至于说,好的,我们理解您的深层需求,请您耐心等待十年,我们会研发出一种叫「汽车」的机械载具,来满足您的需求。

当然,和缺少背景的原故事一样,这只是一种寓言式的简单叙述。实际的情况,往往比这要更复杂。

我之前做过一个客服知识库的项目,业务提出说,在服务客户时,客服如果要查询知识库内容,需要切出操作页面,在新页面中打开知识库,搜索内容。为了提升客服处理效率,想在客服操作页面上,集成一个查询插件,方便他们搜索。

知识库查询插件

于是我们做了这个功能,但是上线一段时间后,发现使用量寥寥无几,更别提效率提升了。去现场调研后,我发现客服通常会将知识库的页面常驻一个标签页,遇到问题会非常顺手地切过去检索。在与顾客通话过程中,点开和使用区域较小的查询插件,反而会影响他们的操作效率。

而之所以会产生这样的问题,是因为我错误地理解了需求的真实场景,把「客服切出操作页面」的场景和「提供查询插件」的方案建立了因果关系。

实际上这个需求,真实的场景是:客服在操作页面上,遇到了某些无法获取答案的「问题」,导致需要切出页面检索信息。那很显然,找到这些「问题」,在操作页面上提供相关信息,才是正解。问题是错的,自然给不出正确的答案。

至于如何把握真实的场景呢,没有什么捷径,只能实地去体验,去做场景观察和调研。不过当然,充足的经验多少也能保证方向上的正确。

2 MVP不是造轮子

两年时间里,我做过最为失败的一个项目,是一个业务自动排班系统。

业务方对系统的预期很高,希望实现的功能,包括对小时业务量的预测、满足各种约束条件的自动排班,和员工考勤以及遵时的监控。几乎每一个单独功能模块,都需要克服很多技术难题,而且需要长时间的优化迭代。

但是坑爹的地方在于,项目周期很短,几乎是赶鸭子上架。我在殚精竭虑了几个礼拜后,终于拿出了一套自认为行之有效的 MVP 方案。

我先是对业务流程进行拆解,认为「自动排班」是当前最大的痛点,所以准备最先实现这部分功能。我们花了大力气研究算法,解决运算资源问题,调优运算结果,好不容易勉强达到了「能用」的地步。

然而,上线后的效果却令人难堪——不仅排出的结果有各种问题,业务在一次试用后,也完全没有再想日常使用的迹象。

在之后的调研和复盘中,我意识到了问题所在——要把一个完全在线下完成的排班流程线上化,第一步绝不是解决我所谓的「痛点」。提供录入功能,将信息在不同系统间打通,实现线上流程闭环,在此基础上,再去提升各环节的效率,进行智能化的应用,这才是正确的产品演进策略。

mvp

而我所谓的「MVP 方案」,实际上是造了个轮子,还是个不圆滑的轮子。而轮子不是 MVP,独轮车才是。这是一个做产品很普遍且常见的坑,但却被我完美地踩了个遍。

知易行难,干这行真的是体会特别深。

3 技术选型会影响产品形态

产品经理需不需要懂技术,这种「日经」话题被讨论太多次了,通常政治正确的结论是:可以不懂,但是懂的话会有很大帮助。但是我的经验是,对一个合格的 PM 来说,前半句是不成立的。

我有时会听到同侪与开发之间,发生如下的对话:

开发:「要实现这个功能,可以用 A 技术,但是会有 a 影响;如果用 B 技术的话——」

产品:「哎呀,怎么实现我不管,技术方案你们自己评估。」

开发:「……好吧。」

其实原则上来讲,产品出 PRD,技术籍此评估技术方案,这么分工没什么毛病。但是实际工作中,却总会出各种差错。这是因为,通常开发和产品对需求的理解不是 on the same page

之前我们业务需要上线一个数据分析看板,涉及实时和离线的数据,开发计划使用 Druid 来实现。Druid 本身是一个成熟的解决方案,但是它有一个弊端——在去重统计时,会有不小的精度误差。碰巧这个需求对离线数据去重精度要求很高,因为涉及业务的绩效和薪资发放。

druid-architecture

但是由于负责的产品对技术方案完全不关心,也没有把「精度要求很高」这样一个隐性需求传达到位,理所当然地觉得不会有问题,导致上线后,统计结果离预期偏差很大。而且,因为一开始的技术选型错误,改动和修正需要耗费大量的资源。

其实这个问题很容易避免,只需要在评审时,仔细听一听开发说的技术方案优、缺点,选择最符合需求、最能保证产品扩展性的方案。

这点对 2C 的产品也是一样。比如说,一个前端页面该用什么框架,不是开发随便选一个就完事了,会存在诸如:是不是要做成单页应用,要不要考虑 SEO,等等,影响因素。

所以产品懂技术,不是要真的上手写代码(当然懂点 SQL 之类的还是很有帮助的),是需要了解自己产品所属领域的技术方案,和其优缺点、扩展性。因为它们是可能对产品形态产生本质的影响的。

4 用有限的资源做正确的事

有段时间帮部门负责人一起面试,有些面试者是转岗的,我通常会问一个问题,你认为产品经理的核心职责是什么。当然,开放性问题,答案不唯一,我自己的答案是:用有限的资源做尽可能正确的事

如果拥有无限的资源,那做产品太容易了,穷举所有可能性,都做一遍,选择效果最好的那个(实际上不少大公司就是在这么玩)。正因为资源有限,做正确的事才显得格外重要,毕竟产品决策失误,是会浪费大量企业的人力和财务资源的。

所以有的时候,要敢于对一些不合理的需求说「不」。而且有些事可能看上去无比正确,但是时机不对,资源不到位,就不该去做。

不久前看到苏杰的一篇博客说「内部乙方没有真正的产品经理」,深有同感。对企业而言,PM 等级的高低,就体现在他处于产品开发的哪个环节。越是前期,就越偏战略层,等级就越高。

如果仅仅是做产品架构、系统需求的梳理,是很难触碰到核心价值的。充其量,只是在打磨战术。2B 产品的出路,应该是参与业务决策,影响业务决策,甚至倒逼业务决策。如果需求的主动权掌握在业务方手中,产品的价值就会被不断压缩。

当然,这点不是仅由 PM 自己所能决定的了,更多的,可能还是受企业管理者的影响。

5 尾巴

四件事说完,好像又什么都没说,感觉不过讲了一些正确的废话。

但是,总结和复盘,本身是产品工作一个重要而不可或缺的环节。所以,尽管本文可能对读者毫无益处,但至少于我,写些来就有其价值了。

Sponsor

Comments
Write a Comment