Lifelog — A Mythology-Driven Devlog
·
账本 — 固态融合
💡
原文英文，约4600词，阅读约需17分钟。
📝
内容提要
在《固态融合》中，松鼠团队认识到在客户未使用之前，无法确定所需的规则引擎。通过与客户互动，团队决定先进行实验，待客户反馈后再构建，最终记录下正确的想法，等待时机成熟。
🎯
关键要点
-
松鼠团队意识到在客户使用之前，无法确定所需的规则引擎。
-
通过与客户的互动，团队决定先进行实验，待客户反馈后再构建。
-
在实验过程中，28条规则被压缩到9条，最终确定了最小可行产品（MVP）。
-
团队强调需要客户的反馈来指导后续的开发，而不是依赖于假设。
-
松鼠团队记录了所有的想法和建议，等待时机成熟再进行实施。
-
客户的反馈被视为学习的机会，团队需要在客户使用产品后才能真正了解需求。
❓
延伸问答
松鼠团队如何确定所需的规则引擎？
松鼠团队通过与客户互动，决定先进行实验，待客户反馈后再构建规则引擎。
在实验过程中，规则数量是如何变化的？
在实验过程中，28条规则被压缩到9条，最终确定了最小可行产品（MVP）。
客户反馈在开发过程中的作用是什么？
客户的反馈被视为学习的机会，团队需要在客户使用产品后才能真正了解需求。
松鼠团队在开发过程中记录了什么？
团队记录了所有的想法和建议，等待时机成熟再进行实施。
为什么团队选择不依赖假设进行开发？
团队强调需要客户的反馈来指导后续的开发，而不是依赖于假设，以避免构建错误的产品。
最小可行产品（MVP）是如何定义的？
最小可行产品（MVP）是通过客户反馈和实验确定的，最终为9条规则。
➡️
