一个保温杯和一块没人要的电池先讲两个真实的小故事。第一个有人花了整整三年研制一种新型电池材料项目结题、论文发表志得意满地拿着成果去找工厂谈量产。工程师看了一眼就摇头——这材料用不了密度太低做出来的电池块头太大装不进任何一款产品。三年心血卡在了一句话上。事后他感叹早知如此当初就不会一头扎进去。问题出在哪不是技术不够硬而是当初对需求的研究不够透。第二个成都一位科技园的孵化器负责人办公室里珍藏着一只用了十几年的保温杯那是他孵化的第一家公司开业时收到的礼物。他说科技创新的全过程里成果转化是公认的最后一公里。前面九十九步都走对了最后这一公里走不通前面就全白费。这两个故事指向同一件事很多技术不是死在实验室里而是死在做完了才发现没人要的那一刻。而避免它的方法恰恰要从动手之前开始——以终为始。二、最后一公里到底卡在哪我们习惯把技术落地难归咎于转化机制不完善“缺钱缺人”,这些都对,但都不是根。看一组数据。国家知识产权局公布,2024 年我国企业发明专利产业化率为53.3%——这已经是逐年改善后的水平,但仍意味着近一半的专利躺在纸面上。高校口径更严峻:学者论文数量、专利申请量常年居世界前列,但高校科技成果转化率整体偏低,业内反复用不好转最后一公里来形容这种结构性梗阻。即便是 2024 年全国 4059 家高校院所合计 2269.1 亿元、66.1 万项的转化合同(同比增长约 10%),拉开看,大量成果从立项那天起就没瞄准过一个真实的产业出口。为什么会这样?因为很多项目的起点是我手里有什么技术、能发什么论文,而不是产业最终需要解决什么问题。起点错了,跑得越快、做得越精,离落地反而越远。一句产品圈的老话说得扎心:“如果你在错误的方向上奔跑,跑得越快,偏离得越远。”上图把两条路径并排放在一起。上面一条是顺推:从手里的技术出发,做出产品,再回头找场景——结果常常撞在没人需要的墙上。下面一条是逆推:先把最终价值/用户痛点钉死,再倒推关键问题、技术路径,最后水到渠成地落地。同样是四步,起点不同,结局天差地别。三、42% 的失败,败在动手之前如果说科技成果转化是宏观层面的最后一公里,那么微观的产品研发里,同样的病更普遍、更致命。创投数据库 CB Insights 对失败创业公司做过经典复盘,排在第一位的死因是没有市场需求(No Market Need),占比高达42%——明显高于资金耗尽(29%)和团队不行(23%)。换句话说,最大的浪费不是钱花光了,而是方向从一开始就错了:做出来的东西,根本没人需要。CB Insights 援引的一个案例特别典型。一家叫 Patient Communicator 的公司做了套帮诊所提效的系统,创始人复盘时说:“我后来意识到,我们其实没有客户——因为没人对我们做的东西感兴趣。医生需要的是更多病人,而不是一个效率更高的办公室。”技术团队对这种剧情应该不陌生:需求文档写了三版,原型迭代十二次,评审会开了八次,功能上线三个月,DAU 只涨了 0.x%。代码没写错,设计也不丑,错的是一开始没问清楚这事到底为谁解决什么痛点。这就引出以终为始的第一性原理:在动手之前,先把最终要交付什么价值、必须回答哪些关键问题想清楚。它不是流程上的繁文缛节,而是过滤伪需求的第一道闸门。四、亚马逊的答案:先写新闻稿,再写代码把以终为始做成可复制工程纪律的,是亚马逊的逆向工作法(Working Backwards)。它的规矩近乎反直觉:严禁先写代码后找市场。任何新项目启动前,团队必须先写两样东西——PR(新闻稿):假装产品已经发布,以用户视角写一篇上市新闻稿,讲清楚它为用户解决了什么、用户为什么会兴奋。FAQ(常见问题):把客户、高管、工程师可能问的尖锐问题提前列出来并作答,包括成本、技术可行性、风险。这两份文档要反复打磨——据亚马逊内部实践,一份 PR/FAQ 通常要修改 10 次以上、与高层开会 5 次以上,才能进入开发。Kindle、Prime、AWS 这些产品,都是从一页新闻稿倒推出来的。为什么有效?因为它用一页纸的成本,替代了一个原型的成本,在写第一行代码之前就把逻辑漏洞暴露出来。当你被迫用用户语言写出这个产品最终长什么样、好在哪,那些技术上很酷但用户无感的功能会自动现形;那些真正的核心价值,也会浮出水面。这正是逆推思维的精髓:从结果倒推路径,而不是从能力顺推结果。配套的还有两条:两个披萨团队(团队小到两张披萨能喂饱,6-10 人,自治权高,减少内耗)和高频用户反馈机制。但灵魂始终是那一句——先想清最终价值,再决定怎么做。五、落地:把以终为始拆成三个动作道理不难,难在它要对抗工程师先干起来再说的本能。给三个可立即上手的动作。动作一:写一页伪新闻稿。项目立项时,别先写技术方案,先用大白话写一段:半年后这个项目上线,用户/客户会怎么描述它带来的改变?写不顺,通常说明价值还没想清。这一步几乎零成本,却能拦掉大半伪需求。动作二:列出关键问题清单。把这件事成立的前提是什么、最可能错在哪、用户真会为它买单吗逐条写下来,逐个找证据验证。研发效能专家何勉提出过三个不等式特别值得贴在墙上:局部效率 ≠ 高效交付,高效交付 ≠ 持续高效,高效交付 ≠ 业务成功。你团队再忙、代码写得再快,只要没解决用户的真问题,交付得再多也等于零。动作三:用四象限给需求排序。把所有待做事项按发生频次 × 痛苦程度扔进四个格子,先做高频高痛的核心价值,坚决不在低频低痛的伪需求区空耗。这三个动作的共同点是:它们都发生在写代码之前,且都在逼你回答同一个问题——最终价值是什么。把这个问题前置,后面的架构、选型、排期才有了校准的北极星。否则,你只是在为一个不确定的终点疲于奔命。结语:能解决真问题的技术,才有生命力回到开头那块没人要的电池。它的失败不在材料学,而在路径学——从能做什么出发,而不是从该解决什么出发。技术的浪漫在于能造出来,但技术的价值只在被需要那一刻才真正兑现。无论是科技成果卡在最后一公里,还是 42% 的产品死于没有市场需求,根子都是一个:起点没有锚定终点。以终为始,不是放慢脚步,而是确保你迈出的每一步,都朝着一个值得抵达的地方。如果只带走一句话,那就是:先想清要去哪,再决定怎么走——能落地、能解决真实痛点的技术,才有生命力。
以终为始：从最终价值倒推技术路径
一个保温杯和一块没人要的电池先讲两个真实的小故事。第一个有人花了整整三年研制一种新型电池材料项目结题、论文发表志得意满地拿着成果去找工厂谈量产。工程师看了一眼就摇头——这材料用不了密度太低做出来的电池块头太大装不进任何一款产品。三年心血卡在了一句话上。事后他感叹早知如此当初就不会一头扎进去。问题出在哪不是技术不够硬而是当初对需求的研究不够透。第二个成都一位科技园的孵化器负责人办公室里珍藏着一只用了十几年的保温杯那是他孵化的第一家公司开业时收到的礼物。他说科技创新的全过程里成果转化是公认的最后一公里。前面九十九步都走对了最后这一公里走不通前面就全白费。这两个故事指向同一件事很多技术不是死在实验室里而是死在做完了才发现没人要的那一刻。而避免它的方法恰恰要从动手之前开始——以终为始。二、最后一公里到底卡在哪我们习惯把技术落地难归咎于转化机制不完善“缺钱缺人”,这些都对,但都不是根。看一组数据。国家知识产权局公布,2024 年我国企业发明专利产业化率为53.3%——这已经是逐年改善后的水平,但仍意味着近一半的专利躺在纸面上。高校口径更严峻:学者论文数量、专利申请量常年居世界前列,但高校科技成果转化率整体偏低,业内反复用不好转最后一公里来形容这种结构性梗阻。即便是 2024 年全国 4059 家高校院所合计 2269.1 亿元、66.1 万项的转化合同(同比增长约 10%),拉开看,大量成果从立项那天起就没瞄准过一个真实的产业出口。为什么会这样?因为很多项目的起点是我手里有什么技术、能发什么论文,而不是产业最终需要解决什么问题。起点错了,跑得越快、做得越精,离落地反而越远。一句产品圈的老话说得扎心:“如果你在错误的方向上奔跑,跑得越快,偏离得越远。”上图把两条路径并排放在一起。上面一条是顺推:从手里的技术出发,做出产品,再回头找场景——结果常常撞在没人需要的墙上。下面一条是逆推:先把最终价值/用户痛点钉死,再倒推关键问题、技术路径,最后水到渠成地落地。同样是四步,起点不同,结局天差地别。三、42% 的失败,败在动手之前如果说科技成果转化是宏观层面的最后一公里,那么微观的产品研发里,同样的病更普遍、更致命。创投数据库 CB Insights 对失败创业公司做过经典复盘,排在第一位的死因是没有市场需求(No Market Need),占比高达42%——明显高于资金耗尽(29%)和团队不行(23%)。换句话说,最大的浪费不是钱花光了,而是方向从一开始就错了:做出来的东西,根本没人需要。CB Insights 援引的一个案例特别典型。一家叫 Patient Communicator 的公司做了套帮诊所提效的系统,创始人复盘时说:“我后来意识到,我们其实没有客户——因为没人对我们做的东西感兴趣。医生需要的是更多病人,而不是一个效率更高的办公室。”技术团队对这种剧情应该不陌生:需求文档写了三版,原型迭代十二次,评审会开了八次,功能上线三个月,DAU 只涨了 0.x%。代码没写错,设计也不丑,错的是一开始没问清楚这事到底为谁解决什么痛点。这就引出以终为始的第一性原理:在动手之前,先把最终要交付什么价值、必须回答哪些关键问题想清楚。它不是流程上的繁文缛节,而是过滤伪需求的第一道闸门。四、亚马逊的答案:先写新闻稿,再写代码把以终为始做成可复制工程纪律的,是亚马逊的逆向工作法(Working Backwards)。它的规矩近乎反直觉:严禁先写代码后找市场。任何新项目启动前,团队必须先写两样东西——PR(新闻稿):假装产品已经发布,以用户视角写一篇上市新闻稿,讲清楚它为用户解决了什么、用户为什么会兴奋。FAQ(常见问题):把客户、高管、工程师可能问的尖锐问题提前列出来并作答,包括成本、技术可行性、风险。这两份文档要反复打磨——据亚马逊内部实践,一份 PR/FAQ 通常要修改 10 次以上、与高层开会 5 次以上,才能进入开发。Kindle、Prime、AWS 这些产品,都是从一页新闻稿倒推出来的。为什么有效?因为它用一页纸的成本,替代了一个原型的成本,在写第一行代码之前就把逻辑漏洞暴露出来。当你被迫用用户语言写出这个产品最终长什么样、好在哪,那些技术上很酷但用户无感的功能会自动现形;那些真正的核心价值,也会浮出水面。这正是逆推思维的精髓:从结果倒推路径,而不是从能力顺推结果。配套的还有两条:两个披萨团队(团队小到两张披萨能喂饱,6-10 人,自治权高,减少内耗)和高频用户反馈机制。但灵魂始终是那一句——先想清最终价值,再决定怎么做。五、落地:把以终为始拆成三个动作道理不难,难在它要对抗工程师先干起来再说的本能。给三个可立即上手的动作。动作一:写一页伪新闻稿。项目立项时,别先写技术方案,先用大白话写一段:半年后这个项目上线,用户/客户会怎么描述它带来的改变?写不顺,通常说明价值还没想清。这一步几乎零成本,却能拦掉大半伪需求。动作二:列出关键问题清单。把这件事成立的前提是什么、最可能错在哪、用户真会为它买单吗逐条写下来,逐个找证据验证。研发效能专家何勉提出过三个不等式特别值得贴在墙上:局部效率 ≠ 高效交付,高效交付 ≠ 持续高效,高效交付 ≠ 业务成功。你团队再忙、代码写得再快,只要没解决用户的真问题,交付得再多也等于零。动作三:用四象限给需求排序。把所有待做事项按发生频次 × 痛苦程度扔进四个格子,先做高频高痛的核心价值,坚决不在低频低痛的伪需求区空耗。这三个动作的共同点是:它们都发生在写代码之前,且都在逼你回答同一个问题——最终价值是什么。把这个问题前置,后面的架构、选型、排期才有了校准的北极星。否则,你只是在为一个不确定的终点疲于奔命。结语:能解决真问题的技术,才有生命力回到开头那块没人要的电池。它的失败不在材料学,而在路径学——从能做什么出发,而不是从该解决什么出发。技术的浪漫在于能造出来,但技术的价值只在被需要那一刻才真正兑现。无论是科技成果卡在最后一公里,还是 42% 的产品死于没有市场需求,根子都是一个:起点没有锚定终点。以终为始,不是放慢脚步,而是确保你迈出的每一步,都朝着一个值得抵达的地方。如果只带走一句话,那就是:先想清要去哪,再决定怎么走——能落地、能解决真实痛点的技术,才有生命力。
