从 0 到 1 设计一个产品

去年有个朋友找我聊创业想法。他滔滔不绝讲了半小时各种功能，我打断他：“你说的这些都很酷，但用户到底为什么需要它？”

他愣住了。

这个问题看似简单，但我自己在第一次做产品时也回答不上来。那时候我以为做产品就是把脑子里想到功能都塞进去，结果做出一个没人用东西。后来才明白，从 0 到 1 的每一步，都是在验证一个假设。

需求发现：从痛点到解决方案

很多人做产品起点是”我有个好想法”。但更好起点应该是”我观察到一个问题”。

我现在习惯用一个小框架来验证需求：谁在什么场景下遇到了什么问题，他们现在是怎么解决，现有方案痛点在哪里。

举个例子。我之前注意到团队每次开周会都要花15分钟找投影仪连接线，或者调试各种兼容性问题。这不是什么大问题，但每周都要经历一次，很烦。后来我们换了无线投屏，这个问题就消失了。

需求的大小，取决于问题频率和痛感。高频高痛是刚需，低频低痛是伪需求。中间的那些，要看具体场景。

但不是所有需求都值得满足。有一次我花了两周时间研究一个功能，后来发现用户根本不在乎。他们嘴上说”这个功能挺好”，但实际行为数据显示没人用。从那以后，我对用户访谈保持警惕，人们说和做的往往不一致。

竞品分析正确姿势

刚入行时，我觉得竞品分析就是列一个表格，把功能点打勾打叉。后来发现这种分析没什么用。

我现在做竞品分析，更关注三个问题：

对手为什么这么做？他们可能在某些方面比你更了解用户，或者他们产品阶段和你不一样。

对手没做什么？有时候空白本身就是信息。可能是他们试过失败了，也可能是他们还没意识到这个机会。

我能做什么？不是所有功能都要跟进，关键是找到自己差异化点。

还有一个容易忽略视角：非竞品。有时候你竞争对手用其他方式解决同样问题人。比如打车软件竞争对手，早期出租车和地铁。

MVP 定义与验证

MVP 这个概念说烂了，但我见过太多人把它理解成”做个简陋版本扔出去看看”。

MVP 的关键是最小可行性。最小意味着用最少资源验证最核心假设，可行意味着它得真能用，能解决用户问题。

我通常会把产品要验证假设列出来，然后按重要性排序。第一个版本只验证最重要那一个。

比如你做一个效率工具，核心假设可能是”用户真有这个问题”而不是”用户愿意付费”。那第一个版本就应该免费，让尽可能多用户试用，看看他们会不会用。如果没人用，后面的假设都不用验证了。

验证假设方式也不做产品。有时候一个落地页、一段视频、甚至一次人工服务，都能以更低成本验证你想法。

原型设计：低保真 vs 高保真

早期我追求高保真原型，觉得细节越多越好。结果花了大把时间调整像素，却在评审时质疑产品逻辑。

后来我学乖了。低保真原型用于验证结构和流程，高保真原型用于验证视觉和细节。在逻辑没跑通之前，不要纠结颜色和圆角。

我现在习惯用纸笔画第一版草图。很丑，但很快。画完之后自己走一遍流程，很多逻辑漏洞就暴露出来了。有时候走到一半发现走不下去，那说明这个设计本身有问题。

数据埋点与迭代

埋点这事容易忽视，但它决定了你迭代方向。

我第一次做埋点时，只是把所有能埋都埋了。结果数据太多，反而不知道看什么。后来才明白，埋点要围绕核心指标来设计。

核心指标通常是一个。比如内容产品可能是阅读时长，电商可能是转化率，工具可能是活跃天数。其他指标都是围绕这个核心指标服务。

迭代不是功能堆叠。每次迭代都应该回答一个问题：这个改动能提升核心指标吗？如果不确定，就先做个小范围测试。

踩过的坑和学到教训

做了几次产品，踩过的坑比做成产品还多。

第一个坑是把自己当用户。我觉得好，用户不觉得好。后来我学会了区分”我喜欢”和”用户需要”。

第二个坑是追求完美。第一个版本就想把所有功能都做好，结果拖了半年还没上线。现在我接受不完美，先上线再迭代。

第三个坑是忽视冷启动。产品做出来了，但没人来用。后来明白，产品上线只是开始，运营和推广要同步规划。

最大的教训是：做产品是在不确定性中寻找确定性。你永远不知道用户会怎么用你产品，但你可以通过验证一步步降低这种不确定性。

有时候验证结果是”这个想法不行”。这不可怕，早点失败总比浪费几个月时间好。

写到这我想起一个问题：如果让我重来一次，我会怎么做？

大概还是会踩坑，只是可能踩得快一点，爬起来也快一点。