对产品故事进行首次讨论，应聚焦于如何具象化产品的机会。需求其实很可能是一个假想，那么唯一可行的做法是验证想法是否具备可行性。验证的方法很多，比如和客户、用户深入交谈，观察他们目前做事的行动，不断和他们反馈，用手绘线框图（Axure）和高保真模型实现解决方案的具象化，并以此和客户/用户进行沟通。通过原型和用户测试来验证产品方案是否真的有用，有价值，并能够质疑用户所说的内容，然后在开发过程中学习（Scrum），迭代乃至最终发布。必须要始终记得，交付给客户/用户的是可用产品。
基于验证的学习循环：开发-（最小可用产品）-度量-（与客户/用户一起，基于目标）-认知-（新的Idea）循环。
如何做计划呢？首先一点，就是要让所有团队成员对于即将要做的内容都非常非常清楚，因为估算要准确，就在于每个人都要真正理解自己在估算什么。第二步，制定可逐步达成的开发计划（先框架再细节。比如一种做法是先做端到端流程贯通以消除技术风险，再逐步添加业务功能）。注意，不要将所有的迭代产出都对外发布，对外发布是一个很严肃的事情，代表着对用户需求的承诺。
使用预算来评估估算是个好方法。
风险故事同样需要统一管理。不要遗漏。
“伟大的作品永远没有完成这回事，只有放弃”---达芬奇
迭代与增量。运用迭代思维持续评估和打磨作品，运用增量思维做加法。
开局，中局和末局。隐喻棋局。开局聚焦于必备功能或者用户步骤，重点关注技术条件和风险，所有开发只要跑通主流程就好。
中局，补充周边功能，主流程之外的可选流程以及复杂的商业规则，如果可能，增加质量方面的考虑，如性能，可扩展性和可用性。
末局，打磨，使产品更加抢眼。