产品蓝图勾勒

高价值方案构建

解决方案是针对用户的问题和需求提出的一整套方案，这个方案可以包含产品、服务等内容。只要解决了用户的问题和需求，就能够给用户创造价值。解决方案是产品、服务等内容的合集。

产品经理要从解决方案的角度思考，除了产品还有什么要提供。而且解决方案是从问题出发的，要能给用户解决问题从而创造价值，而不是从功能出发。产品经理常犯的一个错就是从产品的功能出发，然而用户要的不是功能，而是要解决问题。

产品战略和解决方案所解决的问题是不同的。产品战略在定义产品的边界、公司的内外资源；解决方案在产品边界确定之后，明确该产品下面的模块值不值得做。

有些需求并不一定要开发新的产品功能来解决，现有功能也许就可以在一定程度上直接或间接满足诉求。产品经理首先要对此进行判断，不要盲目、匆忙地着手新功能的设计。如果需求优先级并不高，客户又很着急，那么通过一些已有功能去部分地、间接解决问题，也不失为一个能尽快帮助到客户的好选择。尤其是对于甲方自研自用的系统情况，研发资源有限，如果可以用一些变通的方式解决问题，并不一定需要开发新功能。

在甲方工作的软件产品经理必须意识到，解决业务问题才是核心目标，软件产品只是为了解决业务问题采用的手段之一。有时候通过软件产品解决问题的投入产出比反而比较低。

通常来讲，首先要梳理所有解决方案，先不要评估方案的价值，然后进行全面的价值点分析。一款产品既要对用户有价值，也要对企业有价值。最后是明确双方的价值高低。

场景与功能模块定义

在每个独立的业务场景里，用户可能会跳转访问不同的模块和页面。产品经理需要识别不同场景中的共性内容，进行抽象归纳总结。

可以基于业务领域来抽象模块。业务领域是一个很宽泛的概念，可能包括业务部门、业务单元、业务主体等等。业务领域作为模块划分依据，让模块之间体现出更强的内部聚合性以及松耦合特征。

还可以基于业务场景抽象模块。有时候通过场景来定义菜单，反而逻辑更清晰，更容易理解。基于业务场景抽象模块，更多是从用户体验和业务逻辑出发来做模块划分。在场景菜单下，可能会融合多个模块的功能。

基于业务领域抽象模块，内聚属性更强，和技术架构的模块设计比较贴合。

总而言之，基于业务场景抽象模块，体验属性更强；基于业务领域抽象模块，逻辑抽象属性更强。

除了上述两种方法，还可以基于业务对象抽象模块。也就是将业务开展、运作中关键的业务对象，包括人、事、物，定义成模块。

功能框架设计

设计功能框架的目的是理清业务有什么功能，而不考虑小的功能点。从另一个角度来说，搭建功能框架要理清业务宽度，而不是业务深度。通过理清业务宽度，产品经理就可以避免功能遗漏。

总共分为 5 个步骤：

找到所有参与者，包括参与人和参与系统。
定义内外系统。
找到目标层用例。
找到实现层用例。
找到步骤层用例。