上一篇文章发出后，有读者问“可以聊一下怎么转的吗，以及找产品工作这些，学哪些东西呢？”
这个问题其实就是研发转产品所要面临的最核心的三件事：怎么转、学什么、怎么拿到第一个产品机会。
我先说结论：不用着急去背那些产品方法论，也不用去学怎么画原型图。你有一个最大的优势就是你的技术经验和严谨的逻辑思维，你需要把你的这些技术优势翻译成你的产品能力，再去补齐用户、业务、表达、判断这些短板。
转岗前的第一步，先判断自己是不是真的适合转
产品不同于研发，虽然有交集，但大方向上还是不同的。你的转岗原因是什么？研发太累不想熬夜写代码？研发技术更新太快疲于追赶？AI马上取代研发？如果是因为这些，那产品岗也不一定适合你。产品实际并不轻松，而且这类相似问题在产品岗上实际也同时存在着。
研发需要电脑才能写代码，但产品摆脱了这个限制，有脑子就可以，你可能会时时刻刻都在琢磨一个产品方案，但也不得不承认，产品确实没有研发费脑子。
在转之前，可以先问自己几个问题：
- 是否愿意处理琐碎繁多的事情？
产品要做的事情非常琐碎，虽然主职是需求分析，但也要花费大量时间做竞品分析、处理工单、用户调研、汇报、演示等等，甚至有的时候需求分析可能只占一小部分时间。
- 是否愿意花时间理解用户和业务？
做研发时接收到产品确定的需求，主要的思考内容是技术方案，成熟点的程序员也会问为什么，但答案都是产品经理给的确定答案，接收后判断合理与否即可。但做产品要则考虑用户为什么提出这个需求，他的痛点到底是什么，这是不是伪需求，做这个有没有价值，这些都需要产品层层剥茧、深入挖掘。
- 是否愿意接受大量的沟通和协调？
做研发时的世界最纯粹，大部分时间只需要和电脑打交道，就算偶尔需要和人打交道，接触的也大都是和自己类似的程序员，有逻辑思维、在一条线上、好沟通。但做产品时大部分时间就要变成和不同的人打交道，有产品、实施、用户，甚至有些人连基本常识都不具备。产品要做的就是无论面对哪些人都能聊清楚、达成共识再推进。
- 当一个需求没有标准答案时，是否愿意先做判断、做取舍、再承担结果？
这种情况非常常见，没有人能给出标准答案，我们要做的就是深入分析、衡量利弊、做取舍，然后承受这个决定产生的结果。
如果这些你的回答都是愿意，那我们可以继续往下看。
接下来，我们说下怎么把我们的研发经验转换成产品优势
很多人可能担心，自己没有产品经验，转产品了岂不是从零开始了？
别担心，你的研发经验就是你最大的底牌，你只需要把它换一个表达。做研发时我们说“我会用某某技术栈”，做产品后我们就要翻译成产品语言了。
比如，你懂系统逻辑，说明你能拆解复杂问题；你懂开发成本，说明你能判断需求边界、投入产出是否合理；你给快速思考出实现方案，说明业务熟悉；你和研发能顺畅沟通，说明你能降低协作成本；你经历过方案设计、上线以及交付，说明你知道一个需求从想法到真正落地需要经过哪些环节。
研发转产品，面临的最大的一个坑也是最大的一个挑战，就是思维转换。不用管你之前的技术多厉害，记住不要深陷“怎么实现”的泥沼里。做产品先要问的是：为什么做、给谁做、解决什么问题、值不值得做。
如果想转产品，请从这一刻起，开始练习用产品思维思考事情。
当然，还要补齐我们的短板
转产品，我们可以优先补这五大块：
- 用户理解。知道用户是谁，在什么场景下会遇到什么问题。不同的产品模块不同，可以从你现在负责的模块着手。
- 需求分析。不是简单的用户想要什么，而是拆解出需求背景、用户群、业务痛点、目标、流程、边界以及规则。
- 业务判断。我们不是搬运工、传声筒，产品要能识别需求真伪、判断优先级、投入产出以及取舍。
- 产品表达。产品要会的PRD、原型图、流程图，都不是为了体现有多专业，而是为了让团队成员间对齐理解，避免传达有偏差。
- 数据意识。一个需求上线不代表着结束，你还要知道看什么数据，怎么判断这个需求有没有价值。
原型图、流程图各种工具怎么学，需不需要买课？不用买！这些都是工具，都是表达手段，在AI横行的今天，你可以直接指导AI画出高仿真的原型交互图（skill调教的好你甚至可以直接出最终交互取代前端，当然大厂至少在现在还不敢这么做），表达更准确、更完整、更流畅。
第四，优先尝试内部转岗
这也是我当年走的路。我们要清楚的是，转岗时我们的优势还是研发经验。内部的那些产品领导很可能知道你、就算他们不知道、也有多种渠道轻松获取到你的信息。这个时候他们更多看重的就是你的研发经验、你熟悉企业内部的产品功能，以及你的这些经验将给产品带来的益处。
内部转岗可能没那么顺利，甚至可以会给你提出一些附加条件，可以酌情考虑。我转岗时，甚至同意了再过半年后才正式转，并且在这半年期间内身兼三职，带团队的新负责人、出技术方案以及接手的产品工作。
你可以找你的产品经理或者其他相熟的产品经理，打听下产品部门是否正好有空缺，这会是绝佳机会。
如果刚好你负责的产品经理离职，你能争取到你正在负责的产品岗，那你的产品路对你来说将会非常轻松。
第五，外部求职，请抛弃之前的技术简历
做研发时，我们可以说“精通Java、redis”，但投产品岗时，我们则要侧重说：参与过什么业务，解决过什么问题，和哪些角色协作过，是否做过需求拆解、流程优化、数据分析、项目推进，以及最后产生了什么结果。
面试时，也不要只强调“我懂技术”，而是要表达：我能理解研发实现成本，也能站在用户和业务目标上做取舍，所以我可以在产品和研发之间搭起沟通桥梁。
外部求职通常不容易成功，一个企业不太敢投这么大赌注到培养一个没有产品经验的程序员身上，他们更多怕的是研发经验使思维固化，无法转换到产品思维。
如果外部求职，可以考虑偏技术类产品的产品岗，比如开放平台，这种和API相关，产品功能上就不得不体现出技术相关特性，使用者也是研发类人员。这类岗位更倾向于有研发功底的人，不了解技术的人很难设计好这类产品的功能。
最后，还是给个小建议：不要停留在想，要行动起来
如果决定要转了，就马上去了解下产品的工作内容，看看是不是喜欢；如果有相熟的研发转产品的人，去聊聊他的转岗感受。
从你负责的产品入手，找一个你最熟悉的业务问题，练习拆解出用户背景、业务痛点和需求分析。写一份完整的需求说明，包括用户群、业务背景、痛点、存在问题、实现目标、流程、原型、规则和验收标准，期间可以参考学习你的产品经理所写的详细需求分析文档。
这些东西都不是一朝一夕能掌握的，在这期间要尝试内部转岗，不要等万事俱备，只欠东风。东风不一定什么时候来，要时刻等东风，东风来了马上抓住，干中学绝对可行。
记住，研发转产品，不单纯是岗位的变化、工作内容的变化。最重要的还是看问题方式的变化。
要时刻记得不要一上来就想“怎么实现”，多问问自己：为什么做、给谁做、解决什么问题、值不值得做。
希望我的经验给能帮你解一些惑。还有哪些困惑或者想了解哪些内容，可以留言给我。
 本书序言)
