多伦多 SaaS 创业者怎样把 build in public 真正拉到决策层？3 条教训

Reddit 的 SaaS 板块里最近出现了一个新动作，有人开了一个子项目叫 r/SaaS v2，开始把整个社区产品的迭代过程以月为单位公开出来。这位发起人在第一个月公开了一些过去没人愿意讲的细节，从 issue triage 到 schema migration，从营销节奏到付费墙讨论。这位创始人把项目运营权开放给所有愿意反馈的人，每个公开迭代节点都贴出对应的数据图表。

过去我们说 build in public 时常把它当成「让产品透口气」的姿态。这一次 r/SaaS v2 给出的版本比过去单方向输出更狠，第一周就把会员体系、付费转化路径、邮件推送节奏这类敏感信息一起公开出来。这位发起人过去做过两次失败的 SaaS 项目，他私下抱怨说失败的原因几乎都是产品在某个阶段悄悄离开用户，自己单方面决定下一步。这一次 r/SaaS v2 的核心方法论是把每一个决策点放进公开议题，让社区投票的方向决定一半以上的下一步动作。

从方法论上看，这套玩法的关键是建立「公开决策 + 实时反馈」的回路。第一周的 12 个决策里有 9 个被讨论区推翻或者修改，发起人在 7 天后承认这种节奏比自己想象的更累。一位长期做社区运营的产品总监私下说过一句实话，能扛得住这种公开度的人，过去三年他只见过不到五个。失败案例里最常见的是创始人在第一个月就因为被过度关注而停掉迭代。

这件事的真正教训在于 r/SaaS v2 第一周公开的不是「成功方法」，而是被迫公开讨论过的「失败决策」。从方法论上看，这种决策日志式的做法有几个关键动作，每个迭代点必须贴原始数据截图，团队内部争议必须匿名化处理，反对的观点不能从公开场合抹掉，最后一个动作是任何决策必须有可回滚的兜底。这套动作从工程文化上要求创始人允许公开承认失败，这点从创始人的情绪管理上是真正的考验。

对国内 SaaS 创业者来说 r/SaaS v2 这种动作最大的借鉴意义在于决策日志本身的颗粒度。一位国内做 SaaS 的产品经理看了这件事之后试过一次，把每周决策日志公开发在产品公众号，反馈比预期好，但带来一个真实代价是任何错误都会被放大。这位产品经理私下承认，把决策日志写得越具体越接近真实状态，工程团队和运营团队之间的撕扯反而越激烈。这跟 r/SaaS v2 的核心方法论一致。失败案例可以公开，决策摇摆也可以公开，这是过去几年见过最有判头的方法论账本。

创业找资源，上乌鸦部落。