即刻App年轻人的同好社区
下载
置顶关于我，现 Dora Ops Head(core member)，之前在 AFFiNE 做增长负责人。一直在研究如何用最低成本做最陡的AI 产品增长曲线：获客、留存、付费、飞轮、商业化的坑全都踩过～ 也融过资，做过产品
目前Base在杭州，做出海 / 有时间会接咨询/即刻for生活和工作闲思 / idea grows when shared
月预算9000美金，关键结果：
1. 用户1年增长 30w→200w，全球社区用户增长20w+
2. dora.ai和CapCut共同入选2024年出海流量榜top50
3. 产品 ARR 从 $xx w → $xxx w（同比 +270%）
4. 网页曝光 50w → 540w/月
5. 付费CAC 由50降低12美金（ads做到14美金）
6. LTV/CAC = 9，远大于行业标杆3
7. AFFiNE时期，2个PH日榜第一, 2个周榜第一，SEO 0-1做到百万曝光。
目前Base在杭州，做出海 / 有时间会接咨询/即刻for生活和工作闲思 / idea grows when shared
月预算9000美金，关键结果：
1. 用户1年增长 30w→200w，全球社区用户增长20w+
2. dora.ai和CapCut共同入选2024年出海流量榜top50
3. 产品 ARR 从 $xx w → $xxx w（同比 +270%）
4. 网页曝光 50w → 540w/月
5. 付费CAC 由50降低12美金（ads做到14美金）
6. LTV/CAC = 9，远大于行业标杆3
7. AFFiNE时期，2个PH日榜第一, 2个周榜第一，SEO 0-1做到百万曝光。
11 02
校内网崛起，是因为它抓住了人生第一次社交关系迁徙：高中升大学时，旧的人际网络断裂、需要在新校园重建社交；
但四年后，当用户迎来第二次迁徙——毕业进入社会时，校园场景消失，关系结构再度重组，而校内网没能承接这批用户的新社交需求，用户出现断崖下跌，所以做了人人网
当然最后也失败了，因为微信出来了，做了最后一档子事，之后社交关系的越迁就不会出现了。
每一个档口的档口期很重要，档口期越短，关系沉淀越浅，用户迁徙成本就越低，老产品的留存也越差；真正稳固的社交产品往往建立在长周期、高沉淀的关系上
但四年后，当用户迎来第二次迁徙——毕业进入社会时，校园场景消失，关系结构再度重组，而校内网没能承接这批用户的新社交需求，用户出现断崖下跌，所以做了人人网
当然最后也失败了，因为微信出来了，做了最后一档子事，之后社交关系的越迁就不会出现了。
每一个档口的档口期很重要，档口期越短，关系沉淀越浅，用户迁徙成本就越低，老产品的留存也越差；真正稳固的社交产品往往建立在长周期、高沉淀的关系上
3 00
第一次拿new money 的人，似乎老喜欢比谁的投后估值高、融资额大，好像越大越牛逼。
实际公司经营数据差的离谱，毛利低到负，回报周期根本打不平，贴钱买量做虚荣指标，一问ltv/cac不到1。
实际公司经营数据差的离谱，毛利低到负，回报周期根本打不平，贴钱买量做虚荣指标，一问ltv/cac不到1。
5 00
最近聊机构，好机构的vp, par确实framework更好一些，会问他们最关注的问题，几轮下来就迅速收敛到问题本质。这是非常好的能力，猜测来源于super deals 的经验抽象：
1. 知道哪些变量决定成败
2. 知道哪些red flag不能忽视。
1. 知道哪些变量决定成败
2. 知道哪些red flag不能忽视。
3 00
今天的一些思考：
Senior investors都是老登，时间极其宝贵，耐心少，attention非常稀缺。
Pitch需要在10页讲清楚：
1. 终局 愿景是什么
2. total addressable market有多大，我们能吃掉多少share
3. 面向终局的关键路径是否清晰
4. 为什么只有我们能实现。
多留意senior的问题，了解问题背后的目标是啥。因为Senior也有knowhow和过去大deal的路径依赖，大多数问题其实往往是在填充他路径依赖的思考和论证点：
1. 你讲的故事是否符合他们的世界模型
2. 你的路径是否能跑通他们熟悉的成功范式
3. 你的壁垒是否能穿越周期
4. 你的节奏是否资本效率足够高
Senior investors都是老登，时间极其宝贵，耐心少，attention非常稀缺。
Pitch需要在10页讲清楚：
1. 终局 愿景是什么
2. total addressable market有多大，我们能吃掉多少share
3. 面向终局的关键路径是否清晰
4. 为什么只有我们能实现。
多留意senior的问题，了解问题背后的目标是啥。因为Senior也有knowhow和过去大deal的路径依赖，大多数问题其实往往是在填充他路径依赖的思考和论证点：
1. 你讲的故事是否符合他们的世界模型
2. 你的路径是否能跑通他们熟悉的成功范式
3. 你的壁垒是否能穿越周期
4. 你的节奏是否资本效率足够高
11 10
之前搞一个finance advisor，得花大概100+credits。因为产品不可避免的熵增导致 以语言描述产品需求的指向性极差，又要自己去买模型和算力，配置api_key（担心泄漏）, 集成database, tables，做auth，还要配置pwa
6个月后再用lovable，提升极大。支持visual edition，能局部选中页面模块和控件进行二次编辑，输出app默认配置 Gemini2 flash api_key（安全封装）, 以及登入登出auth，又集成storage, edge function，database和data analysis看板。
To myself app的开发阻力被极大降低。
准备再用用antigravity，再来返一个感受。
6个月后再用lovable，提升极大。支持visual edition，能局部选中页面模块和控件进行二次编辑，输出app默认配置 Gemini2 flash api_key（安全封装）, 以及登入登出auth，又集成storage, edge function，database和data analysis看板。
To myself app的开发阻力被极大降低。
准备再用用antigravity，再来返一个感受。
4 00
Wiki在”管理”这个关键词对带宽的定义是manager需要直接管理的员工数量。合适的带宽数在7-9人，这代表一个manager对信息节点、量级最高效的处理范围。
人多就会增大信息链接节点，阻碍信息的传播和流通。人不变但层级增多，组织结构的效率就会严重依赖各层级代表的效率。
组织架构可以通过更改带宽、层级数量，裁撤低效的个体，来影响信息传递的效率、决策反馈的路径和时长。
人多就会增大信息链接节点，阻碍信息的传播和流通。人不变但层级增多，组织结构的效率就会严重依赖各层级代表的效率。
组织架构可以通过更改带宽、层级数量，裁撤低效的个体，来影响信息传递的效率、决策反馈的路径和时长。
5 00
在 AI 驱动的周期里，真正决定生死的，是创始人对趋势有早于行业6-12月的判断和落地，而不是团队内部流程上的敏捷性。
传统的saas时代，认知和工具能力的更替在2-3年，敏捷的组织有大量时间转型。
Ai驱动的时代，认识差只在2-3个月，今天模型+策略的产品，明天就被模型能力吃掉，敏捷在这里的意义急剧下降。
只有比行业早 6–12 个月做到三件事的团队，才有机会建立真正的增长复利：
1. 提出下一代产品体验的概念（先于市场的认知）
2. 在模型能力的优势窗口期内，真正把产品 ship 出来（先于对手的执行）
3. 用生态来构建：新体验-旧体验<迁移成本，提高用户更替产品的阻力。
传统的saas时代，认知和工具能力的更替在2-3年，敏捷的组织有大量时间转型。
Ai驱动的时代，认识差只在2-3个月，今天模型+策略的产品，明天就被模型能力吃掉，敏捷在这里的意义急剧下降。
只有比行业早 6–12 个月做到三件事的团队，才有机会建立真正的增长复利：
1. 提出下一代产品体验的概念（先于市场的认知）
2. 在模型能力的优势窗口期内，真正把产品 ship 出来（先于对手的执行）
3. 用生态来构建：新体验-旧体验<迁移成本，提高用户更替产品的阻力。
2 00
飞书多维表格上了应用模式，看了下思路还挺好。
从产品形态上看，多维表格不是在做“表格增强”，它本质是在把传统表格工具升级成一个轻量级业务系统生成器。
让企业第一次能用极低成本，搭出属于自己的 database + workflow，而不是被各种模板化的系统绑着走（templates based的适配企业的修改负担挺大）
以前和朋友聊过类似的产品方向，能很好解决小公司低成本开发自己的业务流的问题：
1. 数据断层：流程在跑，数据却散落各处。
应用模式把流程和数据绑成一个闭环——流程一跑，数据就自动结构化沉淀下来，
企业不用再靠人手凑数据、靠 Excel 拼报表。
2. 系统又慢又贵：买十个 SaaS 也未必贴合业务。
零代码搭建意味着大多数团队完全不必再去买一堆不适配的 SaaS，也不用再花时间做定制系统。
会抽出时间来仔细体验下，也推荐给所有还在初创阶段，有数据流程搭建和数据管理痛点的朋友们
从产品形态上看，多维表格不是在做“表格增强”，它本质是在把传统表格工具升级成一个轻量级业务系统生成器。
让企业第一次能用极低成本，搭出属于自己的 database + workflow，而不是被各种模板化的系统绑着走（templates based的适配企业的修改负担挺大）
以前和朋友聊过类似的产品方向，能很好解决小公司低成本开发自己的业务流的问题：
1. 数据断层：流程在跑，数据却散落各处。
应用模式把流程和数据绑成一个闭环——流程一跑，数据就自动结构化沉淀下来，
企业不用再靠人手凑数据、靠 Excel 拼报表。
2. 系统又慢又贵：买十个 SaaS 也未必贴合业务。
零代码搭建意味着大多数团队完全不必再去买一堆不适配的 SaaS，也不用再花时间做定制系统。
会抽出时间来仔细体验下，也推荐给所有还在初创阶段，有数据流程搭建和数据管理痛点的朋友们
5 00
和朋友/网友 又聊了下，发下感受。最近感觉大家都忙着去做context orchestration，希望构建一个：无需用户表达、能自动推断用户需求，并提供主动协助的产品。
感觉这是不完全对的
1. 一个能实时感知，读取所有本地和在线files、页面和行为的OS agent 会有大量的噪音。
2. 噪音处理不当，就会造成意图误判，在不合时宜的时间出现assistance toast，本质上都是对用户的侵扰。
3. 好产品要少输入，因为输入本身也是一种负担。但应该鼓励“有效输入”。
4. 另外Context要有，但并不是越多越好，而是和任务越相关越好，这需要产品本身有明确的上下文边界(知道哪些要哪些不要)
5. 用户对要执行的任务也有明确的意图、目标，甚至条件，注意力边界的控制很重要
感觉这是不完全对的
1. 一个能实时感知，读取所有本地和在线files、页面和行为的OS agent 会有大量的噪音。
2. 噪音处理不当，就会造成意图误判，在不合时宜的时间出现assistance toast，本质上都是对用户的侵扰。
3. 好产品要少输入，因为输入本身也是一种负担。但应该鼓励“有效输入”。
4. 另外Context要有，但并不是越多越好，而是和任务越相关越好，这需要产品本身有明确的上下文边界(知道哪些要哪些不要)
5. 用户对要执行的任务也有明确的意图、目标，甚至条件，注意力边界的控制很重要
5 00