很多工程师认为：我负责实现，产品经理负责定义。分工明确，各司其职。
但这种思维模式，限制了很多技术人的成长。真正的上限，不取决于你写代码的速度，而在于你能否判断什么值得做。
分工是协作，不是隔离
这不是我的工作是职场中最危险的一句话。
当你这么说的时候，你不仅拒绝了一个任务，你还在拒绝一次理解业务的机会。产品经理不是全知全能的，他们需要技术视角的输入。反过来，技术也需要产品视角的输入。
分工是为了让专业的人做专业的事，不是为了让你成为盲目的执行者。
技术人的产品优势
工程师有产品经理没有的优势：你知道什么是可行的。
产品经理可以天马行空地构思功能，但你清楚实现的成本、风险、边界。这种理解，如果能前置到产品讨论阶段，可以避免很多无用功。
不是要你做产品经理的工作，而是用技术视角帮助产品决策。
从怎么做到为什么做
接到需求时，不要只问怎么做，先问为什么。
- 这个功能解决什么问题？
- 为什么这个问题重要？
- 有没有更简单的方案？
- 如果不做会怎样？
这些问题不是在质疑产品经理，而是在共同理解业务。理解越深，实现质量越高。
产品能力不是画原型
很多人以为产品能力就是画原型、写PRD。这些是工具，不是能力。
真正的产品能力是：理解用户、洞察需求、判断优先级、平衡短期和长期。这些能力，技术人同样需要，甚至更需要。
因为你每天都在和用户需求打交道，只是你把它当成需求而不是问题。
技术决策本质是产品决策
选择哪个框架、用哪种架构、怎么做扩展性——这些看起来是纯技术问题，但背后都是产品决策。
框架选型影响开发速度，影响功能迭代，影响最终交付时间。这些都是产品维度。技术人如果只从技术角度考虑，很容易做出技术完美但产品失败的决策。
从执行者到合作者
最好的工程师不是被动执行，而是主动合作。
你会告诉产品经理：这个功能实现成本很高，但如果我们换个思路，可以达到 80% 的效果，只需要 20% 的时间。
这就是产品能力。不是取代产品经理，而是用技术视角优化产品决策。
如何开始
下次产品会议，不要只带技术方案。带上这些问题：
- 用户当前最大的痛点是什么？
- 这个功能真的能解决痛点吗？
- 如果只能做一件事，应该做什么？
思考这些问题，不是越界，而是成长。