<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Y Combinator on 方糖猫Blog</title>
    <link>https://ftmao.com/blog/tags/y-combinator/</link>
    <description>AI 视频、AI Agent 与工程实践笔记</description>
    <generator>Hugo</generator>
    <language>zh-CN</language>
    <lastBuildDate>Fri, 08 Sep 2023 10:40:00 +0800</lastBuildDate><atom:link href="https://ftmao.com/blog/tags/y-combinator/index.xml" rel="self" type="application/rss+xml" /><item>
      <title>《Founders at Work》笔记：32 份一手证词比二手报告值钱</title>
      <link>https://ftmao.com/blog/bookstore/founders-at-work-book-notes/</link>
      <pubDate>Fri, 08 Sep 2023 10:40:00 +0800</pubDate>
      <guid>https://ftmao.com/blog/bookstore/founders-at-work-book-notes/</guid>
      <description>&lt;h1 id=&#34;founders-at-work笔记32-份一手证词比二手报告值钱&#34;&gt;《Founders at Work》笔记：32 份一手证词比二手报告值钱&lt;/h1&gt;
&lt;blockquote&gt;
&lt;p&gt;Jessica Livingston 是 Y Combinator 的联合创始人，2007 年她把对 32 位科技公司创始人的访谈结集出版，就是这本《Founders at Work》。这本书没有框架、没有方法论章节、没有&amp;quot;创业十步法&amp;quot;——它就是一叠访谈实录：PayPal 的 Max Levchin、Apple 的 Wozniak、Hotmail 的 Sabeer Bhatia、Viaweb 的 Paul Graham、Blogger 的 Ev Williams、craigslist 的 Craig Newmark……每个人对着录音笔讲自己当年怎么把公司从零做起来的。&lt;/p&gt;
&lt;p&gt;我读它的动机很直接：市面上讲创业的书大多是记者和学者写的二手报告，故事被磨得又圆又亮，因果链条清晰得像事后编的。而这本书的价值恰恰在于&amp;quot;没打磨&amp;quot;——幸存者自己讲的故事里，能看到 pivot 的狼狈、缺钱的窘迫、被投资人拒绝的真实细节。一手证词比二手报告值钱，这是我读完最大的方法论收获。&lt;/p&gt;
&lt;p&gt;这篇笔记干三件事：先讲为什么一手访谈这种体裁值钱；再从 32 份访谈里提炼出反复出现的共性模式；最后挑 5 个案例展开讲关键细节。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;hr&gt;
&lt;h2 id=&#34;一为什么一手访谈--二手报告&#34;&gt;一、为什么一手访谈 &amp;gt; 二手报告&lt;/h2&gt;
&lt;p&gt;做工程的人都知道：线上事故的复盘，值班工程师的口述记录比一个月后管理层写的 PPT 有用得多。PPT 里事故是一条干净的因果链：&amp;ldquo;因为配置错误，所以服务宕机，所以我们加了检查项&amp;rdquo;。而口述记录里全是毛边：&amp;ldquo;当时我以为是缓存问题，重启了两次没好，才发现 DNS 也不对，中间还有半小时我们在争论要不要回滚&amp;rdquo;。&lt;/p&gt;
&lt;p&gt;二手报告的毛病有三个：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;幸存者偏差的二次方&lt;/strong&gt;。报告本来就在写幸存者，写的时候又把幸存者叙事里的随机性和运气抹掉，只剩下&amp;quot;远见&amp;quot;和&amp;quot;执行力&amp;quot;；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;事后合理化&lt;/strong&gt;。人回忆成功路径时会不自觉地把它讲成一条直线，当年明明是从 A 想法 pivot 到 B 才活下来的，讲出来就成了&amp;quot;我们一开始就看好 B&amp;quot;；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;细节损耗&lt;/strong&gt;。真正有用的信息全在细节里——融不到钱时团队怎么活、第一个用户从哪来、被巨头拒绝时怎么办——这些在二手报告里通常被压缩成一句&amp;quot;经历了艰难的早期&amp;quot;。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;同一段历史，两种载体，信息的衰减路径完全不同：&lt;/p&gt;
&lt;div class=&#34;code-block&#34;&gt;
    &lt;button class=&#34;code-copy&#34; type=&#34;button&#34; hidden aria-label=&#34;Copy code to clipboard&#34;&gt;
      &lt;span class=&#34;code-copy-label&#34; aria-hidden=&#34;true&#34;&gt;Copy&lt;/span&gt;
    &lt;/button&gt;
    &lt;pre tabindex=&#34;0&#34;&gt;&lt;code class=&#34;language-mermaid&#34; data-lang=&#34;mermaid&#34;&gt;flowchart LR
    subgraph SRC[&amp;#34;真实历史：混乱、偶然、缺钱、走运&amp;#34;]
        R[&amp;#34;当事人的记忆&amp;lt;br/&amp;gt;带毛边、带情绪、带具体数字&amp;#34;]
    end
    subgraph PATH1[&amp;#34;一手路径&amp;#34;]
        A[&amp;#34;访谈实录&amp;lt;br/&amp;gt;具体、未经包装&amp;lt;br/&amp;gt;但可能有记忆偏差&amp;#34;] --&amp;gt; A1[&amp;#34;读者自己提炼模式&amp;#34;]
    end
    subgraph PATH2[&amp;#34;二手路径&amp;#34;]
        B[&amp;#34;记者/学者转述&amp;#34;] --&amp;gt; B1[&amp;#34;被磨成光滑因果链&amp;lt;br/&amp;gt;运气被删除&amp;lt;br/&amp;gt;细节被压缩成&amp;#39;早期艰难&amp;#39;&amp;#34;]
    end
    R --&amp;gt; A
    R --&amp;gt; B&lt;/code&gt;&lt;/pre&gt;
  &lt;/div&gt;&lt;p&gt;两条路径各有偏差：一手路径的偏差是&amp;quot;当事人记错或自我美化&amp;quot;，二手路径的偏差是&amp;quot;转述者替你做了归因&amp;quot;。前者你能自己校准，后者你连校准的机会都没有——因果链已经替你想好了。&lt;/p&gt;
&lt;p&gt;Livingston 的访谈好在她问的都是具体的、难以编造的问题：&amp;ldquo;你们第一天在干什么？&amp;ldquo;&amp;ldquo;钱什么时候快烧完的？&amp;ldquo;&amp;ldquo;投资人具体是怎么拒绝你们的？&amp;ldquo;被访者的回答未经公关包装，经常有&amp;quot;说实话当时我们根本不知道在干什么&amp;quot;这种话。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;感悟&lt;/strong&gt;：这跟看技术文档是一个道理——官方文档告诉你 API 怎么用，但只有源码和 issue 区告诉你它在什么情况下会炸。一手访谈就是创业史的&amp;quot;源码 + issue 区&amp;rdquo;。&lt;/p&gt;
&lt;p&gt;当然，一手访谈也不是没有偏差：幸存者毕竟还是幸存者，记忆会自我美化。我的读法是：&lt;strong&gt;信细节，不信结论&lt;/strong&gt;。创始人总结的&amp;quot;成功是因为我们坚持用户至上&amp;quot;听听就好，但&amp;quot;我们账上只剩够发一个月工资的钱&amp;quot;这种细节，多半是真的。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;二32-份访谈里反复出现的创业共性模式&#34;&gt;二、32 份访谈里反复出现的创业共性模式&lt;/h2&gt;
&lt;p&gt;把 32 个故事叠在一起看，有些模式出现的频率高到不可能是巧合。我画了一张图来归纳：&lt;/p&gt;
&lt;div class=&#34;code-block&#34;&gt;
    &lt;button class=&#34;code-copy&#34; type=&#34;button&#34; hidden aria-label=&#34;Copy code to clipboard&#34;&gt;
      &lt;span class=&#34;code-copy-label&#34; aria-hidden=&#34;true&#34;&gt;Copy&lt;/span&gt;
    &lt;/button&gt;
    &lt;pre tabindex=&#34;0&#34;&gt;&lt;code class=&#34;language-mermaid&#34; data-lang=&#34;mermaid&#34;&gt;flowchart TB
    subgraph P1[&amp;#34;① 起点：想法经常不是最后做成的那个&amp;#34;]
        A1[&amp;#34;从别的想法出发&amp;lt;br/&amp;gt;pivot 是常态而非意外&amp;#34;] --&amp;gt; A2[&amp;#34;PayPal: PalmPilot 加密 → 邮件支付&amp;lt;br/&amp;gt;Blogger: 项目管理工具 → 博客发布器&amp;#34;]
    end
    subgraph P2[&amp;#34;② 早期：不被理解&amp;#34;]
        B1[&amp;#34;投资人看不懂&amp;lt;br/&amp;gt;巨头看不上&amp;lt;br/&amp;gt;用户也不是调研出来的&amp;#34;] --&amp;gt; B2[&amp;#34;Apple 被 HP 拒绝多次&amp;lt;br/&amp;gt;Hotmail 融资四处碰壁&amp;#34;]
    end
    subgraph P3[&amp;#34;③ 生存：缺钱是默认状态&amp;#34;]
        C1[&amp;#34;融资艰难&amp;lt;br/&amp;gt;创始人不拿工资&amp;lt;br/&amp;gt;账上只剩几个月&amp;#34;] --&amp;gt; C2[&amp;#34;Blogger 员工走光只剩 Ev 一人&amp;lt;br/&amp;gt;Viaweb 靠接单养产品&amp;#34;]
    end
    subgraph P4[&amp;#34;④ 顺序：先有产品，后有商业模式&amp;#34;]
        D1[&amp;#34;先把东西做出来&amp;lt;br/&amp;gt;让用户用上&amp;#34;] --&amp;gt; D2[&amp;#34;Hotmail 增长先于盈利模型&amp;lt;br/&amp;gt;craigslist 多年不收费&amp;#34;]
    end
    P1 --&amp;gt; P2 --&amp;gt; P3 --&amp;gt; P4&lt;/code&gt;&lt;/pre&gt;
  &lt;/div&gt;&lt;p&gt;这四条单独看都不新鲜，创业鸡汤里全有。但访谈实录的价值在于给你看&lt;strong&gt;每条模式的具体纹理&lt;/strong&gt;：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;pivot 不是战略会上拍板的优雅转身，而是&amp;quot;原来的东西没人要，账上钱在烧，不得不试点别的&amp;rdquo;；&lt;/li&gt;
&lt;li&gt;&amp;ldquo;不被理解&amp;quot;不是一句带过，而是 Apple 被 HP 正式拒绝了不止一次，Wozniak 甚至愿意把设计白送给 HP；&lt;/li&gt;
&lt;li&gt;&amp;ldquo;缺钱&amp;quot;不是励志修辞，而是 Ev Williams 看着员工一个个离开、最后一个人守着服务器；&lt;/li&gt;
&lt;li&gt;&amp;ldquo;先做产品后想商业模式&amp;quot;不是方法论选择，而是大多数时候根本没时间想——Hotmail 的用户增长速度让带宽账单先成了问题。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;感悟&lt;/strong&gt;：读多了你会发现，成功的创业故事和失败的创业故事，在早期阶段长得几乎一模一样——都缺钱、都被拒绝、都在 pivot。差别往往只在&amp;quot;有没有活到 pivot 成功的那一天&amp;rdquo;。所以&amp;quot;活下去&amp;quot;不是底线思维，它就是主线。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;三案例一paypal两次-pivot-才到支付&#34;&gt;三、案例一：PayPal——两次 pivot 才到支付&lt;/h2&gt;
&lt;p&gt;PayPal 的故事是&amp;quot;pivot 是常态&amp;quot;这条模式最完整的样本。Max Levchin 在访谈里讲得很坦白：&lt;/p&gt;
&lt;p&gt;最初的创业方向（公司前身 FieldLink，后改名 Confinity）是&lt;strong&gt;做 PalmPilot 上的加密技术&lt;/strong&gt;——在 PDA 上存储加密信息，比如密码和卡号。技术很酷，问题是没人需要。于是他们在这个技术上加了一层应用：&lt;strong&gt;通过 PalmPilot 的红外端口互相转账&lt;/strong&gt;——两台 PalmPilot 对着&amp;quot;嘀&amp;quot;一下，钱就过去了。这个演示效果极好，投资人当场被镇住，钱也拿到了。&lt;/p&gt;
&lt;p&gt;然后尴尬的事情发生了：红外转账是个炫酷的演示，但现实中没几个人同时拿着 PalmPilot 站在一起还要互相转账。真正有人用的，是他们顺手做的那个&amp;quot;网页版/邮件版&amp;quot;的支付功能——给功能做演示用的网站，结果用户全跑到网页上转账去了，尤其 eBay 上的卖家买家。&lt;/p&gt;
&lt;p&gt;公司的应对是跟着用户走：把重心彻底转到网页/邮件支付，PalmPilot 那条线砍掉。这才有了后来我们认识的 PayPal。&lt;/p&gt;
&lt;p&gt;几个我觉得值得记的细节：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;演示效果 ≠ 市场需求&lt;/strong&gt;。红外转账在投资人面前是无敌的 demo，在市场上是无用的功能。能分清这两者的团队不多；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;安全攻防是真实的生存战&lt;/strong&gt;。Levchin 讲了大量与欺诈者对抗的细节——俄罗斯的黑客团伙规模化地薅羊毛，PayPal 被迫自研风控（后来演变成著名的验证码应用之一和整套反欺诈系统）。支付公司的核心竞争力一半是反欺诈；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;pivot 不是抛弃技术&lt;/strong&gt;。早期的加密技术积累，最后全用在了支付安全上。换方向不等于清零。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;感悟&lt;/strong&gt;：这个案例对我这个工程师的触动是——工程师最容易爱上&amp;quot;技术上漂亮&amp;quot;的东西（红外点对点转账多优雅），但市场只为&amp;quot;解决真实麻烦&amp;quot;的东西付钱（网上陌生人之间怎么安全地付款）。Levchin 自己就是技术出身，他能两次压下对技术的偏爱跟着用户走，这比写出加密算法难多了。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;四案例二apple被-hp-拒绝了五次的个人电脑&#34;&gt;四、案例二：Apple——被 HP 拒绝了五次的个人电脑&lt;/h2&gt;
&lt;p&gt;Wozniak 的访谈是全书里我最喜欢的一篇，因为他讲东西的方式完全是工程师的：具体到芯片选型、怎么省元器件、怎么在频率上做手脚绕过 FCC。&lt;/p&gt;
&lt;p&gt;关键史实线：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Wozniak 当时在 HP 做计算器工程师，业余泡在 &lt;strong&gt;Homebrew Computer Club&lt;/strong&gt;（家酿计算机俱乐部）——一群硬件爱好者每周聚会交换设计和想法的地方；&lt;/li&gt;
&lt;li&gt;Apple I 的整机设计是他在 HP 的工作之余做出来的，用的是便宜的 MOS 6502 处理器（当时主流芯片太贵），整机元器件省到极致——这是他的手艺，也是 Apple I 便宜的原因；&lt;/li&gt;
&lt;li&gt;按照他与 HP 的雇佣协议，他做的设计要先给 HP 看。他&lt;strong&gt;真心希望 HP 来做这个产品&lt;/strong&gt;，前后找了 HP 五次——部门经理、实验室负责人，一层层往上提案，全部被拒。HP 的理由很&amp;quot;合理&amp;rdquo;：这不是 HP 该做的产品形态，个人电脑没有市场；&lt;/li&gt;
&lt;li&gt;被拒完之后，他才和 Jobs 自己干。Apple I 卖的是主板（用户自己配机箱、键盘、显示器），真正起飞是后来的 Apple II。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;两个细节值得单独说：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;① Homebrew 俱乐部这种&amp;quot;同好社区&amp;quot;的作用被严重低估。&lt;/strong&gt; Wozniak 反复说，他设计电脑的初衷很大程度是&amp;quot;做给俱乐部的朋友们看、让他们也能用上&amp;rdquo;——先有一个懂你在干什么的社区，再有产品，再有公司。这个顺序后来反复出现（craigslist 也是一个社区先于公司的故事）。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;② 巨头的拒绝不是愚蠢，是结构性的。&lt;/strong&gt; HP 拒绝 Apple I 不是因为没有聪明人，而是 HP 的判断框架里&amp;quot;个人电脑&amp;quot;不属于任何现有产品线。这事对今天一样成立：大公司拒掉一个新方向，往往不是看走眼，而是它的组织结构就看不见这类东西。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;感悟&lt;/strong&gt;：Wozniak 这篇访谈里没有一点&amp;quot;怀才不遇&amp;quot;的怨气，他说 HP 拒绝了五次时语气就像在说一次 code review 没过。这种纯粹的&amp;quot;我就想把这个东西造出来&amp;quot;的动机，大概是他能在车库里待得住的原因。动机纯度在苦日子里是硬通货。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;五案例三hotmail一行签名档带来的病毒增长&#34;&gt;五、案例三：Hotmail——一行签名档带来的病毒增长&lt;/h2&gt;
&lt;p&gt;Hotmail 的故事（Sabeer Bhatia 与 Jack Smith）是&amp;quot;先做产品后想商业模式&amp;quot;和&amp;quot;增长先于盈利&amp;quot;的教科书。&lt;/p&gt;
&lt;p&gt;史实线：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;两人当时是 Apple 的同事（在 FirePower Systems 也有交集），最初的创业想法其实不是邮箱——他们想做一个基于网页的个人数据库/工具类项目（JavaSoft），融资时被投资人否了。做网页邮箱的灵感来自一个很实际的需求：&lt;strong&gt;公司防火墙挡了他们的私人邮箱，两人之间传文件都麻烦&lt;/strong&gt;，于是想到——如果邮箱在网页上，从任何机器都能登；&lt;/li&gt;
&lt;li&gt;找钱极难。Tim Draper（Draper Fisher Jurvetson）最后投了，金额不大（几十万美元级别）。谈判里著名的插曲是估值博弈，但更重要的是 Draper 贡献了一个影响深远的建议：&lt;strong&gt;在每封发出的邮件底部自动加一行签名档——&amp;ldquo;P.S. Get your free email at Hotmail&amp;rdquo;&lt;/strong&gt;；&lt;/li&gt;
&lt;li&gt;这行签名档的效果是：每个用户发出的每一封邮件都是一次推荐，收件人点链接注册，他发出的邮件又带签名档。这就是后来被命名为&amp;quot;病毒式营销&amp;rdquo;（viral marketing）的东西——这个词很大程度上就是因为 Hotmail 这个案例被造出来的；&lt;/li&gt;
&lt;li&gt;增长曲线陡到服务器和带宽先撑不住。上线后短时间内用户从零涨到百万级、千万级，成为全球最大的邮箱服务之一；&lt;/li&gt;
&lt;li&gt;1997 年底，上线约一年半后，&lt;strong&gt;以约 4 亿美元的股票卖给了微软&lt;/strong&gt;。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;值得琢磨的点：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;病毒增长不是&amp;quot;营销技巧&amp;rdquo;，是&lt;strong&gt;产品机制&lt;/strong&gt;：签名档寄生在产品最核心的动作（发邮件）上，不花一分钱广告费。后来所有做增长的人都在找自己产品里那个&amp;quot;寄生点&amp;rdquo;；&lt;/li&gt;
&lt;li&gt;商业模式是后置的。Hotmail 先有了千万级用户，盈利（广告）是后来的事，卖给微软时收入模型也远谈不上成熟。先有规模，再变现——这条路线在 1996 年是非常反直觉的；&lt;/li&gt;
&lt;li&gt;需求的起点小得可笑：两个人想绕开公司防火墙收发邮件。大需求经常伪装成一个小麻烦。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;感悟&lt;/strong&gt;：Hotmail 让我重新理解了&amp;quot;分发&amp;quot;这个词。工程师做产品默认想的是&amp;quot;把功能做好&amp;rdquo;，而 Hotmail 的胜负手在于把&amp;quot;分发机制&amp;quot;直接焊进了产品动作里。代码写得好只能让你不输，分发机制才能让你赢。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;六案例四viaweb最早的网页应用和它教会-yc-的事&#34;&gt;六、案例四：Viaweb——最早的网页应用，和它教会 YC 的事&lt;/h2&gt;
&lt;p&gt;Viaweb（Paul Graham 与 Robert Morris，后来 Trevor Blackwell 加入）是这本书里和我所在的行业连接最深的故事——他们 1998 年以约 4900 万美元（股票）卖给 Yahoo，产品改名 Yahoo Store；而 Graham 后来用这笔钱和这段经历合伙创办了 Y Combinator，这本书的作者 Jessica Livingston 就是他的合伙人（也是妻子）。&lt;/p&gt;
&lt;p&gt;史实线：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;1995 年起步，做的产品是&lt;strong&gt;让商家通过浏览器搭在线商店&lt;/strong&gt;——今天听起来平平无奇，但在 1995 年这是激进的想法：当时的软件都要装在本机，&amp;ldquo;软件跑在服务器上、用户用浏览器操作&amp;quot;这件事，Viaweb 是最早做出来的一批，Graham 称之为最早的网页应用（web application）之一；&lt;/li&gt;
&lt;li&gt;技术栈很野：后端大量用 Lisp。这个选择在访谈里被反复问到，Graham 的态度是 Lisp 让他们迭代速度比竞争对手快——功能可以飞快上线，这在抢占新市场时是真优势；&lt;/li&gt;
&lt;li&gt;早期靠&amp;quot;什么都干&amp;quot;活着：帮商家建站、手动给商家配图片、做咨询式服务养产品。用户是个位数的时候，onboarding 全手工；&lt;/li&gt;
&lt;li&gt;1998 年 Yahoo 收购，约 4900 万美元，产品成为 Yahoo Store。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;这个案例里我觉得最值钱的三条经验（后来全成了 YC 的教条）：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;&amp;ldquo;做不能规模化的事&amp;rdquo;（do things that don&amp;rsquo;t scale）&lt;/strong&gt;。早期手工服务每一个商家，看起来笨，但那是直接理解用户的唯一方式。这条后来被 Graham 写成著名文章，源头就在 Viaweb；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;迭代速度是早期公司唯一的护城河&lt;/strong&gt;。没有品牌、没有钱、没有渠道，你唯一能比对手快的就是发布速度。工具链（他们选 Lisp）要为迭代速度服务；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;小团队 + 低烧钱 = 活得久&lt;/strong&gt;。Viaweb 三年里人很少、花得省，所以能等到市场（电商）自己成熟。&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;&lt;strong&gt;感悟&lt;/strong&gt;：Graham 后来写的所有创业文章，几乎都能在 Viaweb 这段经历里找到原型。读这一章的感觉像是读到了 YC 方法论的&amp;quot;创世区块&amp;rdquo;。也再次印证了一手材料的价值：二手转述告诉你&amp;quot;YC 主张精益创业&amp;quot;，一手访谈告诉你这个主张是从&amp;quot;当年我们穷得只能精益&amp;quot;里长出来的。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;七案例五blogger员工走光后一个人守住的产品&#34;&gt;七、案例五：Blogger——员工走光后，一个人守住的产品&lt;/h2&gt;
&lt;p&gt;Ev Williams 的 Blogger 故事是&amp;quot;缺钱是默认状态&amp;quot;这条模式最极端的版本，也是全书里我觉得最悲壮的一篇。&lt;/p&gt;
&lt;p&gt;史实线：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Blogger 出自 Pyra Labs，而 Pyra Labs 最初做的产品是&lt;strong&gt;一个项目/团队协作管理工具（Pyra）&lt;/strong&gt;，Blogger 只是团队内部给自己用的小发布工具——又一个 pivot 案例：内部工具比主产品先有了用户；&lt;/li&gt;
&lt;li&gt;2000-2001 年互联网泡沫破裂，Pyra Labs 融资无望，账上的钱烧完了。Ev Williams 在访谈里很平静地讲了最难堪的部分：付不出工资，员工一个个离开，&lt;strong&gt;最后整个公司只剩他一个人&lt;/strong&gt;，服务器账单都成问题，他继续一个人维护 Blogger 的服务；&lt;/li&gt;
&lt;li&gt;转机来自产品本身的生命力：博客这个形态在 2001-2002 年持续自然增长，Blogger 是最大的入口之一。后来推出了付费版（Blogger Pro）多少回了一点血；&lt;/li&gt;
&lt;li&gt;2003 年，Google 收购了 Pyra Labs（Blogger）。价格未公开，但这一步让&amp;quot;博客&amp;quot;正式进入主流视野，也让 Ev 有了后续创业的本钱（之后是 Twitter，当然那是书外的故事了）。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;这篇访谈里最打动人的不是&amp;quot;坚持&amp;quot;这个抽象品质，而是坚持的具体形态：没有钱、没有团队、没有投资人的背书，只剩&amp;quot;这个产品还有人在用，我不能让它挂掉&amp;quot;。用户还在增长这个事实，成了他继续的唯一理由。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;感悟&lt;/strong&gt;：很多创业建议说&amp;quot;数据不好就该放弃&amp;quot;，但 Blogger 的案例给了另一面：当外部环境（资本市场）塌了、而用户数据还在涨时，该信哪个？Ev 信了用户。当然，这话说起来轻巧——他信用户的代价是一个人扛了将近两年。这类决策没有公式，只有&amp;quot;你对这个需求的真实性有多确定&amp;quot;。&lt;/p&gt;
&lt;p&gt;另外值得记一笔的是 Blogger 的 pivot 结构：主产品（协作工具）没成，内部工具（博客发布器）成了。&lt;strong&gt;内部工具外化成产品&lt;/strong&gt;这条路径后来反复出现（Slack、很多开发者工具都是这个剧本），Blogger 是早期样本。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;八顺带一提craigslist一个拒绝长大的例外&#34;&gt;八、顺带一提：craigslist——一个拒绝长大的例外&lt;/h2&gt;
&lt;p&gt;Craig Newmark 的故事值得单独提一句，因为它是全书模式的一个&amp;quot;反例&amp;quot;，而反例最能校准认知：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;1995 年，Craig 在旧金山给朋友们发活动信息的&lt;strong&gt;邮件列表&lt;/strong&gt;，就是 craigslist 的全部起点。邮件列表装不下了，做成网页；用户要发招聘信息，加招聘版块；要租房信息，加租房版块——所有功能都是用户要什么加什么；&lt;/li&gt;
&lt;li&gt;它多年保持极小的团队、极简的页面（那个著名的朴素界面），拒绝 VC，很多年只对少数类别的发帖收费，其余免费；&lt;/li&gt;
&lt;li&gt;结果是：没有病毒营销、没有 pivot、没有惊心动魄的融资战，一个&amp;quot;慢公司&amp;quot;长成了分类广告的巨头，顺便把美国报纸的分类广告业务打残了。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;craigslist 说明共性模式不是普适定律：如果需求真实且增长自发生，&amp;ldquo;不融资、不 pivot、不追增长&amp;quot;也能成。但这种路径的前提是你对增长速度没有执念，且市场窗口允许你慢慢来——1995 年的分类广告允许，大多数今天的市场不允许。&lt;/p&gt;
&lt;h2 id=&#34;八附其他几篇值得一读的访谈&#34;&gt;八·附：其他几篇值得一读的访谈&lt;/h2&gt;
&lt;p&gt;篇幅所限没有逐篇展开，但 32 篇里还有几篇的质量不输上面五个案例，简要标注一下，方便按兴趣翻原书：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Paul Buchheit（Gmail）&lt;/strong&gt;：Gmail 起源于他在 Google 内部做的项目，用大量被&amp;quot;不可能&amp;quot;包围的判断（网页邮箱给 1GB 容量、全文搜索代替文件夹归类），讲了一个&amp;quot;在巨头内部做叛逆产品&amp;quot;的样本。他后来也是&amp;quot;Don&amp;rsquo;t be evil&amp;quot;这句话的提出者之一；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Caterina Fake（Flickr）&lt;/strong&gt;：Flickr 是从一个在线游戏项目（Game Neverending）里 pivot 出来的——游戏没成，游戏里的照片分享功能成了。又一个&amp;quot;内部工具/附属功能反杀主产品&amp;quot;的案例，和 Blogger 同构；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Mitchell Kapor（Lotus）&lt;/strong&gt;：Lotus 1-2-3 是 PC 时代第一个&amp;quot;killer app&amp;rdquo;，它的意义是证明了&amp;quot;软件本身可以是一门大生意&amp;quot;——在这之前大家默认卖硬件送软件；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Charles Geschke（Adobe）&lt;/strong&gt;：Adobe 的起点是 Xerox PARC 里不被看好的 PostScript 技术，两位创始人带着技术出走创业。又一个&amp;quot;巨头看不见新品类&amp;quot;的注脚，和 Apple/HP 的故事互为镜像；&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Blake Ross（Firefox）&lt;/strong&gt;：在 IE 一家独大、所有人都说浏览器战争结束了的年代，从 Mozilla 里精简出 Firefox 重新开打。讲的是&amp;quot;在巨头已&amp;rsquo;获胜&amp;rsquo;的市场里怎么找到破口&amp;quot;。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;读法建议：不必按顺序读。先挑你熟悉的公司的篇章，感受&amp;quot;已知的结局 + 未知的细节&amp;quot;之间的落差——这个落差就是这本书的信息量所在。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;九思考与感悟&#34;&gt;九、思考与感悟&lt;/h2&gt;
&lt;ol&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;一手材料的习惯值得迁移到所有学习里。&lt;/strong&gt; 这本书给我最大的方法论提醒：学任何领域，优先找一手材料——当事人访谈、原始论文、事故复盘原文、源码本身。二手解读帮你省时间，但也帮你过滤掉了真正有用的毛边。做技术选型时看官方 benchmark 是一手，看&amp;quot;十大框架对比&amp;quot;公众号文章是二手，两者的信息密度差着数量级。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;pivot 是能力，不是失败。&lt;/strong&gt; 32 个故事里一大半做过 pivot，而且 pivot 的形态高度一致：不是推倒重来，而是&amp;quot;原来积累的技术/用户/认知，换一个需求接着用&amp;quot;。PayPal 的加密技术变成了支付安全，Pyra 的内部工具变成了 Blogger。所以真正重要的不是&amp;quot;押对第一个想法&amp;quot;，而是保持&amp;quot;手上的东西能复用到下一个想法&amp;quot;的弹性——架构上如此，认知上也如此。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;&amp;ldquo;被拒绝&amp;quot;包含的信息量比&amp;quot;被接受&amp;quot;大。&lt;/strong&gt; HP 五次拒绝 Apple I，不是因为 HP 笨，而是因为组织框架装不下新品类。同理，投资人拒绝你，多数时候不是你的项目不行，而是你的项目不在他的认知框架里。这条对工程师找工作、推技术方案同样成立：被拒绝时先判断&amp;quot;对方框架里有没有我这个类别&amp;rdquo;，再决定是换受众还是换方案。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;增长机制要被设计进产品，而不是外包给市场部。&lt;/strong&gt; Hotmail 的签名档是最干净的示范：产品动作本身就是分发动作。今天做产品的工程师依然很少在设计阶段问&amp;quot;用户的使用行为里，哪一步天然会触达新用户&amp;quot;，但这个问题往往比&amp;quot;功能做得多完善&amp;quot;更决定生死。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;活下去是主线任务。&lt;/strong&gt; 缺钱、被拒绝、员工走光，这些在成功者的故事里不是插曲而是常态。差别在于有人账上的钱、心里的劲、手上的用户数据，三者中至少剩一个能撑到转机。Graham 后来总结的&amp;quot;default alive vs default dead&amp;quot;，源头就是这些访谈里一个个具体的生死时刻。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;别把幸存者模式当成功配方。&lt;/strong&gt; 这是读完 32 篇之后必须泼给自己的冷水：这本书里只有活下来的人。同样的 pivot、同样的死扛，放在失败者身上就叫&amp;quot;方向不清&amp;quot;和&amp;quot;沉没成本谬误&amp;quot;。这些模式真正的用法不是照抄，而是&lt;strong&gt;校准预期&lt;/strong&gt;——让你知道缺钱、被拒、走弯路是这条路的默认路况，而不是你走错了的信号。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;对工程师个人，这本书还有一层职业启示。&lt;/strong&gt; 这 32 个人里相当多数是技术出身（Wozniak、Levchin、Graham、Buchheit），但他们的胜负手几乎都不在技术上：Levchin 赢在两次压下技术偏爱，Graham 赢在手工服务商家，Bhatia 赢在一行签名档。技术在早期公司里是入场券，不是护城河——迭代速度、对用户的贴身理解、活下去的现金流纪律，才是。想明白这一点，对&amp;quot;工程师要不要懂产品、懂增长&amp;quot;这个问题就不会再有纠结了。&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;hr&gt;
&lt;h2 id=&#34;本篇小结&#34;&gt;本篇小结&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;这本书的方法论价值大于内容价值：32 份一手访谈证明，创业史的&amp;quot;源码和 issue 区&amp;quot;比二手报告的光滑叙事有用得多；读法是信细节、不信结论；&lt;/li&gt;
&lt;li&gt;反复出现的共性模式四条：从别的想法 pivot 而来、早期不被理解、缺钱是默认状态、先做产品后想商业模式——但要看具体纹理，不看鸡汤版本；&lt;/li&gt;
&lt;li&gt;五个案例各记一句话：PayPal 演示效果不等于市场需求；Apple 被巨头拒绝是结构性的不是个人的；Hotmail 把分发焊进产品动作；Viaweb 的早期经验后来成了 YC 的全部教条；Blogger 证明了&amp;quot;用户还在涨&amp;quot;可以是独自坚持的全部理由；&lt;/li&gt;
&lt;li&gt;例外同样重要：craigslist 用&amp;quot;慢公司&amp;quot;路径走通，说明模式是概率不是定律；&lt;/li&gt;
&lt;li&gt;书外的补充阅读路径：Graham 的散文集《Hackers &amp;amp; Painters》（Viaweb 经验的文章版）、Hotmail 案例在几乎所有增长黑客教材里的复盘，以及 YC 历年创始人访谈（Founders at Work 的精神续作）。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;如果要给这本书一个一句话评价：它不是教你&amp;quot;怎么创业成功&amp;quot;的书，而是教你&amp;quot;创业真实长什么样&amp;quot;的书。前者不存在，后者恰恰是行动前最需要的输入。&lt;/p&gt;
&lt;p&gt;补充一个适用人群的建议：如果你是纯工程师、没打算创业，这本书也不会浪费——把它当&amp;quot;产品决策案例库&amp;quot;读，每个案例都是一次完整的&amp;quot;需求判断 → 资源约束 → 取舍 → 验证&amp;quot;循环，这种判断力在选型、排期、推方案时天天用得上。&lt;/p&gt;
&lt;p&gt;这本书适合放在手边，每当觉得&amp;quot;现在太难了&amp;quot;的时候翻一篇——你会发现 32 个后来功成名就的人，当年全都难到过不下去。这不是安慰，是基线校准。&lt;/p&gt;
&lt;p&gt;最后说一个阅读之外的收获。读完这本书我顺手做了个实验：找了两篇讲同一家公司（比如 PayPal 早期史）的二手长文，和书里 Levchin 的访谈对照着读。结果很说明问题——二手长文里的 PayPal 是&amp;quot;几个天才看准了电子支付的未来&amp;quot;，访谈里的 PayPal 是&amp;quot;PalmPilot 没人用、欺诈团伙天天攻击、和 X.com 合并后内部天天吵架&amp;quot;。前者读起来爽，后者读完你真的会做事。&lt;/p&gt;
&lt;p&gt;这就是为什么我打算把&amp;quot;找一手材料&amp;quot;变成自己以后研究任何主题的第一步：不管是学一个行业、调研一个竞品，还是复盘一次失败，先找到那个真正在场的人说了什么，再决定信不信别人替他做的总结。这个习惯平移到工程上就是：看 issue 区而不只看文档、看原始日志而不只看监控大盘的结论、听当事人的复盘而不只看事故通报——成本更高，但每次都有超额回报。&lt;/p&gt;
</description>
    </item>
    
  </channel>
</rss>
