发布之前先说明给谁用

一份有用的产品介绍应回答：谁遇到了什么问题、这个版本如何处理、现在可以从哪里开始。不要把未完成的功能写成已经上线。若还在内测，直接说明可使用范围、申请方式和已知限制，让读者判断是否适合参与。

展示一条可以复现的过程

准备一组脱敏的样例，演示从输入到结果的完整路径。截图应对应实际界面，说明应与当前版本一致。用结果解释产品价值：例如用户完成了什么任务、减少了哪一段手工操作。没有测量过的收益和客户数量不应写成数字承诺。

用一份发布清单检查遗漏

  • 页面写清产品用途、适用对象和当前状态。
  • 主要入口能够打开，手机上可以完成核心操作。
  • 提供简短开始步骤，以及问题反馈的方式。
  • 截图、示例和外部链接没有私人或客户资料。
  • 保留已知问题与更新记录，方便回来查看进展。

选择与你的用户相关的渠道

先寻找已经讨论这个具体问题的社区、项目目录或专业交流群。阅读发布规则，说明产品与讨论的关联，并诚实披露自己是作者。不要把同一段推广文案重复投向无关话题；回答实际使用问题通常比只留下链接更有助于了解需求。

区分看到、尝试和再次使用

访问、点击、完成一次核心任务和再次使用，是不同层次的反馈。可以先用简单的记录区分这些行为，再结合用户的具体描述判断。有人打开后离开，并不能直接说明产品方向错误；也可能是入口、说明或运行条件不够清楚。

让每次更新回答一个问题

把反馈整理成具体场景、出现频率和影响程度，选择阻止使用的少量问题进入下一轮。发布更新时说明修复了什么、哪些限制仍然存在，并让原先提供反馈的人能找到结果。TheSolo 的项目页可以记录产品阶段与公开入口，后续推广仍应建立在可用的交付上。