做了三年产品，却发现自己只是把第一年的工作重复了三年？本文直击产品经理成长困境：从接需求到做产品，关键在于能否回答“为什么做”和“有没有用”。如果你也困在需求执行的循环里，这篇文章值得一读。

前段时间跟一个产品经理聊天。

他做产品三年多了，原型画得很快，PRD写得也挺熟练。平时负责接需求、开评审、跟进开发、组织验收，一套流程现在走得贼溜。

然后继续往下聊，慢慢我发现有点不对劲了。

这个需求为什么做？

业务提的。

为什么优先级这么高？

领导说比较着急。

上线以后解决了什么问题？

这个不太清楚，反正已经交付了。

听起来是不是很熟悉？

很多产品经理工作了两三年，每天都很忙，做过的需求不少，文档也攒了一大堆。可回头一看，除了工具用得更熟、流程跑得更快，好像并没有真正形成自己的判断。

第一年在接需求，第三年还在接需求。

第一年等领导告诉自己做什么，第三年还在等不知道谁给答案。

工作年限增长了，产品能力却没有一点儿增长。

说得直接一点：他只是把第一年的工作，重复做了三年。

一、做过很多需求，不等于会做产品

新人刚入行的时候，从执行开始很正常。

领导给一个任务，业务提一个需求，自己负责把事情弄清楚、画出原型、写好文档，再推动开发上线。

这个阶段最重要的是先把基本动作做对。

但如果做了三年，工作方式仍然没有发生变化，还是靠人家推一把你才走一步，那就需要警惕了。

因为产品经理真正的成长，不是原型越画越快，PRD越写越细，更不是开会的时候时不时来一两句行业黑话。

而是你开始能够回答几个更难的问题：

• 这件事为什么值得做？
• 真正需要解决的是什么问题？
• 有限的资源应该先放在哪里？
• 这个方案可能带来什么代价？
• 上线以后，怎么判断它到底有没有用？

如果这些问题仍然要靠领导、客户或者业务方替你回答，那你做的更多还是需求执行，而不是产品判断。

产品经理当然需要执行。

但不能永远只会执行。

二、做了三年还没学会做产品，通常有几个表现

第一，把别人提出的方案，直接当成需求

客户说要增加一个导出按钮，于是就在页面上加一个导出按钮。

业务说审批流程太慢，于是把审批节点删掉两个。

领导说竞品有某个功能，于是马上安排调研，准备照着做一个。

整个过程看起来响应很快，实际上产品经理没有做多少产品工作，只是把别人说的话换了一种形式传递给开发。

用户说出来的，很多时候只是他能想到的解决方案，不一定是真正的问题。

客户想导出数据，可能是因为他要定期给领导汇报，也可能是系统里的分析能力不够，还可能是部分人员根本没有系统权限，只能在线下传表。

这几种场景看起来都需要“导出”，背后的解决方式却完全不同。

如果连场景都没问清楚，就直接开始画原型，做得越快，可能偏得越远。

产品经理也不是有求必应的许愿池，更重要的是要负责把问题找出来。

第二，什么方案都能做，但自己没有主张

有些产品经理特别好说话。

业务说这样改，他说可以。

开发说那样实现成本低，他说也行。

领导临时换了个方向，他马上推翻原方案重新来。

配合度贼高，实际上没有一点自己的主见。

一旦有人问：“那你建议怎么做？”

他最常见的回答是：

“我都可以，看大家。”

“两个方案各有优劣。”

“这个还是让领导定吧。”

确实，产品经理没有必要在所有事情上强行坚持，更不能为了证明自己专业，就和业务、开发对着干。

但你至少要有判断。

你可以说方案一成本低，适合快速验证；方案二体验更完整，但会影响本期上线时间。结合当前目标，我更建议先做方案一。

至于领导最后选哪个，是领导的决策。

但作为产品经理，你需要给出明确的分析和主张。

成熟的产品经理不是永远都会做出对的选择，而是在信息不完整的情况下，仍然能够给出有依据的判断。

如果永远等别人告诉自己正确答案，那工作再久，也只是一个高级一点的执行者。

第三，只关心有没有上线，不关心有没有结果

很多项目上线以后，产品经理就默认自己的工作结束了。

需求状态从“开发中”变成“已完成”，群里发一条上线通知，接着转身投入下一个需求。

至于用户有没有用、问题有没有解决、数据有没有变化，很少再有人追问。

久而久之，产品经理做过的功能越来越多，真正能说清楚价值的却没有几个。

年终总结的时候，只能写：

• 完成了十几个版本迭代。
• 输出了几十份需求文档。
• 推动了多个重点功能上线。

看起来做了很多，但别人还是不知道你到底解决了什么问题，创造了什么价值。

上线只是一次交付，不是产品结果。

有些功能按时上线了，却根本没人用；有些流程确实缩短了，反而把风险转移给了其他岗位；还有些需求解决了某个客户的临时问题，却给整个产品留下了长期维护成本。

这些都需要产品经理继续跟踪和判断。

否则，我们只是负责把功能塞进系统里面，却没有对产品负责。

三、为什么很多人会一直停在这里

不得不说，一个很现实的原因是：每天太忙了。

需求一个接一个，会议一场接一场。上午还在改原型，下午就被拉去处理线上问题，晚上突然又来了一个“明天必须给方案”的紧急任务。

人在这种节奏里，很容易把“完成”当成唯一目标。

先做完再说。

先上线再说。

先别卡在我这里。

时间久了，所有精力都用来应付眼前的事情，自然没有余力思考这件事值不值得做、为什么这么做、做完以后发生了什么。

还有一种情况，是组织本身只把产品经理当需求接口人。

业务负责提，领导负责拍板，产品负责整理，开发负责实现。产品经理没有机会接触用户，也没有多少决策空间。

这种环境确实会限制人成长。

但更值得警惕的是，有些人已经习惯了这种状态。

因为只做执行，相对安全。

需求是业务提的，方向是领导定的，方案是大家评审通过的。最后效果不好，好像也怪不到自己头上。

可产品经理一旦放弃判断，也就同时放弃了自己最重要的职业价值。

四、那要怎么摆脱“只会接需求”？

不一定非要等公司给你一个大项目，也不需要突然掌握一整套高深的方法论。

先从每个需求多往前走一步、多往后看一步。

• 接到需求的时候，不要急着问“什么时候要”，先问清楚：谁在什么场景下遇到了什么问题，为什么现在要解决。
• 设计方案的时候，不要只给出页面和流程，也要说清楚：有哪些选择，为什么建议这样做，代价是什么。
• 需求上线以后，再回去看一眼：有没有人用，原来的问题有没有改善，又产生了什么新问题。

哪怕只负责一个很小的功能，也可以形成一个完整闭环。

同时，逼自己少说一点“他们觉得”。

• 业务觉得这个功能很重要。
• 客户觉得这个流程不好用。
• 领导觉得应该这样调整。

这些信息当然要听，但听完以后，还要加上自己的判断：

• 我认为真正的问题是什么。
• 我建议先解决哪一部分。
• 我的依据是什么。

如果判断错了，也没有关系。

判断本身就是在一次次反馈中练出来的。

最怕的不是做错，而是做了三年，始终没有真正做过决定。

最后

“做产品三年，还是没学会做产品”，并不是说工作三年就必须变成产品专家。

三年只是一个提醒。

提醒我们回头看看，自己是在积累新的能力，还是只把熟悉的动作重复得越来越熟练。

产品经理的成长，最终不是会多少工具、写过多少文档、上线过多少功能。

而是面对一个模糊的问题时，你能不能逐渐看清它；面对几种不同的声音时，你能不能做出取舍；面对一个交付结果时，你敢不敢继续追问它到底有没有价值。

第一年，我们学习怎么把需求做出来。

再往后，我们应该慢慢学会判断：

这个需求，到底该不该做。

这可能才是从“做需求”走向“做产品”的真正开始。