2017 年我从写代码转做项目，2020 年再转做产品。中间隔了三年，但真正的转变发生在某个具体的下午：我发现自己在评审会上，第一反应是判断「这个需求实现起来麻烦不麻烦」，而不是「这个需求对不对」。
那个下午之后，我给自己列了一份清单：哪些工程习惯要留，哪些必须戒。
要戒的
第一，用实现难度代替价值判断。
工程思维的第一个陷阱是：容易做的就重要，难做的就先放放。但产品的排序依据只能是价值，不是成本。成本高可以不做，但不能因为成本高就说它不重要——这两件事在会议上经常被混为一谈。
第二，追求「一次做对」。
写代码时，重构的代价可控；做产品时，一次错误的版本会烧掉半年和一堆人的信任。工程师习惯的「先做对再做快」，在产品上往往要先做最小可验证，再谈对错。
第三，把模糊当敌人。
工程师讨厌模糊，产品经理必须和模糊共处。用户说「要快一点」，这句话里没有数字，但你不能要求他先给一个数字再开始工作。你得自己提出假设，然后去验证。
要留的
第一，能读架构图。
这让我在和研发讨论方案时不会被糊弄，也不会提出物理上做不到的东西。很多产品经理的困境不是不懂业务，是不知道技术边界在哪，于是要么许愿，要么自我阉割。
第二，把「不确定」显式化。
写代码要处理边界条件，做产品要处理例外场景。习惯性地问「如果这里为空呢」「如果网络断了呢」，能把一个方案从 80 分推到可用。
第三，写文档的能力。
这是最被低估的一项。工程师写的文档强调准确，产品写的文档要强调可执行：谁在什么时候做什么，做完了怎么算完成。我见过太多需求文档写得很美，但没人知道下一步该干什么。
一句话
工程训练给我的是下限：我知道一件事最坏会坏成什么样。产品训练给我的是上限：我知道一件事最好能好成什么样。
两个都要。
这篇是旧笔记整理，写于 2024 年，2026 年重新校对。