用演示验证预期工作方式

有些产品实现成本较高，完整开发以前仍可以呈现预期流程。可使用：

• 一段短视频；
• 可点击的页面原型；
• 一份输入和输出样例；
• 由人操作、对外看起来连贯的演示；
• 只实现最难步骤的技术 Demo。

原型适合验证用户能否理解工作方式，MVP 则需要让用户对关键结果作出真实反应。两者用途不同。^[1]

Dropbox 的早期案例常被概括为「先做视频再开发」。更准确的说法是，演示视频先呈现预期同步流程，并收集注册、留言和邮箱，帮助团队判断是否继续投入。^[1] 它不能证明产品当时完全没有代码，也不能保证任何复杂产品拍一段视频就能获得同样结果。

演示应明确标注哪些部分已经运行、哪些是模拟。用户看懂以后，可以继续询问：

• 这个流程是否对应最近发生的任务；
• 哪一步与当前做法不同；
• 用户需要提供哪些数据和权限；
• 输出交给谁，怎样验收；
• 什么时候愿意开始使用；
• 是否愿意提交真实样本或进入付费试做。

仅仅说「看起来很酷」仍然是弱信号。愿意拿出真实文件、安排下一位协作者参加、提供系统约束，通常更接近实际采用。

用手工服务先确认结果

当用户需要的结果已经清楚，产品形态仍不确定时，可以先人工交付。目标是学习用户的输入、判断规则、质量标准和付款条件。

一项 Lead Generation 服务可以先承诺交付一小批符合条件的线索。团队人工寻找、清洗和核对，客户说明哪些线索合格。重复交付以后，再把稳定步骤做成软件。^[2]

这个过程需要记录：

1. 客户怎样描述目标对象；
2. 开始前必须提供什么资料；
3. 哪些判断可以按规则完成；
4. 哪些步骤依赖人工经验；
5. 客户怎样验收结果；
6. 一次交付花费多少时间和费用；
7. 哪些异常让任务无法继续；
8. 客户是否愿意再次购买。

Newsletter 广告线索案例也说明了这一点。客户需要的是已经在同类 Newsletter 投过广告的品牌，数量庞大的通用联系人没有直接帮助。服务先帮助客户寻找这类赞助商，再把数据采集和补全做成可登录产品。^[2] 产品价值来自缩短销售搜索过程，界面只是交付方式的一部分。

另一项社交聆听项目在产品形态尚未确定时，先把整理后的数据和分析报告发送给一小批企业用户。交付过程帮助团队理解用户真正需要的指标和格式，无需先投入登录、前端和复杂交互。^[2]

手工服务还可以暴露软件化条件。若每个客户都要求完全不同的研究、判断和关系协调，业务可能更接近顾问服务。若输入、步骤和输出逐渐稳定，才适合继续自动化。

免费试做需要范围和交换条件

有些早期客户不愿在第一天预付。可以提供一次免费样例或短期试做，但要提前写清：

• 只服务哪一项任务；
• 最多处理多少资料；
• 从哪天开始，到哪天结束；
• 用户需要提供什么输入；
• 交付以后必须安排一次验收；
• 哪些使用和质量信息可以被记录；
• 试做结束后的价格和下一步。

免费不能成为无期限承诺。没有结束条件时，用户可能只是在接受免费劳动，团队也无法观察付款选择。

试做中的交换不一定是公开推荐。更实际的交换包括真实资料、按时反馈、允许观察流程、说明验收标准，以及在试做结束时明确决定继续或停止。

免费用户的反馈仍要保留证据层级。对方愿意投入时间和业务资料，比只留下邮箱更强；对方愿意在服务停止后付款，才进入交易证据。

预付要建立在可以兑现的范围上

预付是一项很强的早期信号，因为用户需要作出真实预算选择。它也给交付方带来责任。

收款前至少应写清：

• 购买的是产品、试点还是定制服务；
• 具体交付物和数量；
• 需要客户提供的资料；
• 预计开始和完成时间；
• 价格、币种、税费和支付方式；
• 修改次数和验收方式；
• 无法交付时的退款安排；
• 哪些功能仍未实现；
• 数据、知识产权和保密怎样处理。

不同地区对预售、自动续费、退款、数字服务和消费者告知的要求不同。本文只能提供研究结构，实际条款需要按销售地区、主体和客户类型核对，必要时咨询专业人士。

预付金额不一定很高。一个浏览器自动化项目曾先询问具体任务和预算，再用范围较小的定制任务获得一笔约一百美元预付。^[2] 这笔交易说明有人愿意为明确结果承担成本，不能据此规定所有产品的定金金额。

接受预付后，团队必须交付或按约退款。夸大完成度、隐瞒关键限制、长期推迟和收取超出能力的订单，会让验证失去意义，也会造成法律和信誉风险。

可运行的最小产品要完成一项任务

有些产品的关键未知只有在真实使用中才会出现。这时需要一个可以运行的最小流程。

最小产品可以缺少批量处理、多语言、模型选择、精美设计和自动化支持，仍要让目标用户完成一项清楚的任务。页面能打开只说明入口可用；用户还要获得结果，并愿意继续行动。

AI Manga Translator 的 1.0 一次只能翻译一张图片，没有后来增加的批量、字体和多语言能力。产品在技术和社区渠道公开以后，第三天出现一笔二十美元订阅。^[3] 这项付款来自该项目记录，只能说明一名陌生用户愿意为方向付费，不能证明完整市场已经成立。

案例还说明，MVP 的范围要围绕主要结果。对漫画翻译来说，大量设置不是重点，图片经过识别和翻译后，译文能够回到接近原来的版式才是关键。^[3] 如果最难的交付没有发生，即使页面和账户系统都完整，也很难验证需求。

上线以后要继续记录失败：哪些图片无法处理，语言质量怎样，用户为什么请求新功能，付款后有没有继续使用。首笔交易是下一轮研究的开始。

开源产品也需要一个承接页面

开源项目的 README 往往同时承担说明、演示和行动入口。它可以包含一句话介绍、适用场景、主要差异、功能证据、Quick Start 和明确 CTA。^[4]

不同项目需要的证据不同。前端产品适合展示 GIF 和交互，开发框架更需要维护状态、接口、性能或最佳实践。README 不应照抄某个热门项目的固定结构，重点是让目标用户快速判断是否值得试用。

Star 和 Fork 可以说明开发者注意到项目，仍然不能代替安装、部署、持续使用和商业转化。发布后要一对一识别早期用户，了解他们是否完成 Quick Start、在哪一步失败、是否愿意加入社区或使用付费能力。^[4]

公开文章和文档也能帮助媒体、社区和用户准确理解项目。它们属于验证和分发材料，需要与真实产品状态一致，不能用未来规划冒充现有功能。