从写代码到做产品：我和PM思维打了三个月架
写代码16年，三个月前开始做产品经理的事。
这三个月最大的收获不是学会了什么方法论，而是跟自己打了无数架。
程序员的本能和PM的本能经常打架，有时候打赢了，有时候被打得鼻青脸肿。
这篇文章不讲成功经验，讲讲真实的内心冲突——我是怎么从一个"先想能不能实现"的开发者，变成一个"先想值不值得做"的PM。
一、第一天就打架：功能清单引发的血案
正式开始做TLDR Scholar那天，我干了一件特别程序员的事：
列功能清单。
不是随便列，是认真列——按照优先级排好，加上一句话说明，打算按这个清单一个个实现：
P0：
- 论文上传与解析
- AI一句话总结
- 历史记录
P1：
- 批量上传
- 论文对比
- 收藏与分类
P2：
- 个性化维度设置
- 导出笔记
- 分享功能
P3：
- 知识图谱
- 论文推荐
- 社群功能
列完看着清单，内心充满了秩序感。16年写代码的经验告诉我：需求文档是根基，根基不稳后面全塌。
然后我拿着这个清单去找一个做产品的朋友看。
他问了我一个问题，我到现在都记得：
"你这辈子只能做一件事，你选哪个？"
我说："AI一句话总结啊，这是核心。"
他又问："那你列这些P1、P2干嘛？"
我愣住了。
他说："你在用开发思维做产品规划。开发是'把所有功能做完'，产品是'把所有价值做透'。这是两种完全不同的目标。'"
那天晚上我回家，把清单删掉了三分之二，只剩下一个功能：上传论文，输出四维度总结，30秒出结果。
第一次打架：我输了。
但说实话，心里不服气。"万一以后需要批量上传呢？""万一用户想对比论文呢？"
——这种"万一"思维，困扰了我很久。
二、"技术上能做"是个陷阱
开发者的通病：只要技术能做，就想做。
为什么？因为写代码的快感很大程度上来自"搞定"——这个问题能解决，那个边界条件能处理，这个功能从无到有跑通了。
我一开始对TLDR Scholar有很多"技术上的兴奋点"：
兴奋点1：多模态论文解析。 文字提取太简单了，能不能把论文里的图表也解析出来？让AI理解图1是什么、图2对比了什么？
做了一周，放弃了。不是做不出来，是发现：用户在筛选阶段根本不需要知道图表内容。他们只需要知道"这篇论文做了个对比实验"就够了。图表的细节，是精读阶段的事。
兴奋点2：论文知识图谱。 能不能把一个领域的论文串起来，展示引用关系、方法演进、发现传承？做个科研版GitHub？
调研了一圈，发现这活儿一个创业公司在做，融了几个亿。用户需求确实存在，但需要的数据积累和产品打磨远超我的能力范围。
兴奋点3：语音播报。 能不能让AI把总结念出来？用户边走路边听论文？
这个功能还真的做出来了，然后——零使用率。
为什么？
我后来才想明白：论文总结是用来"快速判断"的，30秒的事。用户不需要"听"，需要的是"扫一眼"。加个语音播报，在用户决策路径里根本找不到位置。
这三次"技术上能做"的兴奋，都变成了"产品上不该做"的教训。
后来我给自己定了个规则：
每加一个功能，必须回答三个问题：
- 用户在什么场景下会想到用这个功能？
- 这个功能帮用户节省了什么、避免了什么？
- 如果不做这个功能，最坏的结果是什么？
三个问题都答不上来，就不加。
三、"我觉得用户需要"差点让我做一个没人用的东西
第二个让我印象深刻的事，是关于"可重现指标"的。
我自己踩过坑：精读了一篇论文觉得方法不错，花两天尝试复现，结果代码没开源、关键参数没写、实验环境未说明。两天白费了。
基于这个经历，我设计了一个维度：可重现指标。
我在产品文里详细解释了这个维度的价值，读者反馈也很好——很多人说"这个功能太实用了"。
但后来我发现一件事：夸这个功能的人，和骂我"加这么多维度太复杂"的人，高度重叠。
什么意思？
夸"可重现指标"的人，大多是做复现、做研究的——这些人是真的被"复现失败"坑过。
骂"维度太多"的人，很多是快速浏览论文的学生——他们不需要复现，只需要知道"这篇论文说了什么"。
我用自己的痛点设计了产品功能，却假设所有用户都有同样的痛点。
这个问题我到现在都没完全解决。现在的妥协是：四个维度都保留，但把"可重现指标"的视觉权重降低，让不需要的人可以"扫过它"。
但这只是妥协，不是答案。
真正的答案是：你的痛点只是假设的起点，不是假设本身。从"我觉得用户需要"到"验证过用户需要"，中间有很长一段路。
四、完美主义者差点害死产品
我是个有洁癖的开发者。
代码要有好的命名规范，要有注释，要考虑扩展性。提交前至少review两遍再push。写了16年代码，这个习惯刻进骨子里了。
做产品的时候，这个习惯差点把我害死。
事件一：PDF解析的完美主义。
最开始上线时，PDF解析有大约5%的概率出现乱码或信息丢失。这个概率不高，但每次出现都很明显——输出的总结要么答非所问，要么直接说"无法解析"。
我的第一反应：修好它。
然后我花了整整三周，优化PDF解析逻辑，加容错机制，加兜底方案。
这三周里，产品没有任何新用户，没有任何反馈，没有任何迭代——我把时间全花在了一个5%的边界case上。
事后复盘：用户第一次来的转化窗口可能就几秒。你花三周把5%的失败率降到1%，但99%的用户根本没机会感知这个提升，因为他们根本没来。
事件二：UI设计的完美主义。
我是前端出身，对界面有执念。按钮的位置、间距、配色、动效……每一个细节都要扣。
第一版上线前，我在"上传按钮的loading状态应该用什么动画"这件事上纠结了两天。
现在回想起来，简直可笑。但当时就是觉得：这是用户第一眼看到的东西，不能糊弄。
问题是：用户第一眼看到的东西，核心是"这个工具能不能帮我解决问题"，不是"loading动画好不好看"。
开发者的完美主义是质量导向的——代码质量、产品质量。PM的完美主义是价值导向的——用户问题解决没有。
这两个"完美"完全不是一回事。
五、真正的转折点：开始看数据
转变发生在上线一个月后。
那时候产品有了第一批真实用户——不多，几十个。但有了数据之后，我才发现之前很多"想当然"的想法都是错的。
错得最离谱的一个：用户来源假设。
我以为用TLDR Scholar的人主要是研究生，因为研究生读论文最痛苦。结果后台数据显示：40%的用户是工程师，25%是研究员/博士，只有35%是硕士。
这个数据让我重新思考了产品定位。
研究生用工具是为了"完成导师布置的任务"——快速过一遍，组会上能说两句。他们更关注"有没有读完"，对质量要求没那么高。
工程师用工具是为了"判断这篇论文跟手头的工作有没有关系"——如果没关系就跳过，有关系就仔细研究。他们更关注"判断准不准"，宁可慢一点，也要准确。
研究员/博士更复杂——他们有明确的研究方向，要的是"这个方向的新论文我知道了"，对信息的时效性要求更高。
三种用户，三种需求，一个产品能同时满足吗？
现在还在探索。但至少，数据让我从"我觉得用户是研究生"里跳出来了。
怎么开始看数据的？
说起来可笑，我一开始连数据分析工具都没装。用的还是最土的办法：
- 看服务器日志，记录每次API调用
- 导出用户反馈（邮件和网站留言）
- 手动画图表分析用户行为
简单粗暴，但管用。
核心指标我盯三个：
- 首次转化率：访问的用户里，有多少上传了第一篇论文
- 7日留存：首周用过的用户，下周还来吗
- 功能使用分布：哪个维度用得最多，哪个几乎没人看
这三个指标帮我做了很多决策：
- "可重现指标"使用率只有12%，但"核心发现"使用率78%——说明前者的价值对部分用户极高，但入口设计需要优化
- 首次转化率只有15%，大部分人看完就走——说明落地页传达的价值主张不够清晰
- 7日留存35%——比我预期高，说明真的解决了问题，用户愿意回来
数据不会骗人，但你的直觉会。
六、最难的一场架：PM思维 vs 开发者本能
前面讲的都是具体的冲突。最后这场架比较抽象，但我觉得是最核心的。
开发者的本能是什么？
是"把事情做对"。
接到一个需求，先想怎么实现。架构怎么设计，代码怎么组织，边界条件怎么处理。一个功能做完了，标准是"跑通了没"。
PM的本能是什么？
是"做对的事情"。
接到一个问题，先想值不值得解决。这个功能解决了什么用户问题？解决了多大的问题？值不值得投入？
这两套逻辑的差异，用一个例子说清楚：
场景： 用户反馈"批量上传论文很麻烦，一次只能传一篇"。
开发者反应：
- "确实，一个一个传很反人类"
- "实现批量上传不难，用HTML5的multiple属性就行"
- "我今天下午就能做完"
PM反应：
- "用户在什么场景下需要批量上传？"
- "是筛选阶段批量上传，还是整理阶段批量上传？"
- "如果用户有50篇论文要筛选，他们现在怎么做的？"
- "他们现在的做法痛苦吗？值得用产品解决这个问题吗？"
- "如果值得，最小成本的解决方案是什么？"
两套逻辑都能解决问题，但问题可能完全不是同一个。
开发者的逻辑：用户说批量上传麻烦→实现批量上传。
PM的逻辑：用户说批量上传麻烦→为什么要批量上传→可能用户是在做文献综述→可能文献综述的核心痛点不是"上传麻烦"而是"筛选效率低"→可能批量上传只是方案之一，还有更好的方案→最后决定做什么、怎么做。
开发者解决问题，PM定义问题。
这句话听起来像废话，但真正做产品的时候，你会发现90%的时间都在"定义问题"上——问题定义错了，解决方案再好也是白搭。
七、三个月后的我
现在回过头看这三个月，最大的变化不是学会了什么工具或方法论，而是思维模式变了。
之前的我：
- 拿到需求，先想能不能实现
- 做产品，先列功能清单
- 功能做完了，标准是"跑通了没"
- 优化体验，追求细节完美
- 用户反馈是"参考"，自己判断才是主导
现在的我：
- 拿到需求，先想值不值得实现
- 做产品，先找核心问题
- 功能做完了，标准是"解决了问题没"
- 优化体验，先优化核心路径
- 用户反馈是"事实"，自己的判断是"假设"
这两个清单看起来差不多，但优先级完全反了。
这个转变花了多久？
说实话，到现在也没完全转过来。有时候看到一个新的技术方案，还是会手痒想试试；有时候看到用户提的需求，还是会下意识想"这个不难，我能做"。
区别是：现在能意识到自己在犯这个毛病了。
意识到，是改变的第一步。
八、给同样在转型的你
如果你也是从技术转产品，或者正在考虑这条路，有几点我的真实体会：
1. 学会"不作为"的勇气。
程序员的价值来自"输出"——写了多少代码，完成了多少功能。PM的价值来自"判断"——做了什么决定，避免了什么问题。
一个功能不做，比做一个功能更难。因为"做"有即时的成就感，"不做"只有等待结果的焦虑。
2. 用户访谈比数据分析更重要。
数据告诉你"用户在做什么"，但不能告诉你"用户为什么做"和"用户真正想要什么"。
找个用户聊半小时，比看一周数据收获更大。
3. 接受"不完美启动"。
完美主义是开发者的好朋友，PM的天敌。70分的产品先上线，收集反馈，快速迭代——这比90分的产品等三个月再上线强。
4. 保持技术优势，但别被技术绑架。
技术能力是产品经理的底气，但别让"这个我能做"成为做决策的出发点。
好的产品不是"能做什么"，是"该做什么"。
写在最后
TLDR Scholar到现在三个月，核心功能还是那个：上传论文，输出四维度总结，30秒出结果。
没有批量上传，没有知识图谱，没有语音播报。
这些功能都在我的"万一清单"里，躺在那里吃灰。
有时候看到别的产品加了这个功能那个功能，心里还是痒痒的。
但每当这时候，我就问自己一个问题：
如果用户只需要一个功能，你觉得是哪个？
这个问题帮我挡住了大部分"技术兴奋点"的诱惑。
产品经理的终极能力，是在无限的可能性里，选择做那件最重要的事。
这句话听起来简单，做起来——
我还在练。
产品地址：www.tldrscholar.cn
有问题、有建议、有吐槽，评论区见。
#AI产品 #产品经理转型 #独立开发 #开发者思维 #PM思维
