返回博客

我做了204个在线工具,然后学会了做产品

从"写个工具"到"做个产品",中间差了204个工具。

我的工具站上有 204 个工具。这个数字不是计划出来的,是"做多了"的结果。

有人问我:你做这么多工具干嘛?用户用得过来吗?我一开始也回答不了这个问题。但做完第 204 个之后回头看,我发现一个有意思的事实:这 204 个工具,每一个都是一次小实验。而真正教会我做产品的,不是某个成功的工具,是所有失败的加在一起。

第一个工具:典型的"工程师思维"

我做的第一个工具是一个 JSON 格式化工具。当时的心态很简单:我需要一个 JSON 格式化工具,现有的那些要么广告太多,要么界面太丑,要么每次都要加载一堆没用的东西。我觉得"我做一个,肯定比它们好"。

花了两个小时写完,上线。功能齐全:支持格式化、压缩、验证、树形展示、一键复制。我觉得自己做得不错。

然后呢?没什么然后。访问量寥寥无几。偶尔有人用,也是用完就走,没人收藏,没人分享。

我当时很不理解:明明功能更全、界面更干净,为什么没人用?后来我才明白——用户不需要一个"更好的 JSON 格式化工具",用户只需要一个"刚好够用的 JSON 格式化工具"。我在"更好"上花了太多精力,但用户对"更好"是无感的。他们只关心一件事:能不能用最少的操作完成我的任务。

第 50 个到第 100 个:从"我能做什么"到"用户需要什么"

前 50 个工具,我做的基本上都是"我能想到的工具"。Base64 编解码、URL 编解码、图片压缩、颜色转换……每一个都是我觉得"应该有人需要"的东西。

但到了第 50 个左右,我开始注意到一个现象:有些工具——比如一个简单的文本去重工具——访问量比那些"功能更强大"的工具高得多。我百思不得其解,直到有一天我自己需要去重一份几百行的列表,打开了 Google 搜索,发现排在前面的工具要么要登录,要么有使用次数限制,要么界面上铺满了广告。我突然意识到:用户不是来找"功能"的,用户是来找"解决方案"的。而大多数工具提供的是"功能",不是"解决方案"。

这个认知改变了一切。从第 50 个工具开始,我不再问"我能做什么",而是问"用户现在在忍受什么"。我开始观察自己的日常工作流程:哪些重复性操作让我烦躁?哪些时刻我打开了一个工具,然后因为体验太差而关掉了?

第 60 个工具是一个时间戳转换器。这个工具的本质极其简单——就是把时间戳转成可读的日期,或者反过来。但它上线后,访问量是我之前所有工具总和的五倍。为什么?因为我理解了用户的使用场景:开发者看日志的时候,经常遇到时间戳,需要快速知道"这是什么时候"。工具需要做的不是"提供一个转换功能",而是"让这个转换快到你不需要思考"。

关键转折点:工具和产品的区别

大概在第 120 个工具的时候,我开始意识到一个根本区别:

工具是你"能"用的东西。产品是你"想"用的东西。

一个好的工具,功能正确、没有 bug。一个好的产品,除了功能正确,还有三样东西:默认值、容错、反馈

举个例子:我做过一个图片压缩工具。第一版上线时,用户需要先选择压缩质量,然后点击"压缩",再等几秒钟。技术上没问题,功能正确。但数据告诉我,很多用户在选择质量这一步就放弃了。为什么?因为选择质量是一个"决策成本"——用户不想研究"80% 和 90% 的区别是什么",他们只想"图片变小一点"。

后来我改成了:默认质量 80%,拖入图片自动开始压缩,压缩完成后自动显示原图对比。没有"压缩按钮",没有"质量选择器"。就这一版改动,使用率提升了三倍。

这就是工具和产品的区别:工具把选择权交给用户,产品帮用户做选择。

第 204 个工具:我学会了什么

第 204 个工具做的是一个 SQL 格式化工具。和第一个工具(JSON 格式化)很像,但整个设计思路完全不同:

这些细节,每一个背后都有一个失败的工具作为教训。自动检测方言,是因为之前做过一个"需要手动选择格式"的编码转换工具,结果 70% 的用户在第一步就流失了。错误信息改写,是因为我看了数据,发现很多用户第一次使用时会粘贴错误的内容,然后被技术错误劝退。

写在最后

做完 204 个工具,我最大的收获不是"怎么做一个好工具",而是怎么理解用户。每一个工具都是一次和用户对话的机会——你上线一个功能,用户用数据告诉你"我不在乎这个";你改掉一个细节,用户用留存告诉你"这个对了"。

如果你正在做自己的产品,我的建议是:不要想"做一个完美的产品",先做 10 个"半成品"。每一个半成品都会告诉你一些你不知道的事情——关于用户,关于你自己,关于什么才是真正重要的。

204 个工具教会我的,不是技术,是对用户的敬畏