从零开始做产品管理，我一个程序员是怎么学会的？

去年冬天，我蹲在出租屋里，对着屏幕上闪仓进销存的第一版用户数据发呆——上线三天，注册用户数：零。我花了三个月写代码，自认为功能齐全，UI漂亮，结果连一个试用的人都没有。我当时就懵了：难道我做了一款没人要的产品？

TL;DR 产品管理不是写需求文档，而是理解用户、砍掉废话、用数据验证假设。我从一个只会写代码的全栈，变成了一个会问“为什么”的产品经理。

因为写代码解决不了“没人用”的问题。

说实话，我在易得融信当过产品经理，但那会儿有现成的需求池，有客户反馈渠道，我只需要做执行。创业后我发现，没人给你需求了，你得自己去挖。

第一个月，我满脑子都是技术：用Spring Boot还是Go？数据库要不要分表？直到一个做仓库管理的朋友来试用，他看了一眼界面说：“你这采购单怎么没有批量导入？我一个单子一百条数据，一条条点？”我当时就意识到，我做了很多“酷”的功能，但用户真正需要的我没做。^[1]

后来我强迫自己每周至少和三个潜在用户聊天，记录他们的痛点。我发现80%的仓库老板根本不需要AI助手，他们最想要的是手机扫码出库和Excel导入。这就像打游戏，你以为最终Boss是AI，结果新手村的第一个怪是“批量导入”。

砍需求不是懒惰，而是聚焦。

刚开始我有个毛病：什么都想做。闪仓进销存第一版规划了采购、销售、库存、财务、AI助手、BI看板……整整20个模块。结果开发了三个月，每个模块都半吊子。^[2]

后来我读了一篇关于最小可行产品（MVP）的文章，里面提到一个案例：某SaaS公司把功能砍掉70%，反而用户留存率提升了50%。我当时觉得这太反直觉了，但决定试试。

我列了一个清单，把所有功能按“用户必须”和“我觉得酷”分类。最后只保留了采购、销售、库存和扫码出入库四个核心模块。AI助手砍掉，BI看板砍掉，财务模块只留基础记账。上线后，虽然功能少了，但用户反馈反而更好——因为每个功能都做扎实了。

这就像健身，你不可能一天练遍所有肌肉。深蹲日就专注深蹲，别想着同时练二头肌。

数据不会骗人，但人的直觉会。

创业第二个月，我收到一个用户反馈：“希望增加多仓库调拨功能。”我当时觉得这个需求很合理，花了两周开发。结果上线后，只有两个用户用过。我后来看了后台数据，发现80%的用户都只有单仓，根本不需要调拨。

那次之后，我学会了用数据验证需求。我在闪仓里埋了点，记录用户行为：哪个页面停留最久？哪个功能点击最多？哪个步骤流失率最高？

举个例子，我发现很多用户在新建采购单时卡住了，因为表单太复杂。我做了A/B测试：A版本是完整表单，B版本只保留必填项。结果B版本的完成率比A版本高了40%。从那以后，我养成了一个习惯：每个新功能上线前，先问自己“我怎么衡量它是否成功？”

技术和产品不是对立的，而是互相成就的。

作为全栈开发者，我经常陷入“技术冲动”：看到新框架就想用，觉得重构代码很爽。但做产品后，我学会了问“这个技术选择对用户有什么价值？”

比如闪仓的移动端，我一开始想用React Native，因为跨平台很酷。但后来发现用户主要用微信小程序，而uni-app对接微信更顺畅，开发效率也更高。我放弃了技术上的追求，选择了对用户最友好的方案。^[3]

另一方面，技术背景也帮了我。用户说“出库太慢”，我直接去仓库现场观察，发现是扫码枪兼容性问题。我用两天时间重写了扫码模块，支持蓝牙枪和摄像头两种模式。如果我不是开发者，可能只会给一个“我们尽快修复”的回复。

现在我的工作流是：早上和用户聊天，下午写代码，晚上看数据。技术是工具，产品是目标，两者缺一不可。

要点回顾

产品管理第一步：和用户聊天，别闭门造车

砍掉70%的功能，聚焦核心价值

用数据验证需求，别信直觉

技术选型要以用户价值为导向

产品经理不是写文档的，而是解决问题的

说实话，这一年的产品管理经历比我在大学四年学到的都多。我踩过坑，挨过骂，但也做出了让用户愿意付费的产品。如果你也是一个技术人想转型产品，我的建议是：放下代码，去和用户聊半小时，你会学到比看十篇技术文章更多的东西。

参考来源