我职业生涯早期犯过的一个大错误，是相信软件产品本质上是功能的集合。这个应用有认证系统，那个应用有仪表盘，这个加了AI，那个支持协作。背后的假设很简单：更好的技术创造更好的软件。后来我逐渐意识到一个不太舒服的事实——大部分用户不关心技术，甚至不怎么关心功能，他们只关心能不能把事办成。
从那一刻起，我看软件的方式彻底变了。软件不再是功能的堆叠，而是工作流的集合。
没有人大清早醒来想的是“我需要一个笔记应用”。他们想的是“我需要记住点什么”。没人想要项目管理平台，他们想让项目往前推进。没人想要CRM系统，他们想要客户。没人想要AI助手，他们想要答案。软件只是载体，工作流才是目的地。
当软件团队在内部讨论产品时，对话常常是这个画风：加个仪表盘、加上AI、加通知功能、加集成、加报表。但用户很少以功能列表的方式体验软件，他们体验的是一连串动作。
拿笔记应用来说，产品团队可能用富文本编辑、标签、文件夹、搜索、同步这些词来描述它。而在用户那里，体验是“捕捉→整理→日后查找”这三个环节。工作流才是实质，功能只是支撑工作流存在的东西。
一旦我开始用工作流的视角看问题，另一个结论就变得很清晰：很多产品在功能上竞争，而最好的产品在“摩擦”上竞争。问题不再是我们还能加什么，而是我们能拿掉什么。每一次多余的点击、每一个额外的表单、每一块不必要的屏幕、每一次上下文切换、每一个手动步骤，这些都在不断累积。用户通常不会用“摩擦”这个词，他们说的是“这东西用着烦”“这东西好复杂”“这东西反应好慢”。他们其实在描述工作流债务。
一些产品看起来简单得出奇，背后就是这个道理。Instagram的成功不是靠塞进几百个功能，它的核心工作流是“拍摄→加滤镜→分享”。Uber不是因为地图技术才做起来的，真正运转它的是“叫车→乘车→付款”。GitHub也没有发明版本控制，但“推送→审查→合并”这套工作流让它站住了脚。技术当然重要，但最终留在用户记忆里的是工作流。
这个认知改变了我评估软件想法的方式。过去我找的是“有什么技术还没人做”，现在找的是“有什么工作流是断的”。当有人抱怨“我每次都得把这个东西从一个系统复制到另一个系统”，或者说“我老是跟丢这条信息”，或者“我每周都要花一小时做同样的事”，这些根本不是功能请求——它们指向的是一个个等待被打通的工作流缺口。
热门跟贴