产品和技术的思维不同,所关注的内容也有所不同。其中有一个典型的例子就是SaaS 平台的通知公告要不要做未读的小红点提醒?本文针对该案例展开分析,谈谈产品经理如何培养技术思维,一起来看看吧。
前段时间看了一个视频分享,讲到了产品和技术的思维的不同,产品更关注用户价值、使用场景、商业价值和业务闭环,而技术更关注具体实现、技术架构、技术价值和开发成本。
正是思考问题的角度不同,导致产品经理和技术开发会有很多不同的看法,最典型的就是“这个技术上实现不了”或是“这个开发成本太高了”。
视频里讲到了一个非常经典的例子,就是SaaS 平台的通知公告要不要做未读的小红点提醒。本篇我们就结合这个案例来说一下产品经理如何培养技术思维。
回到这个案例,我们先从产品经理视角来看看这个未读通知的需求:
从产品经理的视角来说这个需求似乎很合理。我们来看看技术视角。
可以看到,技术视角和产品视角差别非常大。技术开发接到一个需求,第一反应是做这个需求实现起来复不复杂、开发成本高不高。如果他们觉得需求实现起来复杂,开发成本高的话,往往就会回复产品经理“这个开发成本太高了”或者“这个技术上实现不了”。
对于不懂技术的产品经理来说,其实很难理解一个小红点为什么会说开发成本很高。我们来简单地分析一下,这里面的关键点其实是数据量很大。在数据库的数据表中,我们如果要记录每一个用户通知公告的已读未读状态的话,其实就会得到类似于下面的一个表格。
可以看到,每发布一条通知,就需要为每一个租户的每一个用户创建一条阅读状态的数据记录。设想一下,我们平台有1000个客户(即租户),每个客户有100个员工(用户),这就意味着每发布一条通知,我们会产生10万条(1000×100)数据记录。
这也是为什么在技术架构上会想到要做异步创建阅读通知的未读记录的原因(单次插入10万条数据对数据库压力还是非常大的,可能造成系统卡顿)。
如果每年发布24条通知,意味着一年的数据量会达到240万条,而且会随着客户量和时间不断累积。数据量越大,一方面会导致查询速度变慢(意味着小红点可能要隔个2-3秒甚至更久才能出得来)。另一方面是数据量到一定量级后,会达到数据库的性能瓶颈,可能需要通过拆分数据表来提高性能,这导致运维成本会升高。
所以,有时候技术说“实现不了”或“成本太高”不是真的和产品经理抬杠,而是在他们看来确实是很复杂,不值得为这样的需求投入这样的代价。
产品经理的需求看起来也很合理,技术开发分析看起来也很合理,那怎么解决呢?我们还是要回归到这个需求的核心目的上来。通知公告的小红点目的就是提醒用户查看平台的通知公告。
通常来说通知公告是有时效性的,发布比较久的通知公告读不读其实对业务影响不大。基于这种情况,我们可以有更低代价的技术实现方案。以我们做过的产品为例,我们的实现方式是这样的:
这种方案既满足了核心的产品功能诉求,在技术上也不需要创建针对单个用户的已读未读标识,实现起来也更简单。
很多优秀的产品经理都出身于技术,如果不懂技术,产品经理的一些不合理的设计很可能会导致整个产品的架构出现问题。这也是为什么有不少SaaS 公司在招聘高级产品经理的时候希望产品经理能够懂技术,甚至是技术出身。
就我个人而言,因为本身就是从技术开发出身,所以在设计产品时会考虑技术实现,同时和技术开发交流上不会存在障碍,因此和开发团队的配合都会比较默契。对于没有接触过技术开发的同学,个人建议从以下三个方面去提升技术思维能力:
专栏作家
产品海豚湾,公众号:产品海豚湾(ID:pm-dophin-bay),人人都是产品经理专栏作家。技术出身的产品经理,从事过 C 端产品和 B 端产品设计,擅长 SaaS 产品设计、产品架构设计和需求分析。负责的B 端产品完成了完整的从0到1,从1到 N 的过程,成功签约行业百强客户。
本文原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自Unsplash,基于CC0协议。
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。