Fractional CTPO 对比一位 Fractional CTO 和 CPO：何时一个脑袋更优，何时该拆分

一位 CTPO 把一位 CTO 和一位 CPO 的职责扛在一个脑袋上：做什么、怎么做，以及是否解决了客户的问题。本文要回答的不是合并角色是否真实。它是真实的。问题在于一个脑袋何时胜过两次招聘，以及这个判断在哪一刻翻转，因为把单一 CTPO 留得太久，和拆分得太早一样，都是昂贵的错误。

如果你读过我们关于何时招 fractional CPO 的框架，这篇是它上面的一层：在你决定是否真的需要把角色拆开之前，你要先做的判断。

合并角色为何存在

在 product-market fit 之前，一家初创公司通常既养不起两个高管职位，也承受不了一个 CTO 和一个 CPO 每周二为优先级争执的内耗。合并角色的存在就是为了收起这个循环。决定结账改版比仪表盘更重要的那个人，同时也决定它如何架构、能否在本 sprint 交付。没有交接、没有翻译层、没有两个高管自我之间的拉锯。在 PMF 之前，这道协调税是 runway 浪费的最大来源，而 CTPO 把它去掉。

这也是 Wavect 平时的工作方式，这就是为什么本站把 fractional CPO 描述为合并角色里仅产品的那一片，把 fractional CTO 描述为仅工程的那一片。fractional CTPO 是完整的整体。

何时一个脑袋更优

• PMF 之前或早期牵引。产品问题和构建问题仍是同一个问题。把它们拆开会造出两个日历，任何东西交付前都得先同步。
• 小团队，约八名工程师以下。工程管理还不是全职工作，所以 CTO 会被闲置，而 CPO 会在等一个 CTO 还没配人的构建。
• Runway 紧张。一份资深 retainer 而非两份，是合并脑袋与一轮你还无力承担的招聘之间的差别。
• 创始人想要一条问责线。当某样东西没交付时，你想问一个人，而不是问两个能互相推诿的人。

"合并的 CTPO 不是你因为养不起两个人而退而求其次的妥协。在 PMF 之前，它是更好的形态，因为这么早，产品判断和可行性判断本就不该分处两个房间。"

何时该拆成一个 CTO 和一个 CPO

当两件事同时成立时，这个角色就该拆分：工程管理已经成为一份全职工作，通常超过八名工程师，而产品再也无法等待每周一批决策。过了那个点，一个人同时承担两者就会变成瓶颈，而非捷径。架构工作需要每天的关注，路线图也是，而没有任何单一脑袋能给两者它们如今所要求的每日在场。

创始人常犯的错误走向相反方向：迷恋一个脑袋的便利，把 CTPO 留得远超拆分点。缓解之道是一位知道何时该停止当 CTPO 的 CTPO。一个不规划自己被替代的合并操盘者，就是错误的合并操盘者。及时拆分意味着在瓶颈固化之前、而非之后，招一位专职 CTO 和一位专职 CPO。

合并脑袋对比两次招聘：决策表

单点故障问题，以及我们如何处理

任何合并角色诚实的取舍都是：一个人成为单点故障。他一去休假，你的产品与工程领导就同时暂停。这是拆分最有力的论据，而且是真的。

我们运行合并角色的方式正是围绕这个风险搭建的：你雇的是两位创始人，而不是一名自由职业者。一位是你的 CTPO 对接人，另一位让架构对照真正可构建的东西保持诚实。合并职责落在一条问责线上，但不落在一个日历上。这也是 Wavect 对比另一家 fractional CTPO 中讲到的区别：大多数单人 CTPO 是一个人、一门专长，在产品或工程上强，在另一门上较弱。

奥地利创始人该如何决定

1. PMF 之前、runway 紧张、团队小？一个合并的 CTPO。产品判断和构建判断是同一个判断。若预算是约束，就通过 fractional co-founder 模式来跑，每周 400 欧元。
2. 早期牵引、想在明确范围内获得合并职责？一份 fractional CTPO retainer，并从第一天起规划好、记录好拆分。
3. 工程管理已成全职工作、产品等不了一周？拆分。招一位专职 CTO 和一位专职 CPO。一位好的 CTPO 会帮你主持这轮招聘。
4. 只有一侧真的有缺口？不要合并。选适合的那个单一角色，fractional CTO 或 fractional CPO。
5. 不确定你这个阶段的界线在哪？预约一次通话。我们会直说，哪怕诚实的答案是拆分、并招两位不是我们的人。

关于背后的角色定义，见词汇表里的 CTPO、CTO 和 CPO。这里的合并角色位于仅工程的 fractional CTO 和仅产品的 fractional CPO 之上，并与扩张前的 fractional co-founder 共享同一套交付模式。