技术人的「第二曲线」：从写代码到做产品

技术圈有一个经典问题：一个程序员写了十年代码，和一个程序员写了一年代码、重复了十年，他们有什么区别？

这个问题背后，藏着技术人最深的焦虑：我的技术能力，在 35 岁之后还值钱吗？

焦虑的原因很简单——如果你和五年前一样，只会写代码，那你的可替代性确实在逐年上升。但如果你在写代码的同时，建立了一条新的能力曲线，情况就完全不同了。这条新曲线，我称之为技术人的「第二曲线」：产品思维。

什么是第二曲线？不是换赛道，是叠加新能力

「第二曲线」这个概念来自管理学家查尔斯·汉迪。他的核心观点是：任何一条增长曲线都会到达顶峰然后下滑，如果你想持续增长，必须在第一条曲线还在上升的时候，就开始培育第二条曲线。

对技术人来说，第一曲线是「把代码写好」——这是你入行的基本功，也是你安身立命的根本。但这条曲线有个问题：它的天花板是可见的。当你写到第七年、第八年，你和写了三年的人之间的差距，已经不像你想象中那么大了。

第二曲线不是让你放弃写代码，去做产品经理。第二曲线是叠加在你已有能力之上的新维度——你还是技术人，但你开始用产品视角看问题。

一个只会写代码的技术人，和一个有产品思维的技术人，面对同一个需求时，反应完全不同：

几年前，我接到一个需求：做一个数据导出功能。产品经理的原话是"用户需要把报表导出成 Excel，方便他们离线分析"。

如果我只停留在「需求实现者」的角色，我会怎么做？评估技术方案、选择 Excel 库、写接口、前后端联调、上线。功能做完了，需求完成了，我写得还挺快——一个典型的"好程序员"。

但后来我养成了一个习惯：在写代码之前，追问三个问题：

追问的结果是：用户之所以要导出，是因为在线报表的筛选功能不够灵活，他们需要用 Excel 的透视表做二次加工。而数据量有时会超过 10 万行，直接导出会超时。

最终我做的不是"导出 Excel"，而是优化了在线报表的筛选能力，加上了一个异步大文件导出方案——前者让 80% 的用户不再需要导出，后者让剩下的 20% 能正常导出。

好代码解决的是技术问题，好产品思维解决的是人的问题。

这个案例看起来很小，但它代表了两种完全不同的工作方式。前者是"你给我需求，我实现"，后者是"你给我问题，我帮你找到最好的解决方案"。前者是劳动力，后者是智力。

很多人听到「产品思维」就觉得要做用户调研、画原型、写 PRD——那是产品经理的工作。技术人的产品思维，比这个简单得多：

每次接到需求，先问自己：这个需求要解决用户的什么问题？用户现在是怎么做的？为什么现在的方案不行？

这三个问题用不了五分钟，但问完之后，你对需求的理解深度会完全不同。而且，当你带着这些理解去和产品经理讨论时，你们的对话会从"这个能做吗"变成"有没有更好的方式"。

技术人员习惯用技术指标衡量工作：优化了 30% 的查询性能、把接口响应时间从 500ms 降到了 200ms。但你有没有想过，200ms 和 500ms 对用户来说意味着什么？

如果你能说出"用户打开页面的等待时间从 2 秒变成 1 秒，流失率预计下降 5%"，你的价值就不再是一个"写代码的人"，而是一个能用技术创造业务价值的人。

初级技术人想着"我还能做什么"，高级技术人想着"我们可以不做什么"。

产品思维的核心能力之一是判断优先级——眼前这个需求，是用户真的需要，还是某个人的一时兴起？这个功能加进去，是解决问题，还是制造更多维护成本？

我有一个简单的判断标准：如果一个功能上线后，三个月内没有人会因为它不可用而感到痛苦，那这个功能就不值得做。

培养产品思维不需要你换工作、不需要你报课程，只需要你在日常工作中多做三件事：

每周找一个你正在做的功能，写出它的"用户故事"——是谁在用？在什么场景下用？要完成什么任务？不用写得很正式，用你自己的话写在备忘录里就行。
下次评审需求时，多问一个"为什么"——不是挑战产品经理，而是真诚地想知道背后的逻辑。你会发现，有些需求产品经理自己也没想清楚。
关注你做的功能上线后的数据——有多少人用？他们怎么用？你有没有想过，你写的那段代码在真实世界里产生了什么影响？当你开始关心这些数字，你就不再是"写代码的"，你是"做产品的人"。

技术人的核心竞争力，不应该只建立在一门语言、一个框架、一个工具上。这些东西会变，会过时，会被新的替代。真正持久的能力，是你理解问题、定义问题、解决问题的能力——而这恰恰是产品思维要训练的东西。

写代码是你进入这个行业的门票，但让你一直走下去的，是你能不能用代码解决真正重要的问题。

从今天开始，试着在每次写代码之前，多想一分钟：这个功能，到底在解决谁的什么问题？

这一分钟，就是你第二曲线的起点。