近年来，许多科技公司的文化发生了明显的转变，转向更加以产品为导向的文化。这种转变催生了新的角色，例如产品经理、产品设计师，以及最近的产品工程师。虽然我不认为这些新角色本质上优于典型的工程师和设计师，但它们的适用性取决于具体的工作环境和公司要求。每个角色都拥有独特的优势，使它们更适合特定的环境。

工程师与产品工程师

在我看来，这两个角色之间的主要区别在于它们的用户关注点。传统上，工程师主要专注于解决技术任务，确保其稳健性和可扩展性。虽然这种方法对某些公司有意义，但那些非常重视为用户提供价值的公司发现产品工程师的角色更合适。产品工程师具备普通工程师的许多素质，但我们希望他们能够了解用户的需求，从而找到更好的方法。换句话说，他们的目标不仅仅是编写代码，而是利用代码来满足用户的需求。

一个例子

请允许我举一个 Mercadona Tech 的例子。我们最近遇到了一个挑战，涉及绘制 Mercadona 商店的布局，以便在更短的时间内为客户准备在线订单。该团队包括设计师、产品经理、用户体验专家和工程师，花了几天时间来理解这个问题。提出了多种解决方案，例如使用 Excel 工作表或记事本。然而，一个引人注目的想法涉及利用 Wi-Fi 三角测量技术来生成商店地图。虽然一些工程师熟悉这项技术，但团队的其他成员却不熟悉。虽然 Excel 工作表可能就足够了，但它能解决所有问题吗？是否会如此方便和高效？它能满足用户的所有需求吗？能满足所有商家吗需要？我们希望产品工程师能够提出并与团队讨论这些问题来满足用户需求，而不仅仅是完成分配的任务。

我们可以改变我们的工程师吗？

现在我们了解了产品工程师的角色以及他们增强产品的潜力，一个相关的问题出现了：如果我们的团队中目前没有产品工程师怎么办？工程师有可能转型为产品工程师吗？我的回答是肯定的，只要满足两个条件。首先，您的公司必须相信工程师有能力创造性地为用户问题提供技术解决方案，而不是仅仅依赖于预先定义的解决方案。其次，作为产品团队，我们必须在整个过渡过程中支持和协助工程师。虽然第一个条件是我无法掌控的，但我可以建议 3 个主题来帮助作为 PM 实现这一转变。

清晰的产品愿景

• 作为产品经理，为团队提供有关当前问题的广泛背景至关重要。提供关键绩效指标 (KPI) 的清晰愿景，您可以通过该指标衡量改进情况、这些 KPI 的当前状态以及解决问题的预计影响。虽然我个人不喜欢路线图，但针对特定主题的清晰产品策略可以帮助团队做出更好的技术决策。您可以通过启动会议、小组动态或回顾或计划会议期间的反复讨论向团队传达这种背景。

协作环境

• 促进团队内部的开放式沟通，鼓励所有成员积极参与讨论与工作相关的话题，包括实施疑虑和解决方案的可行性。当工程师参与配对会议时，请考虑促进设计师和前端开发人员之间的配对会议，以改进初始设计实现。同样，后端开发人员和产品经理之间的配对会议可以提高指标的质量。为了将工程师转变为产品工程师，我们必须通过向他们提供必要的问题背景来赋予他们解决方案的所有权。

用户研究和反馈

• 促进工程师和用户之间的直接协作，让他们参与研究、发现和指标分析。对于工程师来说，获得对问题的第一手了解并拜访用户以培养同理心并确保以用户为中心的解决方案至关重要。例如，在 Mercadona Tech，我们实施了一项措施，通过每周拜访用户一次来促进这一过程。我们的用户在物流中心工作，使我们能够密切观察他们面临的挑战。虽然这可能看起来效率低下，并且每周都会花一些时间来分散我们的注意力，但从长远来看，它被证明是有益的。有了这些额外的背景，我们就可以提供更好、更快的解决方案。

长话短说

• 优秀工程师+产品背景=产品工程师
• 避免产品经理承担问题的全部责任，因为他们无法知道所有可能的解决方案。向工程师委托并提供背景信息。
• 具有清晰产品愿景、将用户置于协作环境中每个解决方案中心的团队将成为公司中最有价值的资产，为用户增加价值并实现业务满意度。