产品设计方式
第一，产品经理与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。只设计基本功能的产品可以把复杂度降到最低，把开发时间减到最少，因此是非常重要的。
第二，邀请一位开发人员（比如架构师或主程序员）参与设计原型。请他检查原型，帮助产品经理和设计师估算各种功能的直接成本和间接成本，指出设计上的误区，并分析、评估尚不确定是否可行的功能。等产品原型确定时，开发人员详细估算出所有产品功能的时间成本。如此一来，各项功能已经明了，而且对对方都是透明的，开发团队心里也就有底了。
第三，请真实用户验证（测试）产品原型，这一点至关重要。在产品团队全力开发产品前，产品经理和设计师必须确信产品是用户需要的，然而仅仅相信还不够，必须通过用户测试来验证。这好比不能仅仅因为开发人员相信代码没问题，就允许发布代码一样，必须对代码展开测试。
一旦基本产品确定，通过了目标用户的测试，就不可能削减任何功能。如果还能削减，那说明我们定义的不是基本产品。
产品软件开发
敏捷方法同样适用于产品软件的开发，但应用时应该做出相应的调整：即如何在开发过程加入用户体验设计，如何管理产品的发布和部署等。敏捷方法唯一不适合产品软件开发的地方是在架构设计方面。
敏捷方法鼓励开发人员不要拘泥与传统的开发流程，要相信简单重构和快速设计架构的优势。这对多数定制软件来说是可行的。但产品团队照搬定制软件的敏捷模式，就会遇到问题。至今多数介绍敏捷方法的图书、文章、培训课程依然没有深入理解产品经理和用户体验设计师的作用，因为它们针对的读者还是定制软件团队。
要想成功转型成为敏捷开发团队，选一位合格的敏捷教练相当重要，他必须理解产品软件与定制软件的差别，了解产品软件的特殊需求，而这正是多数人不明白的。
产品软件开发合理运用敏捷方法的十大秘诀
1、产品经理即是产品负责人，他代表了客户的需求。
2、使用敏捷方法绝不等于省略产品规划。产品经理仍然要明白产品的方向和目标，设定衡量产品成功与否的标准。在敏捷环境里，规划周期应该适度缩短，反复迭代，采用轻量级的机会评估方法代替冗长的市场需求文档。
3、产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，确保团队有时间攻克难题。
4、尽量把产品设计工作拆分成独立的部分，分而治之，但也不能拆得太细——好比建筑不能一次只设计一个房间。目标是设计出符合基本要求的产品。值得注意的是，在敏捷环境里，设计师必须加快工作速度，采用迅速制作原型的方法更能适应敏捷环境。
5、产品经理的主要任务是定义有价值、可用的产品原型和用户故事，作为开发的基础。请用户测试原型，根据反馈意见反复修改原型设计，确保交给开发团队的是有价值的结果，避免任何浪费，哪怕只是一个迭代周期。
6、让开发人员自主划分迭代周期。有的产品功能可以在一个迭代周期完成，有的却需要好几次迭代才能完成。好的原型可以提高工作量和开发时间的精度。开发团队必须考虑产品的质量、性能、扩展性，让他们自行决定如何划分迭代周期。
7、产品经理和交互设计师必须出席每天的晨会。晨会是一天沟通过程的开始，而不是结束。
8、除非达到了产品经理的要求，否则不要轻易发布新版本。产品经理必须确保交给用户的产品能正常运行，过度频繁更新版本会让用户感到不安。
9、在每次迭代完成后，产品经理应该向团队展示产品现状，以及下次迭代的产品原型，让大家看到工作成果，同时加深大家对产品的理解，增强团队对这种开发方式的信心。
10、在团队内展开敏捷培训，聘请咨询顾问协助你们完成向敏捷团队转型的目标。只有每位团队成员都真正理解敏捷方法，大家才能把工作重心放在执行上，否则敏捷方法就只能停留在教条式的理论层面。
机会不断
产品软件开发的机会会越来越多。为什么如此坚定，有三点原因：
首先，只要市场上还有蹩脚的产品，就有机会。（愤怒的用户决定着产品未来的发展方向——《跨越鸿沟》）
其次，技术不断发展。今天难以置信的创意，明天也许就能实现。
最后，现有的应用程序为将来的发展打下了基础，这是行业规律。比如最初，浏览器只是一个查看网页的应用程序。我们看到，以因特网为基础，有了应用程序、电子商务的蓬勃发展，出现了许多新应用的平台。