我，创始CPO，40%时间写代码

作为创始CPO，我40%的时间在写代码。我感到既强大又内疚。

这感觉非常高效，但随着我花更多时间写代码，我被拉入一个更深的内心对话：我是否在最好地利用我的时间。

既然我能写代码，问题变成了：我该不该写？

在大公司里，"CPO该不该写代码"通常不是真的在讨论写代码。它关乎信任、控制、自我，所有那些东西。

在这里感觉更简单：

我对如何平衡这个问题没有明确的答案，但这种张力是真实的，我以前从未真正感受过。

1、我在客户方面做什么

我有两个探索方向正在进行，我觉得这很标准，但时间尺度已经压缩了太多，我不得不重新评估。

一个是持续不断的客户电话节奏。杂乱且重复，聚焦于入职或特定问题。你会听到半成型的需求，听到变通方案，听到"我不知道，就是很烦人"。随着时间的推移，你开始从不同角度听到同样的东西。

另一个是一项生成性研究，旨在揭示客户完整的端到端工作流程。这个更慢，我之所以做它是因为我对核心工作流中的差距和障碍有假设。我不想交付50个不同的旋钮和杠杆，而这些可能被一个更好的核心工作流所取代。

再说一次，平衡非常重要。

不幸的是，虽然在访谈综合方面有进步，但与客户交谈并不会比以前快多少。你仍然需要提出行为问题并控制你的偏见，这意味着真正的对话。

客户是真实的人，他们的日程很忙。在早期阶段，你不能随时叫来一个20人的研究队列。

这绝对是目前限制我的瓶颈。

另一方面，AI确实改变了探索的其他方面。像如今许多/大多数产品经理一样，我给自己建了一个客户门户，通过一组Claude技能集中管理上下文。

我从以下来源拉取数据：

它创建汇总和摘要，这样你可以为每个客户生成一份客户概览文件，然后进入Notion供我们的客户成功团队使用。此外，还有足够的上下文可以运行跨客户分析，并从许多不同角度获得有意义的洞察。

我觉得一件非常酷的事情——我可以把我当前研究中的所有问题指向所有过去的访谈文字记录。来自我、来自客户成功团队或来自销售的文字记录。这加速了生成性研究，也避免了当客户已经向团队其他人解释了你在问的一切时那种拍大腿的尴尬。

当AI摘要与客户成功团队的直觉一致时也很有趣，而当它不一致时就更有趣了。

我认为这类事情是作为产品人今天为了跟上交付节奏而必须做的事情的一部分。

当我在等待生成性研究轮次产生足够信号的同时，我使用快速的工具和与客户成功团队的聊天来为近期的待办事项提供信息。而且我只开始做那些显而易见的"是"和双向门——可以改变而不惹恼客户群的有影响力的事情。

这意味着没有大规模的UX变更，没有高风险的战略举措。这样我们可以保持快速交付的节奏，但对更大的工作更加审慎并以研究为依据。

例如，我交付的一个功能让用户可以用自己写作的示例来训练Drumbeat，然后从个性化声音库中选择。原因很简单：很多"AI写作"读起来仍然像AI写作，人们能感觉得到。这是一个显而易见的"是"。

另一件事是一个判断引擎，评估我们的联系人匹配并根据最先进的公关研究进行重新排序。糟糕的匹配不仅浪费时间，还会侵蚀信任。工作流程没有变化，只是匹配更相关了——这是一扇双向门。

我之前写过一篇博客，其中有一个概念引起了联系我的一些人的共鸣——AI加速的步伐给了你更多思考的空间。

我认为这就是它的意思——快速交付那些显而易见的"是"和双向门，但花时间用标准的以客户为中心的探索实践来充分理解大事。

我写代码是对我时间的最好利用吗？

在目前的团队配置下，我感觉自己贡献了大约 20–30%的开发速度，这不算少。在早期创业公司中，势头真的很重要。

但我也意识到这可能只是一个阶段，它之所以合理仅仅是因为团队规模、因为新鲜感、因为肾上腺素，因为我能看到即时的影响。一旦我们招聘了创始工程师，我预计这种权衡会改变。然后在3个月、6个月后又会再次改变，因为瓶颈会不可避免地不断移动。

如果你也处于类似的位置——创始人、产品、工程——我真心想听听你的视角。

你是如何找到"这是杠杆"和"这是一种逃避更难工作的非常高效的方式"之间的界线的？如果你是我，你会继续写代码，还是强制施加不同的约束？

汇智网翻译整理，转载请标明出处