如何创造一款新产品（双语版）

type

The greatest startup story of all time 史上最伟大的创业故事

Pikaia (early screenshot) Pikaia（早期截图）

This guy is Pikaia. He lived around 500 million years ago, grew to around 4cm long, and perhaps swam like an eel. Shortly after, along with most other species, he disappeared. 这家伙就是_皮卡虫（Pikaia）_ 。它生活在大约 5 亿年前，体长约 4 厘米，游动方式可能像鳗鱼。不久之后，它和大多数其他物种一样消失了。

Pikaia sapiens? Pikaia 聪明吗？

And yet Pikaia lives on: his descendants are you and me, rulers of this planet, with influence even beyond the solar system, their images engraved forever on the Pioneer spacecrafts! 然而， _皮卡亚_依然活着：他的后代就是你和我，这个星球的统治者，他们的影响力甚至超越了太阳系，他们的形象永远铭刻在先锋号飞船上！

I believe the Cambrian explosion is the best startup story of all time, full of rapid prototyping and forgotten pivots! Like our early-stage startup, natural selection is a search for new, better designs in a shifting landscape. 我相信寒武纪生命大爆发是有史以来最精彩的创业故事 ，充满了快速原型设计和被遗忘的支点！就像我们早期的创业公司一样，自然选择是在不断变化的环境中寻找新的、更好的设计。

Victorian hackathons 维多利亚时代的黑客马拉松

Some believe that evolution has to be slow, but that's just false. Darwin's theory was influenced by pigeon breeders, who were able to find wonderful new pigeon designs within strikingly short time periods. I like to think of good startups like these breeders: tastefully using mutation and selection to find wonderful new products. 有些人认为进化必须是_缓慢的_ ，但这完全是错误的。达尔文的理论受到了鸽子育种者的影响，他们能够在极短的时间内找到出色的新鸽子设计。我喜欢把优秀的初创企业想象成这些育种者：巧妙地利用突变和选择寻找精彩的新产品。

My claim: when designing startups, we can draw surprisingly concrete lessons from how natural selection works! For my first example: let's look at nature's attitude toward copy-paste. 我的主张是：在设计初创公司时，我们可以从自然选择的运作方式中汲取令人惊讶的具体经验！第一个例子是：让我们看看大自然对复制粘贴的态度。

Avoid abstractions. Use copy-paste-edit! 避免抽象。使用复制-粘贴-编辑！

Fun fact: the snake went full circle. 有趣的事实：蛇绕了一圈。

How did your arms and legs come to be? Notice a difference between you and Pikaia: Pikaia has lots of repeated segments, but your body has just a few specialized segments. 你的胳膊和腿是怎么长出来的？注意你和 Pikaia 的区别： Pikaia 有很多重复的节段，但你的身体只有几个特殊的节段。

This happens so often in evolution that it has a name: it’s called Williston’s Law. Roughly, it says that nature loves to copy-paste and edit. Nature takes a versatile body part like a leg or a tooth, duplicates it many times, gives each one a chance to specialize, then kills off the excess. 这种现象在进化过程中经常发生，因此有一个名字：这就是所谓的威利斯顿定律。大致来说，它说的是 大自然喜欢复制粘贴和编辑。 大自然赋予了身体多功能的部位，比如腿或牙齿，重复多次，让每个人都有机会专攻某一领域，然后杀死多余的。

The more Hox genes you paste, the more shapes you can make! 粘贴的 Hox 基因越多，可以制作的形状就越多！

Nature's love of copy-paste can be seen genetically as well. When you were still an embryo, your body plan was drawn out by 39 different "Hox" genes. Each Hox gene corresponds to one part of your body. But our early ancestors had just one Hox gene! Nature then copy-pasted and edited it many times, and now we have 39 of them, each with a different function. 大自然对复制粘贴的热爱在基因层面也可见一斑。当你还是胚胎时，你的身体结构是由 39 个不同的“Hox”基因构成的。每个 Hox 基因对应着你身体的一部分。但我们的早期祖先只有一个 Hox 基因！大自然随后对它进行了多次复制粘贴和编辑，如今我们拥有 39 个 Hox 基因，每个基因都发挥着不同的功能。

In Computer Science courses, they gave us clear, static requirements, and we were supposed to implement these with "clean code". But programs designed for certain, static requirements look very different to programs designed for uncertainty and change! 在计算机科学课程中，他们会给我们提供清晰、静态的需求，并要求我们用“干净的代码”来实现这些需求。但是 ，为确定的静态需求而设计的程序，与为不确定性和变化而设计的程序，看起来截然不同！

Say you want to add a new kind of "big button" component. Instead of introducing an abstract "button" concept, try duplicating the existing button component, and allowing it to evolve along its own path. Even if your "button" abstraction is right under current requirements, it can stop you from implementing new requirements! What's more, repetitive copy-paste code is friendly to AI-assisted change. 假设您想添加一种新的“大按钮”组件。与其引入抽象的“按钮”概念，不如尝试复制现有的按钮组件，并让它沿着自己的路径发展。即使您的“按钮”抽象_完全_符合_当前_需求，它也会阻碍您实现_新的_需求！而且，重复的复制粘贴代码对 AI 辅助更改很友好。

Avoid splitting stuff up. Use one big blob! 避免将东西分开。使用一个大块！

Why does the peacock not ditch that stupid enormous tail? Well, the males can’t, because the females select for it. But the peahen can’t ditch her selection choice either: she'd have sons with small tails, who wouldn’t get selected! 为什么雄孔雀不放弃那条愚蠢的大尾巴呢？嗯，雄孔雀不能放弃，因为雌孔雀会选择它。但雌孔雀也不能放弃她的选择：她会生出尾巴小的儿子，而这些儿子不会被选中！

Peacock sequence diagram. 孔雀序列图。

Protocols inhibit change, and the peacock has a broken protocol that equates "large tails" with "fitness". An asexual peacock could ditch the tail. But with two sexes, there’s no way to change without global coordination. 协议阻碍了变革， 孔雀的协议被破坏了将“大尾巴”等同于“适应性”。无性孔雀可能会抛弃尾巴。但对于两种性别来说，如果没有全球协调，就不可能做出改变。

Nature's lesson for us: avoid splitting stuff up. And especially avoid any splits that create distributed systems! It’s easier to change one big thing than to change many small things talking to each other. Your professor is not here to punish you any more. It's okay to keep everything in one file! 大自然给我们的教训： 避免分裂事物。 尤其要避免任何造成分布式系统的分裂！改变一件大事更容易而不是改变彼此交谈的许多小事情。你的教授不会再惩罚你了。将所有内容保存在一个文件中是可以的！

Even the earliest prototypes often look like this: a client, a database, and an API between them. But with this design, you’ve already introduced two splits! 即使是最早的原型也常常是这样的：一个客户端、一个数据库，以及它们之间的 API。但这种设计其实已经引入了两个拆分！

By contrast, the first prototype of Granola was an isolated desktop app. It talks to the things it needs to, but is otherwise a single blob. 相比之下， Granola 的第一个原型是一个独立的桌面应用程序。 它与需要对话的事物对话，但除此之外，它只是一个单一的斑点。

We eventually had to have some server-side stuff. Typically this means building an API layer. But we avoided that by using Supabase, which lets clients directly interact with your central database. Instead of two interfaces slowing you down, we just had one. 我们最终不得不添加一些服务器端的东西。通常这意味着构建一个 API 层。但我们通过使用 Supabase 避免了这个问题，它允许客户端直接与你的中央数据库交互。这样就不用再使用两个界面来拖慢速度了，我们只需要一个界面。

Avoid auto-update. Use direct distribution! 避免自动更新。使用直接分发！

Btw, notice all the repeated segments. 顺便说一句，请注意所有重复的片段。

Here are some of the bizarre life forms that lived alongside our ancestor Pikaia. Life is always exploring many variants in parallel! That’s the only way to quickly explore a giant possibility space. 以下是一些与我们的祖先_皮卡亚（Pikaia）_ 共同生活的奇异生命形式。生命总是在并行探索许多变体！这是快速探索巨大可能性空间的唯一方法。

Yet most software distribution is sequential. v1 then v2 then v3, and so on. Web apps are constrained to a single “production” version being explored by users. Mobile apps are constrained to a single version published on an app store. Bad for exploration. 然而大多数软件分发都是连续的。 v1 然后是 v2 ，然后是 v3 ，以此类推。Web 应用仅限于供用户探索的单一“生产”版本。移动应用仅限于在应用商店发布的单一版本。不利于用户探索。

Instead, Granola is directly distributed via a .dmg file. This means we can make some radical code changes, cut a new build, and send it to a single user. This is great for evolving a product, because we're evaluating many versions in parallel. 相反，Granola 直接通过 .dmg 文件分发。这意味着我们可以进行一些彻底的代码修改，创建一个新的版本，然后将其发送给单个用户。 这对于产品的改进非常有帮助，因为我们正在同时评估多个版本。

(You might be thinking: "But we have feature flags." Good, but you can't make radical changes on a feature flag, because your single production version must act as a superposition of all possible software changes.) （您可能会想：“但是我们有功能标志。”很好，但是您不能对功能标志进行_彻底的_更改，因为您的单个生产版本必须充当所有可能的软件更改的叠加。）

In early life, avoid linear auto-update. Instead, use direct distribution. 在早期阶段，避免使用线性自动更新。相反，使用直接分发。

Help your software versions die 帮助您的软件版本消亡

Copy-pasted eyes. 复制粘贴的眼睛。

Opabinia lived alongside our ancestor. He had five eyes on stalks, and a single, central claw. But Opabinia's descendants are not alive today — perhaps because he was a stupid design. Most of the Cambrian forms were evolutionary dead ends. _奥帕宾尼亚_与我们的祖先生活在同一时期。它有五只分布在柄上的眼睛，以及一只位于中央的爪子。但_它_的后代如今已不复存在——或许是因为它的设计本身就很愚蠢。大多数寒武纪生物都走向了进化的死胡同。

Without death, natural selection doesn’t work! And yet much conventional advice makes it hard for us to kill our bad software versions. 没有死亡，自然选择就不起作用！然而，许多传统的建议却让我们难以彻底消灭那些糟糕的软件版本。

(From left) Living Granola, dead Granola. （从左至右）活的格兰诺拉麦片，死的格兰诺拉麦片。

What is a "dead" software version? It's one with no more references to it. Think garbage collection. So, to let your software die, avoid unnecessary references to it. Let's look at common references we can avoid. 什么是“死”的软件版本？它是指不再被引用的版本。想想垃圾回收机制。所以， 为了让你的软件“死”下来，请避免对它进行不必要的引用。 让我们看看我们可以避免的常见引用。

Avoid automated tests. Test manually! 避免自动化测试。手动测试！

Hey, come back here! 嘿，回来吧！

So you’ve made a software change, but now the tests are broken. Don't feel bad: it's the tests' fault, not yours! 你修改了软件，但测试却出问题了。别难过：这是测试的错，不是你的！

Tests are chains, stopping your program from running free. The tests say: "Bad code! Stop changing! Go back and be the previous program!" 测试就像锁链，阻止你的程序自由运行。 测试表明： “糟糕的代码！停止修改！” 回去做以前的程序吧！”

So avoid writing tests. Just test the things that are unlikely to change. Test everything else manually. 所以，避免编写测试。只测试那些不太可能改变的东西。其余部分都手动测试。

(Note: type-checking is different. It tests correctness properties that apply to any program. A good type-checker lets you move fast without breaking as many things.) （注意：类型检查有所不同。它测试适用于_任何_程序的正确性属性。好的类型检查器可以让你快速移动而不会破坏太多东西。）

Avoid unnecessary users. Build for yourself! 避免不必要的用户。为自己构建！

Please support us! 请支持我们！

You've experienced this too: you want to remove something from your product, but some obscure users loudly complain, so you give in. 你也经历过这种情况：你想从产品中删除一些东西，但是一些不知名的用户大声抱怨，所以你屈服了。

Conventional advice says to launch ASAP. But people using your software keep it alive, and so they can slow down change. 传统建议是尽快发布。但使用你的软件的人会让它保持活力，所以他们可以放慢变化的速度。

Instead, avoid all unnecessary users. Build for a small set of target users. (That target might just be yourself!) 相反，要避开所有不必要的用户。只为一小部分目标用户构建。（这个目标用户可能就是你自己！）

Avoid landing pages. Onboard manually! 避免使用落地页。手动引导！

We'll remember you forever! 我们会永远记住你！

Conventional advice is to focus on top-of-funnel experience. Build a landing page to sell the product. Write docs and build a slick onboarding into the app. 传统建议是专注于漏斗顶端的体验。创建一个落地页来销售产品。编写文档，并在应用中构建流畅的引导流程。

But all these user-facing resources reference a specific version of your product! And so they make it harder to kill that version. 但是所有这些面向用户的资源都引用了产品的特定版本！因此，它们使得淘汰该版本变得更加困难。

At Granola, we deliberately spent a long time pre-launch. We targeted a small niche, and manually onboarded everyone. This reduced distractions, made it easier to throw stuff away, and helped us practice for when we eventually did build a landing page and onboarding. 在 Granola，我们特意花了很长时间进行产品发布前准备。 我们瞄准了小众市场，并手动让每个人都加入。这样可以减少干扰，让扔东西变得更容易，并帮助我们为最终构建登陆页面和入职培训做准备。

Best practices for pre-launch software are very different 预发布软件的最佳实践截然不同

Midwit meme for you to copy-pasta. Midwit meme 供您复制粘贴。

Conventional advice says that good code is "clean code" with high test coverage, and that teams prioritize early launches, continuous delivery, and top-of-funnel experience. But in an early startup, your sole focus is to search for a product, and these "best practices" can slow down this search. Try optimizing for change, by using low-abstraction copy-paste, all in one place, with no tests. Distribute your app manually, and onboard people manually. That's what we did. After 12 months, we now think we've found our product, and it might be time to re-evaluate our approach. If you’d like to join our journey, get in touch! 传统建议认为，好的代码是“干净的代码”，并且测试覆盖率高，团队优先考虑早期发布、持续交付和漏斗顶端体验。但在初创公司初期，你唯一的重点是寻找产品，而这些所谓的“最佳实践”可能会减慢你的搜索速度。尝试使用低抽象的复制粘贴功能，将所有代码集中在一个地方，无需测试，从而针对变化进行优化。手动分发你的应用，并手动引导用户。我们就是这样做的。12 个月后，我们认为我们已经找到了我们的产品，也许是时候重新评估我们的方法了。如果您想加入我们的旅程，请联系我们！