通过三年时间的探索和尝试，本文作者总结了通过提升产品框架设计能力来提升产品灵活度的操作方法，与你分享。
优秀的产品框架能够为产品的迭代和发展预留最高的自由度和可能性，并且可以让很多看似不同的需求以一种通用的方式被解决掉，从而降低产品复用和推广的成本，增加产品调整和试错的空间。
如果说排优先级是对开发资源的合理利用，那么设计一个合理的产品框架则是为你的产品创造了一个效能更高的驱动能源。
作为探讨这个课题的系列之一，本篇分享的是产品设计早期应该注意的一个主题：「提升产品的灵活度」。
提升产品的灵活度，核心要解决的问题是：在开发成本不明显升高的前提下，设计出灵活度高的功能，使产品满足尽可能多的使用场景。
这需要产品经理能够预判产品的发展方向、理解技术实现的成本、抽象总结出需求中需要灵活设计的部分。大概花费了两年时间探索和尝试，我总结出了以下几个有效的方法：
看三做一
不要孤立的看待某次改版和某个接到的需求，在思考当前需求时，对下个版本（甚至接下来三个版本）的需求要有比较清晰的预判和认知。然后去将后续版本中可能调整的地方在本期的需求里预留可拓展性。
如何操作
可以通过预设一些框架性的问题，去帮助自己实现这一点。
问题示例如：当前版本上线后，数据大概会有几种可能？→各种可能下，产品的应对策略应该是什么？→届时会产生哪些优化点？→哪些优化点是出现的概率比较高的？哪些优化点是对产品目标帮助较大的？→这些优化点对当前的需求的改动有多大？→当前需求做什么调整可以兼容后续的需求？
一些锻炼方法
每次提需求前都做上述问题的预设，然后在上线后，认真对自己的预设进行复盘，观察自己容易遗漏的情况是什么。
多参与其他同事的分享和讨论，理解其他产品的迭代思路，培养对各种产品优化方向的基本感知。
关注、保留一些优秀产品的各版本截图，以及查看它们的 App Store 更新说明，思考为什么它们在某个版本做了某些功能。
代入角色
除了实现自己的规划和方向外，在进行产品设计前，还要兼顾其他项目角色可能会产生的需求。要学会站在其他角色的视角给自己提需求，去试图列举运营、老板、合作业务方，在不同的时间、场景、目标下，对同一个产品上线后的反应和后续的需求会是什么。一旦你对其他角色对产品的需求理解的比他们自己更深入，就不会再经常面临「被动接需求」的局面。
如何操作
最好的方式是亲自去那个岗位工作一小段时间，如果没条件实现，依然可以通过预设一些框架性的问题，去帮助自己实现这一点。
问题示例如：他出于什么动机提出的这个需求？→如果当前需求的数据结果不能满足他的动机，他可能会提出什么需求？→这个动机下，还可能衍生出什么需求？→出现什么样的情况，他的动机会发生变化？→这个新情况下，他会产生什么新需求？→这些新需求和当前他提出的需求的相关性有多大？→当前需求做什么调整可以兼容后续的需求？
一些锻炼方法
扮演其他角色的back up，站在对方的视角去思考日常要面临的问题。
写测试用例，留意当前需求对边缘情况的覆盖度，然后形成不忘记思考边缘情况处理方式的思维习惯。
阅读其他角色的周报，留意各个角色工作的重点和目标，帮助理解对方的需求动机。
理解技术方案
如果不理解开发的技术方案，产品经理提出的需求很容易是「需求量增加」而不是「灵活度增加」的方案，会在PRD评审时遇到很大的阻力。虽然不需要深入到技术实现的细节里，但是对自己提出的需求的难易程度、开发成本、最佳实现方式、对当前系统的改动量有多大，是实现「灵活设计产品」的基本前提。
如何操作
理解基本的前端、客户端、服务端的交互关系；
评估出每一个功能的实现需要哪些角色，其中由谁实现成本低、由谁实现更灵活；
甚至在技术方案评审时，能够抛砖引玉，帮助开发提出灵活度更高的技术方案；
一些锻炼方法
向认识的每一个开发请教他设计的技术方案，尤其是能够担当技术PM的那些，邀请他们帮你理解整个产品在系统架构上的分布关系。
认真参与技术评审，理解每个开发之间的边界、调用方式、交互关系。
阅读开发文档，别怕难，代码比你想象的要容易和简洁，且通常会有注释。
研究开发写的系统架构图的设计思路，对产品自己画产品框架图亦有好处。
常浏览技术相关论坛，了解解决一个常规的产品问题，最新的技术方案和思路是什么。
抽象和正确组合
按照上述步骤操作，你基本上可以收集到自己所负责的产品80%以上可能衍生的需求，并且能够对每一个需求的实现成本有所预判。接下来，需要根据自己收集到需求的实际情况进行归类，如：UI&文字改造的需求、信息表达结构的需求、触发－执行动作的逻辑等，然后去组合出需求的共性，将其中需要提供多种选择的功能抽象出来，形成自己最终的产品需求。
如何操作
将需求中「需要经常调整、配置的地方」设计成配置项，由后台的某个开关来控制（可以邀请你的开发一起帮忙设计开关的方案）。通常UI/文案/展现逻辑等，均可做成配置项。记得在产品还没开发前就尽量将所有需要抽离配置的地方预设好，此时是成本最低的，一旦产品框架确定后，要再抽离出配置项，复杂度就会上升。
将通用和基础的部分抽离成一整个功能模块，个性化、定制、可变的部分抽离成另一个流程。通常来说，一个产品核心的主流程一定是逻辑相对固定的，在主流程上的分支流程需求变化较大，将主流程和分支流程分开设计、分别开发，会大大提高产品的灵活度。
在PRD中标明某处需要「预留扩展性」，在评审时提醒开发同学要注意技术方案的设计，要选择对后续方向来说开发成本最低的方案，而不是当前需求下成本最低的方案。
一些锻炼方法
扩大自己对产品的理解，哪怕是用户端产品，也要多去了解一些平台型产品、B端产品、商业产品的产品设计思路和方案。
多参考被别人夸赞为「很灵活」的产品，或者仔细研究「有几年历史」的产品，通常这些产品会整合了众多复杂的功能，并且在迭代中衍生出了合理的配置项和主流程、分支流程的设计。
亲身实践，吸取教训，举一反三。即使严格按照以上流程去思考和操作，也一定有自己预期外的情况出现，好的产品经理是必然花费诸多金钱和时间才能在实践中锻炼出来的。
千万别忘记，停留在「排优先级」层面的产品经理多如牛毛，在「产品框架设计」层面上的竞争才是产品经理的核心战场。当你发现80%的意外情况（跟自己产品相关的突发事件/老板心血来潮提的新idea……）下，自己的产品不需要额外开发即可解决问题，那么恭喜你，这一课你毕业了。
接下来会进行系列分享，主要分为「如何提升产品框架能力」、「XXX是为何失败的」和「XX相关的产品经理是做什么的」三大系列，可能是半年内你能发现的最好的产品相关内容，别错过。
