2. 你产品的价值是否在这个场景里有最直接的体现 。 最好的直接通常是直指人心的 ， 是人直接能体会到的「感受」 。 对于开发者产品来说 ， 我通常会选择的锚点是「用户体验」 ， 因为好的体验是不言自明的 ， 汽车和马车对比在通勤舒适度和效率的时候 ， 是完胜的；就像 TiDB 和 MySQL 分库分表的方案比弹性扩展能力时候也是一样 ， 体验上也是完胜的 。 对于这一点倒是有很多方法去参考 ， 有兴趣的可以参考我那篇关于用户体验的文章 。
第一种思路本质上来说是 Storytelling ， 这种方式的好处在于：

1. 非常好验证 ， 当你把故事想明白了 ， 那自然典型的用户旅程就出来了 ， 这时候你把自己作为一个假想的用户完整的体验一遍即是验证 ， 这也是我通常使用的检验我们自家产品经理工作的方式?? 。
2. 用户很好接受 ， 道理很简单：人人都喜欢听故事 ， 人人都喜欢看 Demo ， 人人都喜欢抄作业 。

对于第二种思路 ， 通常适用于一些改进型的特性 ， 其中的关键点在于：待解决的问题到底多痛？没有完美的软件 ， 在重度用户那边一定会有各种各样的问题 ， 而且这类问题通常这个功能的开发者是难以体会到的 ， 这时候要做的也很简单 ， 就是弯下腰去了解 ， 去使用 ， 去感受 。 我经常会去和我们的客户交付团队的一线同学聊天 ， 在做这次分享之前也不例外 ， 大致的对话如下：
我：关于我们的 SQL 优化器 ， 你觉得日常工作中 ， 让你最头疼的问题是啥？
Ta：执行计划突变 。
我：对了 ， 那是 hint 不太够用吗？而且 3.0 就引入了 SQL Binding？这些帮上忙了吗？
Ta：对于一些疑难杂症来说你很难通过 hint 来指定的特定的执行计划（然后附上了一个真实的业务场景中的例子 ， 一条百行的 SQL ， 确实无从下手） ， 另外 SQL Binding 问题在于 ， 我绑定了 SQL 执行计划以后 ， 之后如果有更好计划 ， 还需要重新来？
我：我们 4.0 不如引入了 SQL Plan Management 吗？里面的自动演进功能不正好是解决这个问题的吗？
Ta：没错 ， 但是我们生产环境都不敢开 ， 对于极端重要的 OLTP 场景 ， 不能容忍执行计划自动变更带来的抖动风险 。
我：我们的产品做什么事情 ， 能让你觉得日子好过一点？
Ta：1. 对于复杂的 SQL 能够选择目标执行计划 ， 让我选择 binding 就好 ， 而不是通过 Hint 构造；2. SPM 发现更好的执行计划 ， 只需要及时通知我 ， 我来做变更 ， 而不是自动决策变更 。
上面最后一句的两个反馈 ， 我听到以后觉得很有启发 ， 其实这两个需求都是很中肯 ， 而且开发的代价并不大 ， 但是确实节约了很多的时间和 DBA 的心智负担 。
类似的例子还有很多 ， 但是重点是：找到产品的重度使用者 ， 深入挖掘他最头疼的问题 ， 有时候会有意想不到的收获（例如去 OnCall 的现场观察大家的操作） 。 而且这类问题的解决 ， 通常也会伴随着很好的体感 ， TiDB 在最近几个版本中的一些关于可观测性的改进 ， 基本都是通过类似的观察得来 。
但是第二种思路的价值展现 ， 一定要找到合适的听众 ， 例如：通常我们为应用开发者（数据库的使用者）解决的问题和数据库运维者（DBA）是不一样的 。 面对错误的对象 ， 结果有可能会是鸡同鸭讲 。
当用户在说：「我要这个」的时候 ， Ta 其实在说什么？
在中国基础软件的产品经理和解决方案工程师难找 ， 我觉得是有历史原因的 ， 就像上面我提到 ， 过去很长时间 ， 我们通常是站在一个「使用者」的视角去看待软件 ， 这意味着从问题到解决方案通常是明显的 ， 例如 ， 假设我需要做一个高性能 ， 支持亚毫秒低延迟读写的 User Profile 系统 ， 数据量不大 ， 可以容忍数据丢失 ， 那我就用 Redis 好了！但是作为 Redis 的产品经理来说 ， ta 很难为了 User Profile 这个很特化的场景去设计 Redis 的功能 。