前言
视频里讲到了一个非常经典的例子，就是SaaS 平台的通知公告要不要做未读的小红点提醒。本篇我们就结合这个案例来说一下产品经理如何培养技术思维。
视角分析
回到这个案例，我们先从产品经理视角来看看这个未读通知的需求：
用户价值：通过未读小红点能够让平台的用户不错过最新通知，了解最新的通知内容。
业务场景：用户登录到后台或 打开App后，在通知入口看到小红点，然后点击查看未读通知。
商业价值：完成平台的通知公告传达义务，让用户避免错过一些重要通知，实际上这个功能商业价值不大。
业务闭环：用户存在未读通知时，小红点一直存在，直到用户阅读完（或标记已读）全部未读通知。
从产品经理的视角来说这个需求似乎很合理。我们来看看技术视角。
具体实现：这个小功能实现起来要做不少事情。
需要建立一张通知公告和用户的中间数据表，来标记用户的已读未读状态。
当平台发布一条新通知后，要给平台所有的用户插入该通知未读的记录。
需要写一个接口告诉前端，当前用户有没有未读通知。
当用户打开一条通知详情后，需要将未读状态更改为已读。
还需要写一个标记全部已读的接口，来标记全部的通知公告为已读状态。
技术架构：插入的通知未读的数据量会非常大，为了避免影响发布通知，可能需要使用异步的方式创建通知未读记录。
技术价值：这东西没什么技术价值。
开发成本：开发成本比较高，而且通知越多数据量越大，到后期维护成本非常高。
可以看到，技术视角和产品视角差别非常大。技术开发接到一个需求，第一反应是做这个需求实现起来复不复杂、开发成本高不高。如果他们觉得需求实现起来复杂，开发成本高的话，往往就会回复产品经理“这个开发成本太高了”或者“这个技术上实现不了”。
技术角度分析
对于不懂技术的产品经理来说，其实很难理解一个小红点为什么会说开发成本很高。我们来简单地分析一下，这里面的关键点其实是数据量很大。在数据库的数据表中，我们如果要记录每一个用户通知公告的已读未读状态的话，其实就会得到类似于下面的一个表格。
可以看到，每发布一条通知，就需要为每一个租户的每一个用户创建一条阅读状态的数据记录。设想一下，我们平台有1000个客户（即租户），每个客户有100个员工（用户），这就意味着每发布一条通知，我们会产生10万条（1000x100）数据记录。
这也是为什么在技术架构上会想到要做异步创建阅读通知的未读记录的原因（单次插入10万条数据对数据库压力还是非常大的，可能造成系统卡顿）。如果每年发布24条通知，意味着一年的数据量会达到240万条，而且会随着客户量和时间不断累积。数据量越大，一方面会导致查询速度变慢（意味着小红点可能要隔个2-3秒甚至更久才能出得来）。另一方面是数据量到一定量级后，会达到数据库的性能瓶颈，可能需要通过拆分数据表来提高性能，这导致运维成本会升高。
所以，有时候技术说“实现不了”或“成本太高”不是真的和产品经理抬杠，而是在他们看来确实是很复杂，不值得为这样的需求投入这样的代价。
怎么解决？
产品经理的需求看起来也很合理，技术开发分析看起来也很合理，那怎么解决呢？我们还是要回归到这个需求的核心目的上来。通知公告的小红点目的就是提醒用户查看平台的通知公告。通常来说通知公告是有时效性的，发布比较久的通知公告读不读其实对业务影响不大。基于这种情况，我们可以有更低代价的技术实现方案。以我们做过的产品为例，我们的实现方式是这样的：
获取平台最新的发布通知时间，如果在距离当前时间设定的时间范围内（比如7天），我们就会在通知入口标记一个“NEW”的标识，提醒用户有最新的通知公告，而不是未读状态的标识。
用户点击过这个入口后，有前端缓存状态，清除掉这个“NEW”标识，避免点击过的用户进入查看到已读的通知公告。
这种方案既满足了核心的产品功能诉求，在技术上也不需要创建针对单个用户的已读未读标识，实现起来也更简单。
怎么提升技术思维？
很多优秀的产品经理都出身于技术，如果不懂技术，产品经理的一些不合理的设计很可能会导致整个产品的架构出现问题。这也是为什么有不少SaaS 公司在招聘高级产品经理的时候希望产品经理能够懂技术，甚至是技术出身。就我个人而言，因为本身就是从技术开发出身，所以在设计产品时会考虑技术实现，同时和技术开发交流上不会存在障碍，因此和开发团队的配合都会比较默契。对于没有接触过技术开发的同学，个人建议从以下三个方面去提升技术思维能力：
优秀产品研究：通过研究优秀产品，我们会发现很多在我们看来很“高级”的功能，他们都已经实现了，因此会了解到这些高级功能的技术可实现性。我自己在公众号拆解 SaaS 产品也是基于研究优秀产品这个目的。
多与开发同学交流：在产品评审阶段，多听听技术开发同学对技术方案的评估，并且遇到不理解的可以请教他们，交流多了，就能够培养自己站在技术的角度思考问题。
学习基础的技术知识：个人的建议是基础的技术知识可以有意识地学一下，比如什么是API接口，同步/异步处理、设计模式、数据库等等。尤其是数据库，关系到产品和技术的最底层，可以着重考虑。比如本篇讲到的案例，如果是了解数据库知识，就能够快速理解技术开发说的成本太高的原因，进而和开发同学一起讨论一个更优的解决方案。
