Building in the AI Era: The HeyGen Way

Our Mission: Make visual storytelling accessible to all.

我们的使命:让视觉叙事被所有人触及。

We've categorized videos into two types:

我们把视频分成两类:

Communication Videos — business updates, tutorials, interviews, podcasts, explainers. These are designed to explain, inform, or communicate. (Best suited for script-based editing.)

Communication Videos(沟通型视频)—— 业务更新、教程、访谈、播客、讲解。目的是解释、告知、沟通。(最适合基于脚本的剪辑流程。)

Cinematic Videos — high production ads, films, music videos, trailers, high-end brand content. These are designed to move, inspire, or entertain. (Best suited for timeline editing.)

Cinematic Videos(电影感视频)—— 高制作广告、电影、MV、预告片、高端品牌内容。目的是打动、鼓舞、娱乐。(最适合基于时间轴的剪辑流程。)

Our focus is on making Communication Videos accessible to everyone. When we say everyone, we mean every skill level, from first-timers to pros. Our product is simple enough for anyone to make a high-quality video in minutes.

我们聚焦的是让 Communication Videos 被每个人触及。说"每个人",意思是覆盖所有技能层级——从第一次摸视频的人,到专业老手。我们的产品要简单到任何人都能在几分钟内做出高质量视频。

Traditional software development is dead. The foundations that once stayed still now shift under our feet. In the AI era, breakthroughs land every few months, and yesterday's limits turn into tomorrow's defaults.

传统软件开发已经死了。曾经稳如磐石的地基,如今在我们脚下移动。AI 时代里,突破每隔几个月就落地一次——昨天的天花板,变成明天的默认值。

At HeyGen, we don't fight this instability. We ride the wave. We've built our entire development philosophy around surfing AI advancement rather than seeking stable technical foundations that no longer exist.

在 HeyGen,我们不跟这种不稳定较劲。我们驾驭浪潮。我们的整套开发哲学,都是围绕"乘着 AI 的进步往前走"建起来的——而不是去找那块早就不存在的稳定技术地基。

This book documents how we think, build, and win. It's for every HeyGen team member—engineer, designer, PM—and for those who want to join us. This is how we work when the foundation constantly shifts beneath our feet and how we turn that instability into our competitive advantage.

这本书记录的是我们怎么想、怎么做、怎么赢。它写给每一位 HeyGen 团队成员——工程师、设计师、PM——也写给想加入我们的人。这就是我们在地基不停移动时的工作方式,以及我们如何把这种不稳定变成自己的竞争优势。

核心信条 verbatim 中译:跑得快,也做到极致。驾驭 AI 浪潮,接受研究层面的不确定,押注 6 个月之后,做出能随模型升级而自动变强、又不牺牲质量的灵活产品。

In the AI era, we operate without a stable technology foundation. Every few months, the AI technology evolves dramatically. Model capabilities are unknown and changing rapidly.

在 AI 时代,我们脚下没有稳定的技术地基。每隔几个月,AI 技术就发生剧烈演化;模型能力是个移动靶,变化飞快。

We're operating in a once-in-a-generation technology window. In the next 12 months, AI represents the wartime opportunity of our generation. We have a chance to build the next Google or Facebook. The opportunity is exploding right now. We should turn up the intensity to maximum level. That's the reason everyone joins HeyGen and that's why we're here.

我们正在一个百年一遇的技术窗口里。未来 12 个月,AI 是我们这一代的战时机会——有机会建出下一个 Google 或 Facebook。机会正在此刻爆发。强度,要调到最大。这是每个人加入 HeyGen 的理由,也是我们在这里的理由。

This isn't a bug. It's our opportunity. We ride the wave instead of fighting the current.

这不是 bug,是我们的机会。我们驾驭浪潮,而不是与水流为敌。

Traditional Era:Build on stable foundations · Optimize for longevity · Plan 12-18 months ahead · Polish, then ship · Sequential development.

传统时代:在稳定地基上盖楼 · 为长寿优化 · 提前 12-18 个月做规划 · 先打磨再上线 · 顺序开发。

AI era (Our Way):Ride the technology wave · Build for automatic improvement · Plan 2 months realistically (aligned with model upgrade cycles) · Ship to learn · Parallel experimentation.

AI 时代(我们的方式):驾驭技术浪潮 · 为"自动变好"而建 · 实事求是地只规划 2 个月(对齐模型升级周期)· 上线是为了学 · 并行实验。

Traditional Agile assumes relatively stable technology with predictable capabilities. We work in an environment where the foundational technology changes every few months. Our approach extends Agile principles but optimizes for technology instability rather than stable iteration cycles.

传统 Agile 的前提是技术相对稳定、能力可预期。而我们工作的环境,底层技术每几个月就变一次。我们的方法延伸了 Agile 原则,但优化目标是技术的不稳定本身,而不是稳定的迭代周期。

Competitors chase stable ground and get blindsided by the next leap. We design for automatic improvement as models advance and choose to surf the wave, not fight it.

竞品在追稳定地面,然后被下一跳模型突袭。我们设计的是"随模型变强而自动变好"的系统——选择驭浪,而不是搏水。

Understanding what changes vs. what stays constant: It's important for us to understand what components might change in the near term (models, capabilities) and what are not likely to change (user workflows, core problems), and build our products/systems around the things that don't change while riding the wave of model improvement.

理解"什么会变 vs 什么不变":近期会变的是模型 / 能力,不变的是用户工作流和核心问题。我们要围着"不变的"建产品和系统,同时驭着"会变的"模型浪潮往上走。

Examples of wave-riding opportunities: In-context learning vs. fine-tuning vs RAG approaches · Post-processing improvements in voice models · Multi-vendor system optimizations.

驭浪机会的几个例子:在 in-context learning / 微调 / RAG 几条路径之间切换 · 语音模型的后处理优化 · 多供应商系统的优化。

We move fast AND be the absolute best. This seems contradictory until you understand: moving fast allows us to build better quality in the long run and deliver customer value faster. When competitors ship one feature per month, we ship five experiments. We learn five times faster. That learning compounds into superior products.

我们跑得快,也做到极致。这看起来矛盾,直到你理解一点:跑得快,反而能在长跑里堆出更高的质量,也能更快地把价值交到用户手里。对手每月上线 1 个 feature 的时候,我们上 5 个实验——学习速度是他们的 5 倍。那种学习会复利,最后变成更好的产品。

Moving fast doesn't mean shipping features quickly—it means delivering customer value quickly (and learning quickly). Speed serves the ultimate goal of being the absolute best.

跑得快不等于"赶快上 feature"——意思是"赶快把价值交到用户手里"(以及"赶快学到东西")。速度服务于一个终极目标:做到极致。

For video content especially, quality is non-negotiable. Users don't love products because of polished UI—they love products that solve their problems with exceptional quality. Our success metric: the average video quality any user can achieve on our platform.

对视频内容尤其如此,质量不可妥协。用户喜欢一个产品,不是因为 UI 多精致——而是因为它用过硬的质量解决了他们的问题。我们的成功指标:任何一个用户在 HeyGen 上能做出的视频平均质量。

Why 2 months? This aligns with model upgrade cycles and allows for rapid strategy adjustments while maintaining focus.

为什么是 2 个月?因为这跟模型升级周期对齐,既能快速调整策略,又不至于失焦。

2-month roadmap planning — Synchronized with AI advancement cycles. Deep dive on product recap and strategy with leadership, tech leads, and PMs (design optional but encouraged). Held ideally in person to maximize throughput and break through noise. Full transparency and intellectual honesty about our performance, with strategy adjustments as needed.

2 个月路线图规划——跟 AI 进展周期同步。CEO + tech lead + PM(设计可选,但鼓励参加)深入复盘产品和策略。最好面对面开,把噪音穿透、效率拉满。对自己的表现保持完全透明、保持智识诚实,该调策略就调。

6-12 month strategic bets — Predicting and preparing for the next big breakthroughs.

6-12 个月战略押注——预测下一个大突破,并提前做准备。

Bi-weekly commitment lists — Product and Engineering jointly decide and prioritize what each team commits to for specific deliverables.

双周承诺清单——产品和工程联合决定、排优先级,每个团队对具体交付物做承诺。

Daily shipping — Improvements, features, or experiments go live every day.

每日 ship——每天都有改进、feature 或实验上线。

The Philosophy: Short cycles keep us aligned with the pace of AI development. Long enough to build meaningful things, short enough to adapt when the technology landscape shifts.

这套哲学:短周期让我们跟 AI 发展的节奏对齐。够长,能做出有意义的东西;够短,在技术地形变化时还能调头。

Important Note: This framework applies more to existing product and growth areas, but less to new features and research areas where longer exploration may be needed.

提醒:这个框架更适用于已有产品和增长方向;对全新 feature 和研究方向不那么适用——后者需要更长的探索周期。

Day 1: Define hypothesis and success metrics · Day 2: Build MVP (truly minimal) · Days 3-5: Ship to subset of users · Week 2: Analyze, learn, decide next steps.

Day 1:定义假设和成功指标 · Day 2:做 MVP(真的最小)· Day 3-5:推给一部分用户 · Week 2:分析、学习、决定下一步。

Good Experiments Are: Fast (days, not weeks) · Scientific and data-driven · Provide clear signals: proceed, pivot, or stop · Big swings over small tweaks (we're not mature enough for optimization).

好的实验是:快(以天为单位,不是周)· 科学、数据驱动 · 给出明确信号:继续 / 转向 / 停 · 大刀阔斧,而不是小修小补(我们还没到优化的阶段)。

Failed Experiments: Most experiments fail—this is expected. Failure with learning = victory. Failure without learning = actual failure. Never run experiments so long you can't conclude.

失败的实验:大部分实验会失败——这是常态。失败 + 学到东西 = 胜利。失败 + 没学到 = 真正的失败。永远不要把实验拖到无法下结论。

Framework: Is this a one-way or two-way door? One-way doors: Careful deliberation (rare). Two-way doors: PM decides quickly, test immediately (common). When debating: Can we test this? If yes, stop talking and experiment.

判断框架:这是单向门还是双向门?单向门(走过去就回不来):仔细斟酌(少见)。双向门(可以回头):PM 快速决策,立刻测试(常见)。争论时问一句:这个能不能测?能 → 别说了,立刻做实验。

Decision Communication: Communicate via Slack immediately with clear single-person accountability and execution timing · Full transparency between teams · Share context, not just the plans · Clearly explain who should be communicated to for each decision.

决策沟通:立刻在 Slack 上同步——单人 accountable + 明确执行时机 · 团队之间完全透明 · 分享上下文,不只是分享计划 · 每个决策都说清楚:还需要 sync 给谁。

While we plan realistically for 2 months, we must predict 6-12 months ahead for strategic bets. This requires: Following AI research breakthroughs · Understanding compute trends · Anticipating model capabilities · Building flexible architectures that benefit from future improvements.

虽然我们脚踏实地只规划 2 个月,但战略押注必须看 6-12 个月。这要求我们:盯住 AI 研究的突破 · 理解算力趋势 · 预判模型能力 · 建出"未来能力提升后能直接受益"的灵活架构。

Core Principle: Build for flexibility and replaceability · Build abstraction layers that expect change (caveat: don't over-abstract when it's not ready) · Document assumptions, not implementations · Version everything aggressively · Design systems that improve when models do.

核心原则:为灵活性和可替换性而建 · 做"预期会变"的抽象层(注意:还不到时候就别过度抽象)· 记录假设,不是记录实现 · 对所有东西激进地做版本管理 · 把系统设计成"模型变强它也跟着变强"。

Time Allocation for Technical Debt: Treat technical debt reduction as an investment in future velocity. We celebrate technical debt reduction efforts that measurably improve team productivity and system reliability. Technical debt work should be clearly connected to business outcomes and velocity improvements.

技术债时间分配:把"还技术债"当作"对未来速度的投资"。能可量化提升团队产能和系统可靠性的技术债清理,我们会庆祝。技术债工作必须跟业务结果和速度提升明确挂钩。

The New Reality: In the AI era, the team that learns fastest wins. Period.

新现实:在 AI 时代,学得最快的团队赢。就这么简单。

Ship in days, not weeks · When in doubt, ship an experiment · Momentum matters more than perfection · Moving slow is the only unforgivable sin.

以天为单位上线,不是以周为单位 · 拿不准就上一个实验 · 节奏比完美更重要 · 慢——是唯一不可饶恕的罪。

Practical Application: MVP for testing ideas, not final products · Good enough to validate > perfect but late · Ship imperfect, then follow up: sunset if it doesn't work, or improve until it's the best if users care · Bugs are worse than imperfect features (bugs prevent learning).

怎么落地:MVP 用来测想法,不是最终产品 · 足以验证就够 > 完美但晚了 · 先上不完美的,再跟进——不灵就下线,用户在意就改到极致 · bug 比"不完美的 feature"更糟(bug 会让你学不到东西)。

Speed Is an Attitude. Speed isn't just about raw execution. It's about mindset. We don't say "Let's wait until Monday to ship this so it's safe." This reveals lack of urgency, lack of desire to learn faster (2-3 days of valuable data lost), weak ownership, and doubt in execution ability. This mindset prevents us from winning. Winners own, ship, learn, and adapt, fast.

速度是一种态度。速度不只是执行力的事,是心态的事。我们不会说"周五先别 ship,等周一再说,这样安全"——这种话暴露的是:缺紧迫感、不想更快学到东西(等于丢掉 2-3 天宝贵数据)、ownership 弱、对自己的执行能力心虚。这种心态会让我们输。赢家是 own、ship、学、调整——而且全部快速完成。

Bias for Action > Being Perfect. If you're optimizing for being right, you're moving too slow. Don't fear being wrong. Fear being too slow to learn.

"立刻动手" > "做对"。如果你在优化"对",那你已经走得太慢了。别怕做错——怕的是,学得太慢。

Stop chasing technology stability. It doesn't exist. The AI foundation will change every 2 months. Design your products to automatically improve when models do. Build abstraction layers that expect change. Make your product experience ride on top of AI advancement, not despite it.

别再追技术稳定了——稳定不存在。AI 地基每 2 个月就变一次。把产品设计成"模型变好,产品自动跟着变好"。做"预期变化"的抽象层。让产品体验骑在 AI 进步上面跑,而不是顶着AI 进步跑。

We're in wartime, not peacetime. Everyone contributes ideas and feedback, but decisions must be fast. Once made, we fully commit, even if we disagreed. Strategy flaws from lack of commitment are worse than imperfect decisions we can quickly correct.

我们处在战时,不是和平时期。每个人都贡献想法和反馈,但决策必须快。一旦定下,所有人完全 commit——哪怕你当时反对。"因为没承诺导致的策略失败",比"决策本身不完美、但可以快速纠正"更糟。

Users love products that solve problems, not pretty interfaces. Innovation and user love are tightly coupled. We innovate how people create videos with AI, building magical experiences that weren't possible before. But innovation without solving real problems is worthless.

用户喜欢的是能解决问题的产品,不是漂亮的界面。创新和用户喜爱是绑在一起的。我们在重新发明"用 AI 做视频"这件事,做出过去不可能的魔法体验——但创新如果没解决真问题,等于零。

The Onboarding Challenge: AI products have vast capability variance based on user skill · Our responsibility: Teach use cases, not just features · Success = average quality any user can achieve · Measure video quality, not just video creation.

新手引导挑战:AI 产品的能力释放,因用户技能差异巨大 · 我们的责任是教用例,不只是教 feature · 成功 = 任意用户能做到的平均质量 · 量的是视频质量,不只是"做了多少视频"。

Whatever provides the best user experience, we do that.

哪个能给用户最好的体验,我们就走哪条。

Built in-house: Avatar video models (no external provider meets our quality bar). External providers: Voice (good enough quality, resource constraints). No ego, just results.

自研:Avatar 视频模型(没有任何外部供应商达到我们的质量线)。外部供应:声音(质量够用,资源紧)。No ego, just results——不为面子,只看结果。

All teams follow the same core structure: PM + Engineering + Design + Data Science.

所有团队都遵循同一个核心结构:PM + 工程 + 设计 + 数据科学。

Product Managers: The Orchestrators. Core Responsibilities: Primary driver for decisions and priority setting · Work directly with leadership on strategy · Own the "why" behind every feature · Coordinate across engineering, data science, design.

PM:编排者(The Orchestrators)。核心职责:决策和优先级的首要推动者 · 直接跟 leadership 对接做策略 · Own 每个 feature 背后的"为什么" · 横向协调工程 / 数据科学 / 设计。

PM Capabilities: Create functional MVPs and UX prototypes · Simplify technology abstractions for users · Lead the prototype-first approach.

PM 能力:做出能跑的 MVP 和 UX 原型 · 把技术抽象简化给用户 · 主导"原型先行"的工作方式。

AI-Era Evolution: Build functional prototypes, skip traditional specs · Use Figma designs or UX prototypes as documentation · Plan for capabilities that don't exist yet · Be very familiar with all the AI tools in the market and use them daily.

AI 时代演化:做出能跑的原型,跳过传统 spec 文档 · 用 Figma 设计稿或 UX 原型当文档 · 为"还不存在的能力"做规划 · 对市面上所有 AI 工具非常熟,每天用。

Engineers: The Rapid Builders. Core Responsibilities: Build and execute on decisions at maximum speed · Provide technical insights PMs might miss · Architect for flexibility and rapid iteration · Deeply understand the "why" behind problems.

工程师:快速建造者(The Rapid Builders)。核心职责:以最高速度落地决策 · 提供 PM 可能漏掉的技术洞察 · 为灵活性和快速迭代而做架构 · 深度理解问题背后的"为什么"。

AI-Era Focus: Code with AI assistants (Cursor, ChatGPT, etc.) to amplify speed. We used to talk about 10x engineers in our industry. I'm not sure about 10x, but with AI code pilot tools, everyone is at least 3x more productive than 2 years ago.

AI 时代重心:用 AI 助手(Cursor / ChatGPT 等)写代码,放大速度。我们行业过去聊的是"10x 工程师"——10x 我不敢说,但有了 AI code pilot,每个人的产能都至少是两年前的 3 倍。

Build prototypes that can evolve into production systems · Focus on building, not documentation · Partner directly with PMs for rapid prototyping.

做出"能演化成生产系统"的原型 · 聚焦在"建",而不是"文档" · 跟 PM 直接配对快速做原型。

Designers: The Simplifiers. Primary Role: Define simple yet exceptional experiences.

设计师:简化者(The Simplifiers)。主要角色:定义简洁、却卓越的体验。

The Design Mission: As a creative tool for video, our design needs to be world class. Anything below that won't position us to make our tools accessible to everyone. Therefore, the number one principle for our design is simplicity. Making something work in AI is not hard, but making it easy to use while maintaining high quality is extremely hard. And that is the main mission for our design team.

设计使命:作为视频创作工具,我们的设计必须是世界级的。低于这个水位的水平,都会让我们没办法把工具送到每个用户手里。所以我们设计的第一原则是简洁。让 AI"能跑"不难;让它简单好用、同时质量过硬——极其难。这就是设计团队的主战场。

Core Responsibilities: Create functional MVPs and UX prototypes · Refine prototypes into consumer-level, delightful experiences · Ensure all features fit cohesively into the HeyGen product framework · Maintain our principle: dead simple for everyone (including grandma) · Lead simplification efforts — if grandma can't use it, designers flag it and fix it · Own design systems for consistent, rapid iteration · Help simplify the product marketing · Focus on visual polish and experience consistency after validation.

核心职责:做出能跑的 MVP 和 UX 原型 · 把原型打磨到 consumer 级、让人愉悦的体验 · 确保所有 feature 都装进 HeyGen 的产品框架 · 守住原则:每个人都能用(包括奶奶)· 主导简化工作——奶奶用不了,设计师标记并修复 · Own 设计系统,让未来开发保持一致且快速 · 帮助简化产品 marketing · 在验证之后,聚焦视觉打磨和体验一致性。

Key Principle: Designers focus on post-validation excellence rather than early exploration to maintain development speed. They are the primary guardians of the "dead simple for everyone including grandma" principle — a fundamental design challenge that requires real expertise applied after validation.

关键原则:设计师聚焦在"验证之后做到卓越",而不是"早期探索"——这是为了保持开发速度。他们是"奶奶都能用"原则的首席守卫——这是一个根本性的设计挑战,需要真正的专业能力,在验证之后投入。

Data Scientists & PMs: The Analysis Partners.

数据科学家 & PM:分析搭档(The Analysis Partners)。

Data Science Responsibilities: Metric explanation & validation (source of truth for logic and definitions) · Statistical analysis: correlation, causation, causal inference · Establish advanced experiment metrics not achievable in PostHog · Build institutional dashboards on established product features · Complex analysis requiring advanced SQL/Python · Light data engineering & modeling (pipelines, transformations) · Knowledge sharing of data science principles and dictionary.

数据科学职责:指标的解释和校验(逻辑和定义的 source of truth)· 统计分析:相关、因果、causal inference · 建立 PostHog 做不了的高级实验指标 · 在已建立的产品 feature 上做机构级 dashboard · 需要高级 SQL / Python 的复杂分析 · 轻度数据工程和建模(pipeline / 转换)· 数据科学原则和术语的知识分享。

PM Responsibilities (data side): Familiar with area's top-line metrics and able to identify abnormal patterns and initiate investigation · Leverage PostHog analytics to monitor trends and usage · Pull simple data from Hex master tables · Proactively manage experiment lifecycle (pre-testing / back-testing / cleanup) · Define experiment setup — exposure, groups, success metrics · Identify additional events required for measurement · Conduct initial experiment reviews · Understand connections between area topline and company strategy · Expected to do data analysis on their own in PostHog and write simple queries in Hex.

PM 职责(数据侧):熟悉本领域的顶层指标,能识别异常模式并发起调查 · 用 PostHog 分析监控趋势和用量 · 从 Hex 主表里拉简单数据 · 主动管理实验生命周期(预测试 / 回测 / 清理)· 定义实验设置——曝光、分组、成功指标 · 识别度量需要的额外事件 · 做初步实验复盘 · 理解本领域顶层指标与公司战略的关联 · 预期自己能在 PostHog 做数据分析,在 Hex 里写简单查询。

Shared Responsibilities (Both DS & PM): Experiment impact analysis · KPI definition (e.g. AER, retention, conversion) · Joint experiment review when deeper analysis is needed · Investigate abnormal patterns.

共享职责(DS & PM 都做):实验影响分析 · KPI 定义(例如 AER、留存、转化)· 需要更深分析时的联合实验复盘 · 调查异常模式。

PM helps define the what: Frames the problem · Defines the objective · Brings clarity and context.

PM 定义"做什么":框定问题 · 定义目标 · 带来清晰度和上下文。

Engineers shape the how: Co-designs the solution with PM & Design · Owns feasibility, trade-offs, execution.

工程师塑造"怎么做":跟 PM 和设计一起共同设计解决方案 · Own 可行性、取舍、执行。

Designers ensure simplicity: Make complex AI accessible to everyone · Guard the "grandma test" principle · Create delightful experiences.

设计师确保简洁:让复杂的 AI 被每个人触及 · 守住"奶奶测试"原则 · 做出让人愉悦的体验。

Data Scientists provide the truth: Validate assumptions with data · Measure impact scientifically · Guide experimentation methodology.

数据科学家提供"真相":用数据验证假设 · 用科学的方式度量影响 · 指导实验方法。

All align on the why: Why is this worth doing? · What problem are we solving? And for whom? · Why now? Why this approach over others? · Why does this move the business forward?

所有人在"为什么"上对齐:这件事值得做吗? · 我们在解决什么问题?为谁解决? · 为什么是现在? · 为什么走这条路而不是那条? · 这件事为什么能推动业务?

The Philosophy: In traditional software, PM + Design + Engineer formed the holy triangle. In fast-paced AI development, we optimize for speed and learning over perfect process.

哲学:传统软件里,PM + 设计 + 工程构成"神圣三角"。在快节奏的 AI 开发里,我们优化的是速度和学习,而不是完美流程。

Flexible Partnership Model: PM and designer partnerships can vary for different teams. Some PMs have more experience in UX and should drive the prototype end to end; some designers understand deeply how AI works and can jump in to lead the prototype.

灵活的搭档模型:PM 和设计师的协作模式可以因团队不同而不同。有的 PM 有 UX 经验,应该端到端推动原型;有的设计师对 AI 怎么工作理解很深,可以直接 jump in 主导原型。

The 2-Person Rule: In principle, one person from PM/Design plus one Engineer (total 2 people) builds the prototype. We don't optimize for consensus just to protect everyone's feelings. We are here to speed things up to validate ideas in the market ASAP so we as a team can build a better product.

2 人规则:原则上,PM / 设计师里出 1 人 + 工程师 1 人(总共 2 人)来做原型。我们不会为了照顾所有人的情绪去优化共识。我们在这里是为了加速,尽快在市场上验证想法,以便作为一个团队做出更好的产品。

Everyone will have opportunities to build prototypes for new ideas. There are technically infinite things to build in the AI era (like what we did in our hackathon, truly amazing). The key is to have an effective group to drive fast decisions.

每个人都会有机会为新想法做原型。AI 时代要做的东西从技术上讲是无限的(就像我们在 hackathon 里做的那样,真的精彩)。关键是有一个有效的小组,推动快速决策。

The Universal Approach: Prototype First: PM/Designer + Engineer work directly together to build and test ideas quickly · Prove It Works: Validate the concept with real users before heavy design investment · Design Polish: Once proven, designers refine the experience to fit our overall product framework and maintain simplicity · Production Ready: Every feature that graduates from prototype to production must be well-designed.

通用做法:原型先行——PM / 设计师 + 工程师直接配对,快速做出想法并测试 · 证明它能跑——在重投入设计之前,先用真实用户验证概念 · 设计打磨——一旦验证通过,设计师把体验打磨进整体产品框架,保持简洁 · 生产就绪——从原型晋升到生产的每个 feature,都必须设计到位。

Why This Works: AI features have massive uncertainty. Most prototypes won't work. Over-investing in design for unproven concepts wastes time. But everything that reaches users must meet our quality bar.

为什么这套有效:AI feature 的不确定性巨大,大部分原型会失败。对未经验证的概念投入太多设计,就是浪费时间。但任何抵达用户手里的东西,必须达到我们的质量线。

Focus: Building and Refining Core Product Features. Core Product teams focus on the foundational product experience — building features that define what HeyGen is and does. They optimize for user experience quality, feature completeness, and long-term product vision.

聚焦:建造与打磨核心产品 feature。核心产品团队聚焦在基础产品体验——做那些"定义 HeyGen 是什么、做什么"的 feature。他们优化的是用户体验质量、feature 完整度、长期产品愿景。

Core Product Team Characteristics: Longer development cycles for complex features · Focus on product experience and user journey · Emphasis on design systems and consistency · Integration across the entire product ecosystem · We're building a business tool, but delightful product experience is extremely important for a creative tool and for HeyGen to hit 100M users.

核心产品团队特征:复杂 feature 用更长的开发周期 · 聚焦产品体验和用户旅程 · 强调设计系统和一致性 · 在整个产品生态里做集成 · 我们做的是一个商业工具,但对于创作工具来说、对于 HeyGen 要到 1 亿用户的目标来说,愉悦的产品体验极其重要。

Zero Bugs Aspiration: We should aim for zero bugs. We're not there yet, but that's our north star. When you use the best creative tools—Canva, Figma, or CapCut—you rarely encounter bugs because accuracy is critical for creative work. As a creative tool, reliability isn't just nice to have—it's essential for user trust and workflow continuity.

"零 Bug"是我们的北极星:我们应该以"零 bug"为目标。还没到,但这是我们的北极星。当你用最好的创作工具——Canva、Figma、CapCut——你几乎遇不到 bug,因为对创作工作而言,准确性是关键。作为一个创作工具,可靠性不是"有最好",而是用户信任和工作流连续性的必要条件。

The Experiment Engine Philosophy: Growth teams operate differently from core product teams. We're the experiment engine. We're built for speed, learning, and impact. Every principle serves one goal: increasing our velocity.

实验引擎哲学:增长团队的运作方式跟核心产品团队不同。我们是实验引擎。我们为速度、学习和影响而建。每一条原则只服务一个目标:把速度拉高。

Engineering Is a Tool, Impact Is the Goal. We don't just ship code. We ship outcomes. In the AI era, code is cheap. Impact is valuable. Don't optimize for beauty or over-engineer solutions no one asked for. Optimize for Speed to Impact: Ship what matters (20% input, 80% outcome), iterate when proven, and refine once the value is real.

工程是工具,影响才是目标。我们不只是 ship 代码,我们 ship 结果。在 AI 时代,代码便宜,影响才珍贵。不要优化"美感",不要为没人要的方案过度工程化。优化"Speed to Impact":先 ship 重要的东西(20% 投入产出 80% 结果),验证成立后再迭代,价值真实之后再打磨。

Experiments Are for Learning, Not Winning. Safe experiments aren't really experiments. The goal is to learn faster by taking smart risks, betting on bold hypotheses, and being willing to be wrong fast so we can be right faster next time.

实验是为了学习,不是为了"赢"。安全的实验,根本不算实验。目标是更快地学——通过聪明地冒险、押注大胆假设、愿意快速犯错,以便下一次更快地走对。

Growth PMs: The Experiment Orchestrators. Make decisions collectively with the team · Own the metrics and learning loops · Deeply understand user problems and business impact · Define the "what" — frame problems, define objectives, bring clarity · Align on the "why" with engineering — why is this worth doing? Why now? · Spin up experiments rapidly with bias for action · Own outcomes, not just outputs.

Growth PM:实验编排者。跟团队一起做决策 · Own 指标和学习循环 · 深度理解用户问题和业务影响 · 定义"做什么"——框问题、定目标、带来清晰度 · 跟工程在"为什么"上对齐——值得做吗?为什么是现在? · 用 bias for action 的姿态快速跑实验 · Own 结果,不只是产出。

Growth Engineers: The Velocity Machines. Co-design solutions with PM & Design · Own feasibility, trade-offs, and execution to build better, faster, smarter · Shape the "how" while aligning on the "why" · Spin off experiments at maximum velocity · Obsess over learning loops and data · Deeply understand problems beyond just "tell me what to build" · With the "why," become active participants who deliver more value with less iteration · Focus on speed to impact over perfect architecture · Build the experiment engine that changes company trajectory.

Growth Engineer:速度机器。跟 PM 和设计共同设计方案 · Own 可行性 / 取舍 / 执行——做得更好 / 更快 / 更聪明 · 塑造"怎么做",同时跟"为什么"对齐 · 以最高速度撒出实验 · 对学习循环和数据着魔 · 深度理解问题——不只是"告诉我要做啥" · 有了"为什么",从被动接需求变成主动参与者,用更少迭代交付更多价值 · 聚焦"Speed to Impact",而不是"完美架构" · 建出能改变公司轨迹的实验引擎。

The Growth Difference: Growth teams are built for a different game than core product teams. Where core product focuses on building and refining features, growth focuses on rapid experimentation and learning. We're playing a game where velocity wins, and every principle serves that goal.

增长团队的不同之处:增长团队和核心产品团队玩的是两套游戏。核心产品聚焦在"建造和打磨 feature",增长聚焦在"快速实验和学习"。我们玩的这场游戏,速度赢——每一条原则都为速度服务。

Async First: With distributed offices, leverage asynchronous communication whenever possible.

异步优先:多地办公室分布,能用异步沟通就用异步。

Meeting Red Flag: If any team member has more than 3 sync meetings with groups larger than 5 people, raise the red flag.

会议红旗:任何团队成员一周有超过 3 个"5 人以上的同步会议",就翻红牌。

Time Focus: Our time should be spent building, not meeting.

时间聚焦:我们的时间应该花在建造上,不是开会上。

In-Person for Impact: Use in-person time for maximum communication throughput and team building.

面对面是为了密度:面对面的时间用来最大化沟通带宽和团队建设。

Decisions: Communicate via Slack immediately with clear single-person accountability and execution timing. Full transparency between teams. Share context, not just the plans. Clearly explain who should be communicated to for each decision.

决策:立刻在 Slack 同步——单人 accountable + 明确执行时机。团队之间完全透明。分享上下文,不只是分享计划。每个决策都说清楚:还需要 sync 给谁。

Feedback: Be direct — good work is good, bad work is bad. Focus on work, not person. When receiving feedback: It's about the work, not you. Everyone can improve.

反馈:直接——好就是好,坏就是坏。对事,不对人。接收反馈时:这是关于工作,不是关于你。每个人都能进步。

1. The Perfect Architecture · Spending weeks designing for "scale" · Your scale problem: 100 users · Actual problem: No users love it yet.

1. 完美架构 · 花几周设计"可扩展性" · 你的扩展性问题:才 100 个用户 · 真正的问题:还没用户爱你。

2. The Research Paralysis · "We need more user research" · Months of interviews, no shipping · Better approach: Ship wrong, learn fast, ship right.

2. 研究瘫痪 · "我们需要更多用户调研" · 几个月访谈,什么都没上线 · 更好的做法:先 ship 错的,快速学到东西,再 ship 对的。

3. The Stable Foundation Fantasy · Waiting for AI to "mature" · Building like it's 2019 · Reality: It will never be stable — ride the wave instead.

3. 稳定地基幻想 · 等 AI"成熟" · 还在用 2019 年的方式开发 · 现实:它永远不会稳定——别等了,驾驭浪潮。

4. The Consensus Trap · Everyone agrees = no one cares · Strong opinions, loosely held · Conflict means you're onto something.

4. 共识陷阱 · 所有人都同意 = 没人在意 · 强观点 + 弱坚持 · 有冲突,说明你抓到了点子。

5. The Quality Excuse · "It's not ready yet" · "Just one more polish pass" · Ship confidently, improve fast.

5. 质量借口 · "还没准备好" · "再打磨一轮就好" · 自信地 ship,然后快速改进。

6. The Big Bang Release · 6 months of secret development · Grand reveal · Competitors already shipped and learned.

6. 大爆炸式发布 · 6 个月秘密开发 · 盛大揭幕 · 竞品已经 ship 出去 + 学到东西了。

7. The Sunk Cost Fallacy · "We've invested so much already" · Kill failures fast · Celebrate the learnings, delete the code.

7. 沉没成本谬误 · "我们已经投入了这么多" · 快速砍掉失败的东西 · 庆祝学到的东西,把代码删掉。

Quality Gates (Non-Negotiable): Bugs that prevent learning from experiments · Security vulnerabilities · Features that actively hurt user experience · Breaking changes that affect customers.

质量门槛(不可妥协):导致实验学不到东西的 bug · 安全漏洞 · 主动伤害用户体验的 feature · 影响客户的破坏性变更。

Strategic Pauses (Rare but Important): One-way door decisions with major business impact · Technical architecture that will affect next 6 months · When user feedback indicates a fundamental direction change · Legal or compliance requirements.

战略性慢下来(罕见但重要):对业务有重大影响的单向门决策 · 影响未来 6 个月的技术架构 · 用户反馈显示需要根本性调头 · 法律或合规要求。

We ship 5x faster than competitors: More experiments = more learning.

我们 ship 速度是竞品的 5 倍:更多实验 = 更多学习。

Learning compounds into better products: We embrace what others avoid.

学习会复利成更好的产品:我们拥抱别人逃避的东西。

Instability is our advantage: Old-school competitors can't adapt.

不稳定是我们的优势:老派竞品适应不了。

We focus on what matters: Quality for users, speed for learning, innovation for differentiation.

我们聚焦在重要的事上:质量为用户、速度为学习、创新为差异化。

1. Move fast, no compromises · 2. Build the absolute best product experience · 3. Quality is paramount (especially for video visual quality) · 4. Disagree and commit · 5. When in doubt, ship an experiment · 6. Embrace unstable AI development — ride the wave · 7. Foster innovation through integration.

1. 跑得快,不妥协 · 2. 建出绝对最好的产品体验 · 3. 质量第一(尤其是视频视觉质量)· 4. Disagree and commit · 5. 拿不准就上一个实验 · 6. 拥抱不稳定的 AI 开发——驾驭浪潮 · 7. 通过集成催生创新。

Three years ago, we couldn't have imagined current AI capabilities. ChatGPT wasn't even there. Three years from now, today's cutting-edge will seem quaint. The only constant is change. The only strategy is riding the wave. The only goal is user value.

三年前,我们无法想象当下的 AI 能力——那时连 ChatGPT 还没出现。三年之后,今天的尖端会显得过时。唯一不变的是变化。唯一的策略是驾驭浪潮。唯一的目标是用户价值。

We don't have all the answers, but we have something better: the fastest learning loop in the industry.

我们没有所有的答案。但我们有更好的东西:这个行业里最快的学习循环。

Every day, we face a choice: seek false stability or ride the wave. We choose to ride. We choose to build products that get magically better as AI advances. We choose to ship fast, learn even faster, and win.

每一天,我们都面对一个选择:寻找虚假的稳定,还是驾驭浪潮。我们选择驾驭。我们选择建那种"AI 进步、产品自动神奇变好"的东西。我们选择 ship 得快、学得更快、然后赢。

Welcome to the future of software development. Let's build something incredible.

欢迎来到软件开发的未来。我们一起,建点了不起的东西。

Remember: Velocity paired with quality. Innovation with integration. Speed with purpose.

记住:速度,要配上质量。创新,要配上集成。速度,要有目的。

The LinkedIn Pulse post received 106 visible comments. We read all 102 retrievable from the comment section. Of those, ~88 were one-line congratulations on the $100M ARR milestone. Three stood out — two as substantive critique that pushes back on §02's "rock-solid product quality" claim, one as a customer-trust anecdote that anchors what good engagement looks like in practice.

LinkedIn 原帖累计 106 条评论可见,我们读完抓得到的 102 条。其中 ~88 条是"$100M ARR 太牛了"这类一句话祝贺。三条值得入文——两条实质性批评,直接戳在 §02 那条"rock-solid product quality"的反面;一条则用一个老客户的具体经历,锚定了"什么叫真的把用户当回事"。

What the rest looked like: 88 of 102 readable comments were one-line variants of "Congrats Joshua / $100M ARR is huge / The HeyGen Way is the playbook". Useful as a sentiment baseline (founders & ops people overwhelmingly cheering), but not load-bearing for understanding the essay itself.

其余 88 条长啥样:都是"Congrats Joshua / $100M ARR 太牛了 / HeyGen Way 就是 playbook"这类一句话祝贺。情绪基线层面有用(创始人和运营人群压倒性叫好),但对理解这篇 essay 本身并不承重。