Product Engineer

产品工程师（Product Engineer）是一名对问题负责、而不仅对实现负责的软件工程师。普通工程师拿到一份规格说明，把它做好。产品工程师会追问这份规格说明是不是该构建的正确东西，会与有这个问题的用户交谈，决定真正要交付什么，然后才写代码。他把产品经理和工程师合并到一个脑袋里。产出不是「按规格说明做出来的功能」，而是「用户的问题，被解决了」。

这个角色之所以存在，是因为产品死在交接处。产品经理写一份规格说明，工程师严格照做，三周后却没人用这个功能，因为规格说明漏掉了一个只有盯着代码的人、或用户本人才会发现的细节。产品工程师在构建途中就能抓住它，因为两端都归他。按定义，他并不比普通工程师更资深。他的接线方式不同：他在意的是指标动起来，而不是工单被关掉。

一个说明为何融合更胜一筹的具体例子：某 SaaS 团队完全按设计交付了一套引导流程。激活率纹丝不动。产品经理怪构建，工程怪规格说明，等到有人去验证真正的假设时，一个月已经没了。换成产品工程师，他会在三天内交付一个更薄的版本，看着五个真实用户卡在第二步，并在冲刺结束前重写第二步。同样的人手，十分之一的周期时间，因为既没有交接，也没有甩锅回路。从「用户卡住了」到「在生产环境修好了」的路径，全在一个脑袋里跑完。

这正是 Wavect 实际工作中很大一部分内容。我们大多数的兼职联合创始人和 CTPO 合作，本质上就是换了名字的产品工程：一个操盘者负责界定 MVP、与你的用户交谈、交付代码，而不是一个产品经理、一个设计师加三个承包商在玩传话游戏。诚实的取舍：产品工程师很难招，而且无法线性扩展。你无法在一个产品上堆二十个，而现有的那些人很贵，因为这种组合很稀有。创始人常犯的错误是招了一个对用户毫无兴趣的出色程序员，然后纳闷为什么路线图里全是没人要的优雅功能。解法不是在上面再加一层更厚的产品经理，而是一个宁愿和客户聊天、也不愿去调构建流水线的工程师。相关：全栈软件开发。