前言

2021年对我来说是特别酸爽的一年，这一年我接手了一个还未正式发布就已经烂尾的产品，研发全体跑路、产品文档基本空白、若干即将“爆炸”的已签单项目……所幸苟到现在，产品终于步入正轨。
在这段经历里，我开始思考安全产品如何从idea到能够平稳落地实现，然后发现——绝大概率研发是不可能把产品做砸的，做砸也是因为产品经理压根没想清楚:）而产品经理要如何跨越从idea到可落地实现这道思路鸿沟呢，那么至少要把以下7个问题想清楚。

Step1：用一句话描述产品要解决的问题（What）

如果一个产品无法用一句话说清楚它是要解决什么问题的，那基本上可以说是废了，后续没有必要再继续。

Step2：给出用户故事（Why）

这一步是Step1的强化，用具体的用户故事来帮助团队达成思想统一，真正理解我们接下来到底要做个什么事，能产生什么价值。

Step3：分析业务场景，说明产品准备怎么解决用户痛点（How）

罗列用户业务场景（主体+客体+动作+规则），分析业务场景中的各个组成元素，将其不断拆分、细化、扩展，比如说：
主体有哪些类型，未来可能延伸到什么类型；
客体有哪些类型，未来可能延伸到什么类型；
动作到底是怎么进行的，越具体越好；
整个过程要进行需要哪些前提，受到哪些规则限制，包括管理要求、政策要求、等保测评要求、其他潜在的要求等。

然后看我们的产品准备从业务场景下的哪些部分下手，从而解决用户痛点。

Step4：确认产品的获取、配置与使用流程（How）

解释如果用户该如何获取、如何配置、如何使用我们的产品，先进行什么步骤，后进行什么步骤，最终解决其面临的问题。这里可能会比较耗时，最后应该要输出产品形态说明、产品部署实施方式、产品主流程原型图。

Step5：识别产品关键质量需求（How）

在进行Step4时，我们会很自然地注意到一些质量相关的需求，这里我直接引用徐锋老师《有效需求分析》中提到的六点需求，不同的产品在这六点有不同的侧重点，需要对号入座。

5.1 易用性需求

效率要求高
用户基础弱
与设计者思维差异大

5.2 安全性需求

有哪些敏感数据？
开放了哪些端口？
有无已知安全漏洞？

5.3 可靠性需求

长时间运行，对内存、磁盘的占用
使用者手生，误操作是否会使系统运行不可靠

5.4 性能需求

找出最高并发的场景
识别需要复杂的算法和实现逻辑的地方

5.5 可维护性需求

业务变化，管理模式、业务模式、法律法规等变化
技术变化，出现新的技术趋势、应用技术等

5.6 可移植性需求

可移植性的最大威胁：系统生命周期长，使用周期长就越可能经历多次技术变迁，就增大了移植需求；系统部署范围大，涉及更多客户、地区、国家

Step6：产品全生命周期分析（How）

为了确保内容完备性，我建议还需要从产品全生命周期的角度（如：立项-开发-测试-发布-推广-采购-使用-维护-退市）出发，逐一分析产品的各生命过程，看在每个过程里产品会接触到哪些人，他们都是什么角色，都关心什么事情，以确保我们所准备做的这款产品，能够流畅地走完全生命周期。一款ToB产品，绝对不是只满足最终实际用户的需求就够了的，一定需要充分考虑上下游各个岗位角色的利益诉求。

Step7：产品roadmap（How）

如果要做的事情太多，建议分成几个专项来逐一实现（一定要分成专项，每个专项都有明确的目标，不然研发团队会抓不到重点），而这几个专项的内容和顺序就构成了产品的roadmap。roadmap的确定，也需要充分考虑当前市场状态、实验局项目状态、公司销售渠道特征等。

总结

想清楚了以上7个问题后，再将它们落到纸面上，这已经就是一份合格的产品需求说明书（PRD），可以作为PM、SE的工作指导材料了。我不认为那些一上来就直接罗列界面功能模块的文档叫做PRD文档，那样的文档对团队成员理解产品没有任何帮助。而一份合格的PRD文档，可以让每个阅读它的成员（哪怕是新成员）都能快速理解这个产品是什么、为什么要做、怎么做，他身处这个产品研发项目中的什么位置，到底该如何去落地自己的工作。