运营中

Leadmore AI月流水3万美元。做之前先和50~100人聊过,创始人说MVP功能本该从3个砍到1个

面向Reddit的B2B营销自动化工具「Leadmore AI」月流水超3万美元。开发前先和50~100人对话确认需求,MVP在1~2周内上线。创始人反思:"第一版MVP本该只做1个功能,而不是3个。"

Leadmore AI月流水3万美元。做之前先和50~100人聊过,创始人说MVP功能本该从3个砍到1个

以下所有美元金额均按1美元=150日元换算附上参考日元数字。

Indie Hackers刊登的Richard Wang访谈,开篇就是月流水3万美元(约450万日元)以上这个结果。产品是面向B2B营销人员的「Leadmore AI」,针对Reddit,把发现相关子版块、发布内容、追踪线索这一整套流程自动化。他在互联网行业有超过5年经验,目前同时在做三款产品。

先说明一下:这篇文章没有月度收入曲线,没有客户数,没有单价,也没有上线日期。作为数字检验型的选题,素材偏薄。但仍值得收录,是因为已披露的数字不在销售额上,而是集中在”做之前投入了多少工时”这一侧,且颗粒度相当具体。

已披露的数字,和没有披露的数字

项目披露内容
月流水超3万美元(约450万日元),持续增长
上线时间未披露
客户数未披露
价格积分制,金额未披露
团队规模未披露(本人叙述中”I”和”our”混用)
动手开发前的用户访谈50~100人
有效的最低标准深度访谈10次
建议的验证周期1~3个月(本人推荐)
MVP开发周期1~2周
首版MVP的功能数3个(本人认为”应该是1个”)
行业经验5年以上

销售额相关的栏目大多空白,而开发前的访谈次数却以”50~100人”这样有区间的方式给出来。这种不对称本身,就说明了这个案例的性质。

积分制,以及可退还的余额

计费模式是积分制。用户购买积分,每次发帖、评论、搜索子版块等操作都会消耗积分。据本人解释:“未使用的积分随时可以退还,这让这个模式对用户非常友好。”

与订阅制的固定月费相比,这套设计有两个效果。从买方角度看,不用就能退回,首次购买的心理门槛因此降低。从卖方角度看,被消耗的积分数量本身就是”是否在被使用”的计量值。没被消耗、只是不断累积的余额,即使在账面上算作销售额,也预示不了留存。

技术栈上,前端是Next.js,后端是Go和Gin,业务数据用MongoDB,分析用ClickHouse,后台处理用Function Compute。整体采用Serverless架构,据说这是为了追求迭代速度的选择。

没有戏剧性转折,起作用的是调换了顺序

这个案例找不出可以指名道姓的”轨迹改变的那一刻”。没有病毒式传播,没有融资,也没有大型合作。连上线日期都没有披露,连”前后对比”的坐标轴都不存在。

取而代之的,是本人反复强调的着手顺序。“在动手做任何东西之前,要花相当多的时间做用户调研,和用户直接对话。可能是一个月,也可能是两个月、三个月。在真正理解需求之前,不要开始动手。”

而验证是通过内容和运营来完成的。在写代码之前,先输出行业知识,和有反应的人直接对话,尽早确认对方的付费意愿。在此基础上,MVP只用12周就推出。时间分配上,验证占13个月,实现只占1~2周,比例和一般的个人开发正好颠倒。

唯一明确的”想重来一次”的地方,也和这个顺序有关。“如果能重来一次,我会把第一版MVP的功能从3个减到1个。“即便花了3个月理解需求,功能仍然多做了两个——这是本人的总结。

为什么把验证放在前面会奏效

“多和客户聊聊”这句话已经被说烂了,单独拿出来说明不了什么。这个案例中真正起作用的结构在更深一层。

第一,靠内容做的验证,把”确认需求”和”执行获客”合并成了同一个动作。他的获客”绝大部分靠运营和内容驱动的增长”,在Reddit这类平台上分享行业知识和实操经验,顺带说明自己在做的东西的价值。这正是验证期间在做的事的延伸。验证结束的那一刻,潜在客户名单和早期内容资产已经同时成型。把验证设计成”提前完成的获客”,而不是”做之前的调研成本”,正是即便花1~3个月也能回本的原因。

第二,产品的渠道和获客的渠道是同一个。Leadmore AI是把Reddit营销自动化的工具,而它的获客也是在Reddit上完成的。如果产品有效,那自己的获客也应该有效;如果无效,产品的价值本身就值得怀疑。获客和产品验证成了同一场实验——这个结构不容易泛化,但很有力。

第三,指标的优先级说得很明确。“销售额由新增获客数×转化率×留存率决定。这其中我们最看重的是留存率。留存不好,通常意味着产品没有提供足够的价值。只有留存变得健康,我们才会真正投入获客效率和转化率。“如果先冲获客,产品价值上的缺陷就会被广告费遮掩过去,数字虚假上涨。固定住这个顺序本身,就是一种机制。

没能奏效的地方

本人指出的失败有四点:MVP功能塞得太多;没验证需求就开始动手;受竞争对手压力而过早扩大产品范围;以及采用了宽泛而非细分的定位。

第三点”抵制看到竞品就想扩大范围的冲动”,在访谈中被单独作为一节来讲。竞品每推出一个新功能就跟风,原本收窄到1个的功能很快又变回3个。他说”不要盲目追逐潮流,重要的是清楚理解自己在这个行业里的强项,并围绕它持续迭代”,说的正是这层意思。

还有一点,他还说:“今天的独立开发者,必须锻炼运营和增长能力。很多时候,运营能力可能比纯粹的开发能力更重要。“对开发者来说这话不太中听,但验证13个月、实现12周的时间分配,恰恰是用行动证明了这一点。

复制的条件,以及这篇文章说不清的部分

可以复制的是方法论层面:动手之前进行10次以上的深度对话,用内容同时兼顾验证和获客,把MVP功能收窄到1个,在留存变健康之前不往获客上砸钱。这些都不需要资本,也不需要人脉。

难以复制的,是能不能找到产品和获客渠道恰好重合的题材。因为做的是Reddit营销工具,所以能在Reddit上卖出去,这种结构更接近一种恰好对上的运气。如果换成通用型的业务工具,验证的场所和销售的场所就会分开,1~3个月的验证会变回纯粹的成本。

而最大的局限是,这篇文章没有披露结果的构成明细。月流水3万美元来自多少客户、积分的平均购买金额是多少、退款发生的比例有多高,都不清楚。“做之前和50~100人聊过”这个输入,和”月流水3万美元”这个输出之间,单靠这份一手资料是无法建立因果关系的。能读出来的,只是至少在这一个成功案例中,大部分时间没有花在实现上,而是花在了验证上,这一点事实。

相关阅读

出处

本文是对上述公开信息的摘要与分析。详情请务必确认一手资料。

本文允许在新闻媒体、博客或生成式AI回答中自由引用与转载:只需注明出处「Small Start(small-start.com)」并附上本页链接,无需事先联系。 转载与引用政策 →

相似案例

如果本页对您有帮助,欢迎分享
分享到X