很多产品最初并没有完整的商业计划。它们只是从一句很具体的话开始：“我希望这件事能更简单一点。”
OnePlayer 的起点也是如此。我们想要一个真正尊重本地音乐收藏、打开就能听歌的播放器。
先解决自己反复遇到的问题
真实需求通常带着具体情境：什么时候发生、为什么不顺、现有方式哪里让人失望。它比抽象的“用户可能需要”更容易验证。
当我们自己也长期面对同一个问题，就能更敏锐地发现微小摩擦，也更愿意花时间把它处理好。
用最小版本验证方向
第一版不需要回答所有问题。它只需要证明核心体验是否成立：用户能否更轻松地导入音乐，能否快速找到想听的内容，播放过程是否稳定。
越早让真实用户使用，越容易区分真正的需求和开发者自己的想象。
让反馈改变细节，而不是稀释方向
反馈很重要，但并不是每个建议都应该变成功能。我们会寻找反复出现的模式，再判断它是否符合产品最初想解决的问题。
这样既能让产品持续成长，也不会在一次次局部需求中失去自己的边界。
小问题也值得认真解决
独立开发的优势，是可以选择那些不够宏大、却真实影响日常体验的问题。只要它反复发生，并且我们相信可以做得更好，它就值得成为一个产品的开始。