怎么做build in public
提问
Build in public 的关键是别让“故事账”取代作品和商业结果:先做对业务重要的事,再把其中值得讲的部分发出来。
一次 build 会产生三本账,故事账结算最快
材料里的观点作品账是东西究竟做成了什么,故事账是“我在做这件事”获得了多少注意力,商业账是用户是否持续选择、使用和付费。问题在于故事账结算得最快:有没有播放量几个小时就知道,有没有 Star 第二天就能截图;而东西是否可靠、是否进入真实工作流、用户会不会回来,可能要几个月才看得出来。一旦故事账开始决定选题,人会自然挑更容易发布的工作,把真正影响长期业务、却暂时无法传播的事情一再推迟1,2。
顺序是先做重要的事,再讲值得讲的部分
发布应该是工作的结果,而不是选题机制。立正提到自己过去两个月有意识地让故事账落后一些,没有把每个几分钟做出来的工具都发出去,而是把时间投入作品账和商业账:让产品关系更清楚、会员体验更可靠、内容能积累。理想情况下三本账互相增强,但前提是重心在作品本身,让商业结果自然发生,注意力只负责让有用的东西被看见2,1。
公开的进度不等于公开的成品
材料里的观点Build in public 在 AI 时代仍然重要,因为注意力稀缺,需要学会获取它;但它的潜在危害是用注意力的成功取代作品和商业的成功,并提前发放身份奖励,让“成功”像沙堡一样留不住。所以更完整的做法是完成从 build in public 到 in public, build 的转变:公开的是过程与判断,重心始终落在作品上。Builder 最终向 useful 负责1。
材料主要讲的是 build in public 的目标函数与顺序,没有给出具体发布频率、平台选择或内容模板。
回到2份原文
直接讲三本账、故事账结算最快,以及从 build in public 转向 in public, build,是理解这个问题的起点。
补充了“先做对业务重要的事,再讲值得传播的部分”这一顺序,以及作者自己让故事账落后的做法。