三个月更新25个版本之后：Mytess 如何限制功能范围与观察使用
做产品与交付 · 软件与 SaaS · 产品迭代与范围取舍特斯拉数据 App 的开发者自述，借助 AI 在三个月内发布 25 个版本，并把产品限制在行程、充电、电耗等用车数据，暂不做社区、商城或控车。他描述了先给车友试用、再按使用情况取舍的做法；评论中也有用户称新增功能基本没用过，具体淘汰记录和留存结果尚未披露。
条件摘要 本站摘编 · 原帖当时记录
- 涉及对象
- 已上线并持续增加功能的小型App开发者
- 事项与做法
- 用产品范围与用户使用反馈决定功能去留
- 进展边界
- 版本数量和取舍做法为自述；具体淘汰、留存与收入未披露
原帖要点
- 限定在用车数据：Mytess 作者把行程、充电、电耗、电池健康与费用作为产品范围，说明论坛、社区、商城和控车暂不做，希望把已有数据算准、讲清楚。
- AI 加快制作，范围仍由自己决定：作者自述过去三个月发布25个版本，AI参与代码、语言补齐、截图和宣传图制作；功能更容易实现后，他反而更重视哪些事情不做。版本数量并非本站核验的商店记录。
- 描述先试用再取舍的方式：作者说自己减少事前功能调研，有想法先做给车友使用，用得多就继续打磨、没人用就拿掉。他举出足迹与成就徽章等新增项，但没有列出具体被移除的功能、使用人数或判断门槛。
原帖解读
制作一个功能变快以后，是否值得保留，仍需要另一组证据。
先用产品范围约束想法，再看使用证据
本站解读：作者明确只围绕用车数据扩展，这给新想法提供了筛选条件。进入范围的功能仍需回答谁会用、用于哪次任务以及是否会再次使用；功能仍属数据类，并不自动说明值得长期维护。相比站内单个付费客户要求定制功能的案例，这里讨论的是开发者主动增加功能后的普遍使用判断，不能直接套用单客报价或投入估算。
对照阅读：对照：单个订阅客户要求新功能
用户说没用过，先区分没发现与不需要
本站解读：Fish1024 在第1条回复表示正在使用产品，但新增功能基本没用过。这是一个用户的体验，尚不能证明多数人不需要，也不能反过来认定只需加强引导。可先了解对方平时看哪些数据、是否知道新增入口，再决定继续观察、解释用途或减少维护。作者没有公开观察周期、活跃用户基数和具体淘汰记录，因此“没人用就拿掉”仍是其描述的做法，而不是可复用的阈值；25个版本也不等于留存或收入改善。
来源：Fish1024 · 第1条使用反馈yekk · 快速试做方式
对照阅读：区分实际使用与付款证据
接下来检查什么 本站建议
分别观察功能被使用、重复使用和付费的证据。
小范围验证要看什么，什么反馈还不足以说明需求？按环节阅读：做产品与交付 · 把想法做成产品或服务，检查能否完成交付。
