公式驱动：以应用类产品举例，如果一个公司可以同时向用户提供两种服务A和B，二者的利润不同，同时又会受到市场季节性需求变化和产能供应 量的限制出现数量上的波动;现在要求我们能够找到合适的资源分配方式，来让公司获得最大的盈利。这其实就是一个根据制约条件来找到A和B两种服务对应各自 需要有什么变量的问题。不妨列出一个公式，看看究竟各个制约条件之间是如何影响的，从而找到合适的解决办法。
要记得，在需求被拆解后的每一个问题有些是对应固定的角色的，而一些则是可认为是无所谓角色区分的共性问题，还有一些问题的处理结果会影响他角色。务须能分清楚来对待。分解阶段另一件重要的事情就是完成流程图的设计，对应产品人员要做的是业务流程图，如果有核心开发人员也参与了前期的需求讨论分析，可以建议他们同步展开架构流程的思考。
在绘制流程图的时候需要尽可能标明其中的里程碑功能，大约需要哪些功能支撑、需要设计多少个页面或频道、组件，对应的管理后台需要有哪些对应的 调用。这时候也需要一并带着整理。我的实践经验是，可以先做完流程图，然后把后面的这些问题带进去思考，一方面寻找答案，一方面也可以完善你的流程图。如果能够一路坚持走下来，基本上可以做到很完整地了解自己要解决些什么问题了。这时候你面对的就不再是一个总的需求，而是一个个细节的问题。接下来要做的就是对各个问题进行评估，
在经过了前面几轮重重的折磨，才是产品人员真正发挥创意的时候，你将左右会有怎样的表现，你拥有整个产品开发的决策权。别人可以提意见，但是最终你才是那个决定事情该怎么做的人。制定项目计划，针对每个细分功能拿出具体的实现策略，给出产出物的交付时间，绘制原型图和PRD文档。从产品整体框架到页面布局、频道功能再到 按钮的位置，弹出层的设计。设计的创意才在这里真正迸发，你所有知道的界面设计、导航架构、交互形式的知识和才能都会在这里得到淋漓尽致的体现。
暂且撇下你的设计创意不表，如何把评估阶段的成果应用好是我们是否能顺利进入决策阶段的关键。总会有一些功能被砍掉，也有一些新功能提出来，原 本想好的某些流程也可能要重新调整。在决策阶段，你需要有做减法的魄力和决心，抛弃一些东西，适当做一些让步，但是要能保证产品的核心功能不被阉割。对于 核心功能，任何为了减轻工作量或者无法实现而要求绕道而行的借口都是可耻的;如果你有有充分的理由相信产品的核心功能，那就一定要坚持到底。