老周的产品上线那天，他给自己定了一个很朴素的目标：先别急着证明“有多少人用”，而是先证明“有没有人愿意为它付钱”。他做的是一款面向小型团队的协作工具，功能不算复杂，但打磨了将近四个月。上线前他把定价表改了七版，最后定下来的结构是：免费版、每月 99 元的专业版、每月 299 元的团队版。这个价格表看起来平淡无奇，真正有意思的是他接下来做的事——他没有立刻去推广，而是先邀请了 7 个在早期内测时就表现出强烈兴趣的用户，问他们一个问题：如果这个工具要收费，你会选哪个版本，为什么。

定价表不是拍脑袋定的，是拿约束条件推出来的

老周一开始并没有直接参考市面上同类工具的定价。他先列了自己的三个约束条件：第一，这是一人 SaaS，没有销售团队，所以价格必须低到用户不需要“内部审批”就能自己做决定；第二，他不想做按席位收费，因为一人公司没有精力去处理“加一个席位要发账单”的琐碎事务；第三，他需要一条清晰的升级路径，让用户能直观地理解“为什么要多付 200 块”。

这三个条件直接排除了很多常见做法。按席位收费在早期看似灵活，但对单人运营者来说，每一个计费维度都意味着多一套解释成本和账单处理逻辑。老周最终选择了按“功能边界”来切分：免费版解决“个人试用和轻量使用”，99 元的专业版解决“认真用这个工具完成工作”，299 元的团队版则面向“需要多人协作和更高配额的小团队”。

免费版的功能被刻意做得“能用但不够用”。老周没有把免费版砍成一个残缺的演示品，而是保留了完整的核心流程，让用户能真实跑通一个项目，但在存储空间、协作成员数、高级自动化动作上设置了明确上限。这样做的逻辑很直接：他希望用户是因为“用到了上限”而升级，而不是因为“功能被锁”而流失。

7 个用户的付费验证：问的不是“你愿意付多少”，而是“你会选哪一档”

老周很清楚，一个定价表在没有真实付费行为之前，只是一组数字。他不想做问卷调查，因为问卷里用户往往会给出“看起来很合理”的答案，而不是真实掏钱时的选择。所以他换了一种方式：给那 7 个内测用户发了一封邮件，附上完整的定价说明，然后问他们——如果现在必须选择其中一个版本开始付费使用，你会选哪个？

这个问题的巧妙之处在于，它把“要不要付费”的模糊问题，变成了“选哪一档”的明确决策。用户不再思考“这个工具值不值”，而是被迫在三个选项里做比较。老周得到的答案分布很有意思：4 个人选了 99 元的专业版，2 个人选了免费版，1 个人直接选了 299 元的团队版。

选免费版的 2 个人给出的理由几乎一致：他们目前的使用强度很低，免费版的上限足够覆盖日常需求。选 99 元的 4 个人则提到，他们需要的是高级自动化和更大的存储空间，这些功能直接关系到他们的工作效率。而选 299 元的那位用户，理由让老周印象最深——他说自己团队有 5 个人在用，免费版和专业版的限制都太紧了，团队版虽然贵，但算下来比用别的工具组合便宜。

这个结果没有直接告诉老周“应该定多少钱”，但它验证了一件事：三个层级之间的功能边界，确实对应着三种不同的使用场景和支付意愿。免费版不是用来“养用户”的，而是用来筛选“真正需要这个工具的人”；99 元是主力付费档；299 元则承接了那些已经把工具当成团队基础设施的用户。

功能边界是定价的灵魂，价格数字只是结果

复盘这个案例时，最值得注意的不是 99 和 299 这两个数字本身，而是老周如何定义每一档的“边界”。免费版的存储上限是 2GB，专业版是 50GB，团队版是 200GB；免费版只能创建 1 个自动化流程，专业版是 10 个，团队版不限量；协作成员数从免费版的 1 人、专业版的 3 人，到团队版的 15 人。

这些数字不是拍脑袋定的，而是老周观察内测用户的真实使用数据后划出来的。他发现，大多数个人用户在单个项目上的数据量很少超过 2GB，而一旦开始把工具用于正式工作，数据量会迅速增长到 10GB 以上。自动化流程的使用频率也有类似的分层：轻度用户一个月用不了几次，重度用户几乎每天都要配置新流程。

这种“按真实使用强度划分边界”的做法，让每个层级的付费理由都变得具体可感。用户不会觉得“我在为某个虚无缥缈的高级功能付费”，而是清楚地知道，自己升级是因为存储不够了、协作人数不够了、自动化流程不够用了。这种付费逻辑比“专业版功能更多”这种模糊表述要扎实得多。

验证结果的真正价值：不是确认价格，而是确认用户分层

老周后来把 7 个用户的反馈整理成了一份简单的表格，他发现了一个比“哪档卖得最好”更有价值的结论：用户选择哪个版本，几乎完全取决于他们的团队规模和工具使用深度，而不是他们的支付能力。选免费版的人不是付不起 99 元，而是他们的需求确实停留在免费版能覆盖的范围；选 299 元的人也不是特别有钱，而是他们的使用场景确实需要那么大的配额。

这个发现让老周对产品的后续迭代有了更清晰的方向。他不再纠结于“要不要降价”或者“要不要加更多免费功能”，而是把精力放在优化专业版的核心体验上——因为那是用户最集中的一档，也是从免费版升级上来的第一站。团队版则被他定位成“服务少数但更稳定的客户”，他不需要很多团队版用户，只要有几个持续付费的，就能支撑起稳定的收入。

别把别人的价格表当成自己的答案

老周这个案例最容易被误读的地方，就是把 99 元和 299 元当成“独立开发者的标准定价”。事实上，这两个数字之所以成立，是因为它们恰好匹配了老周自己产品的功能边界、他目标用户的支付习惯，以及他单人运营的成本结构。换一个产品、换一批用户、换一种成本结构，同样的价格可能完全不适用。

对准备设计套餐的独立开发者来说，值得借鉴的不是老周的具体价格，而是他的验证方法：先定义清楚每一档的功能边界，再让真实用户做“选哪一档”的决策，最后根据选择结果反推定价是否合理。价格表不是静态的，它应该随着用户反馈和使用数据不断调整。老周在验证后也做了微调——他没有改价格，但把免费版的存储上限从 2GB 降到了 1.5GB，因为他发现 2GB 对免费用户来说太宽裕了，导致一部分轻度用户迟迟没有升级动力。

这 7 个用户的验证结果只代表老周产品的早期状态，不代表任何市场规律。但它提供了一个有价值的思考框架：定价不是拍脑袋定一个数字，而是通过功能边界设计，让不同需求的用户自己找到对应的付费层级。当用户能清楚地说出“我为什么选这一档”的时候，你的定价表才算真正经过了验证。