我们如何解读第一波反馈

当一个工作室网站上线后，就会开始收到一类特殊的电子邮件。这些并非关于特定应用的错误报告——这类报告有专门的渠道——而是更宏观、更笼统的反馈。. 我喜欢能做 X 的应用程序，你们考虑过 Y 吗？您的定价太低/太高/不明确。 所有这些都是天赋。大部分都不能成为产品。

最后那句话听起来比我们本意要严厉些。问题并不在于这些建议的质量——其中很多都很不错。而是小型工作室一次只能开发少数几个项目，而每次说“好”就意味着对其他项目说“不”。因此，真正的工作在于决定哪几项创意值得占据这些资源。.

我们怎么做

阅读。标记。分类。建议会汇总到一份共享文档中，我们每季度末（而不是每周）重新阅读一次——只有当积累到足够多的内容，能够看出趋势时，那些重要的规律才会显现出来。.

标签很简单：涉及哪款应用（如果没有，则标注“studio”），请求的类型，以及用我们自己的话写的一行概括。这句概括很重要。 将我们认为用户真正的需求写下来，而不是他们提出的解决方案，往往能从中获得有价值的洞察。例如，有人在婚礼策划应用中请求导出日历功能，这其实可能是在告诉我们，他们需要与不使用该应用的人共享策划内容。.

我们会回复每一位用户，哪怕回复很简短。一句简短的感谢加上诚恳的说明——“我们已经将此列入计划”，或者“我们可能不会开发这个功能，原因如下”——总比保持沉默要好，也比做出无法兑现的承诺要好。.

我们不做的事

立即构建用户需求最多的功能。用户需求最多的功能几乎总是用户最了解的需求，而不是最能改进产品的功能。更深层次的改进通常来自第二封或第三封邮件，这封邮件说 这样做是可行的，但感觉不对，因为......

这些邮件更难据此采取行动，因为它们很少附带具体的解决方案。有人告诉我们某个界面看起来杂乱无章，或者说他们不再使用某项功能，却说不清具体原因。单看每一条反馈，内容都比较模糊。但当多条反馈指向应用的同一个角落时，这些反馈往往就是该文件夹中最有价值的内容。.

此外，我们也不会将开发新应用的请求视为待办事项清单。关于全新产品的构想会像其他所有项目一样，每季度接受一次评估，而其中大多数最终仍停留在构想阶段。最终得以推进的项目都符合我们的工作方式：一款功能专注、本身就很有用、而且是我们自己也想使用的工具。.

我们的失误

在最初的几周里，我们的本能是随反馈一到就立即回应——这里快速修复一下，那里稍作调整。这让人感觉我们很用心。但这也意味着，每周最引人注目的那封邮件决定了我们的优先级，而一些仓促做出的改动最终不得不悄悄撤回。 等待季度报告的发布虽然节奏较慢，有时甚至令人沮丧，但能带来更明智的决策。.

一个月过去了，我们已经有了一个文件夹。整个夏天，我们都会在这些文件夹里工作。