半个月上架 App 之后，独立开发者先拉用户还是加功能？

上架之后，先观察用户怎样完成一次使用？

选一个产品准备服务的典型需求，让使用者从入口开始走到预期结果。对听力口语这类方向，可以先明确一次练习想帮助使用者完成什么，再记录实际操作中需要解释或中断的位置。这里建议的是观察方法，没有补写案例 App 的具体功能。

邀请能够说清使用目标的人体验，并允许他们按自己的理解操作。若开发者需要一直在旁指导，就把指导内容记下来，看看问题来自入口表达、操作步骤还是预期结果不清楚。先知道卡点在哪里，才方便决定修改什么。

讨论热度与真实使用，为什么要分别记录？

公开摘要里有人询问产品名称和开发工具，这可以帮助发现感兴趣的方向。整理反馈时，把想了解开发过程的人与准备使用产品的人分别看待，再继续确认各自关心什么。不能仅凭一条内容的互动，就计算产品的活跃、转化或使用意愿。

把产品内实际发生的使用过程单独记录，只收集判断下一步所需的信息。有人愿意体验但没有开始时，先问清原因；有人开始后没有完成时，回到中断的位置。不要用新增功能数量替代这些尚未了解的情况。

下一轮加功能，怎样与已有反馈对应起来？

为准备修改的内容写下对应的使用问题、预期变化和检查方式。先处理阻碍完成核心任务的部分，再考虑扩大用途。新想法暂时放入观察记录，等能够说明它服务谁、解决什么问题时，再决定是否进入开发。

当使用者能够理解当前产品并完成预期任务时，再邀请更多相似需求的人体验，观察原有问题是否重复出现。本文只以本站公开短摘要为线索讨论发布后的工作安排，没有读取或扩写付费帖，也未推断作者的用户、收入和留存情况。实际下一步仍需依据自己的使用反馈决定。

做自己的小样，检查交付结果

对于听说练习应用，可以让测试者从收到测试入口开始，独立完成一段三十秒练习，再说明在哪里听到反馈、是否知道下一步。记录安装失败、未开始和完成三种状态；帖子收藏不计入完成。本文没有安装原应用或招募测试者，试验时长只是建议的最小任务。