产品需求文档，其作用是：将客户需求转化成开发团队能够理解的产品功能、性能、指标和参数，将前期的发现的市场机会和需求洞察，锁定并落地到具体的产品定义；
产品需求文档，通常由产品经理负责制定，由开发团队参与并提供输入；
产品需求文档，它综合了客户需求、业务需求、市场竞争、国家标准、行业标准、供应链能力和企业最佳实践，所形成的一份综合性的开发文档，也是后续开展产品设计、产品测试、物料采购、生产制造、订单交付等活动的重要依据。
步骤一：明确客户需求；
步骤二：将客户需求，转化成产品需求；
步骤三：产品需求评审。
无需求不产品，产品始于客户需求，终于客户满意。
产品的预期用途，产品需要做什么；
谁将使用它，需要如何使用，需要在什么环境条件下使用；
由于法规、语言和消费者行为不同，目标市场对产品的需求有何不同，等等。
优秀的产品经理，不仅关注终端用户的需求，还会关注：
整个产品生命周期中，与产品产生接触的所有利益相关方的需求；
这些利益相关方，包括老板、开发团队、供应商、仓储运输、销售代理、售后维修，等等；
这些利益相关方，只要跟产品产生接触，就会对产品有自己的利益诉求。
完整的客户需求，可以用两个维度进行展开：
时间维度：代表产品的生命周期，从需求开始，到开发、制造、运输和使用，最后到报废。
系统维度：代表产品的边界，从产品开始，到使用场景，再到周围环境。
2 将客户需求转化为产品需求
客户需求明确后，下一步就是将这些客户需求转化为产品需求。
这是一个对客户需求进行分析和筛选的过程，通常需要综合考虑客户需求、业务需求、产品战略和市场竞争，对各种需求进行优先级排序。
那些被选择在这个产品上实现的需求，就是当前的产品需求。
产品经理需要将这些产品需求，翻译和转化成产品团队容易理解的产品功能、性能、指标和参数等等。
通常，硬件产品需求包括如下内容：
产品由哪些零部件或模块组成，用什么传感器、什么芯片、什么电池、什么外部接口，它们之间是怎么连接、交互和工作的。
产品的外观、风格、尺寸、重量、材质、颜色、表面处理等有什么要求。
产品的外观设计有没有创新点，使用的材料和工艺有没有新突破？
产品为客户提供什么功能，其中哪些是核心功能，哪些是辅助功能；哪些是使用功能，哪些是美观功能。
这些功能是如何开始和停止的，工作逻辑和流程是什么，逻辑状态有哪些变化，使用条件和环境是什么？
除了基本功能外，有哪些功能是竞争对手不具备的，有哪些功能是优于竞争对手的？有没有超出用户期待的创新功能？
2.3 性能要求
产品完成既定功能需要达到什么程度，需要满足什么性能参数或技术指标？
产品的易用性、美观性、安全性、可靠性、可维护性、经济性有什么要求，怎么评价和衡量？
产品的设计寿命是多长，保质期是多久？
有没有哪些性能指标优于竞争对手，需要在产品开发过程中重点关注和实现？
2.4 交互要求
用户如何与产品交互，是通过按键交互、还是语音交互、或者视觉交互？
用户界面上有什么，需要采集、传递、显示什么信息和数据？
信息和数据的采集、存储、处理和显示，在速度、数量、质量、安全方面有什么要求？
访问和控制权限怎么设置？
2.5 环境条件
产品将在什么环境条件下使用？
正常的使用温度、湿度、海拔高度是什么？
正常的运输、存储和安装条件是什么？
是在室内使用、还是在室外使用？
防水、防尘、耐候性有什么要求？
耐冲击、振动、跌落有什么要求？
抗电磁干扰、通信方面有什么要求？
2.6 标准和测试要求
产品需要遵守哪些法规和标准，需要获得哪些认证证书？
需要进行哪些测试，测试要求是什么，验收标准是什么？
产品的功能、性能怎么验证？
可靠性、安全性怎么验证？
老化测试、寿命验证怎么做？
产品有哪些品质关键点，需要在产品开发过程中重点关注和实现？
2.7 生产制造要求
产品的哪些零部件和模块需要外购，验收标准是什么？
产能方面有什么要求？
关键元器件的供货，有没有备用供应商？
有没有卡脖子的生产技术和设备？
2.8 包装和运输要求
产品需要如何运输和存储？包装和运输的测试要求是什么？
产品有没有包含诸如锂电池、化学品之类的危险品，需要进行运输安全鉴定或者运输防护？
产品需要哪些标签、警告和认证标志？
需要哪些用户文档、使用说明书、安装指南等。
3 产品需求评审
将客户需求转化成产品需求后，就可以组织团队对产品需求进行评审。
评审通过后，就可以将产品需求确定下来，形成产品需求文档。
一般的说，需求评审，必须对产品需求的如下特性进行评估：
需求应该简洁、精确、易于理解，且只有一种解读方式。
需求不应该含糊不清、或过于笼统，以致出现多重解读、甚至不正确的解读。
那些大量使用模糊性形容词的需求，比如：用户友好、高效、及时、容易、可靠、尽量等等，都不是好的需求定义，需要进行量化。
举一个例子：
不好的需求：正常工作时，空气净化器的噪音应该尽量小，以免影响用户体验。
好的需求：正常工作时，空气净化器的噪音必须符合《GB/T 18801-2015空气净化器》的要求，目标争取控制在55dB以内，优于竞争对手的60dB。
3.2 正确性
必须准确捕捉、深刻洞察客户和关键利益相关方的需求和期望，并将需求洞察准确的转化成硬件产品的功能、特性，以及性能指标。
产品需求的确定，是一个反复的过程，需要通过与客户和关键利益相关方反复讨论、假设和验证，确保需求的正确性。
举一个例子：福特与马的故事。
不好的需求：一匹更快的马
好的需求：福特汽车
3.3 完整性
需求必须陈述完整、没有遗漏，以免导致误解或不理解。
当一项需求没有明确适用条件时，常常会出现完整性问题。
举一个例子：
不好的需求：台灯光源中心的发光照度必须大于1500lx；
好的需求：将台灯以正常工作位置放置在水平桌面上，投射在水平桌面上的、光源中心的发光照度必须大于1500lx。
3.4 可验证性
所有的产品需求都必须通过客观的分析、检查、测试进行验证，并且能够制定相应的测试计划和验收标准。
那些当前无法进行验证、或者验证成本超出项目预算范围的需求，当前都不是好需求。
如果无法验证的需求，是个性需求、或短期需求，建议取消该项需求。
如果无法验证的需求，是未来看好的长期需求，建议纳入下一代的产品规划中。
3.5 定义“是什么”，而不是“如何做”
产品需求应该描述用户和利益相关方的需要，将产品必须做什么、或者具备什么特性，描述清楚即可。
切不可过多关注如何实现需求，过多描述具体解决方案。
这样不仅剥夺了开发人员选择最佳解决方案的自由，而且还可能因为技术背景的欠缺导致解决方案不能充分满足客户需求。
举一个例子：
不好的需求：产品有一个红外传感器，能够探测当前环境是否有人出入。
好的需求：产品能够探测当前环境是否有人出入。
3.6 一致性
产品需求与任何其它需求都不冲突，且该需求的描述和术语，在整个产品开发过程中、以及产品开发各个阶段的文档中，都是一致的。
当一项需求的实现，禁止了另一项需求的实现，两项需求不能同时存在时，就会出现需求冲突和不一致。
对这种相互冲突或不一致的需求，需要进行综合权衡，根据优先级重新定义。
举一个例子：
可穿戴电子产品，总是希望功能丰富、轻巧、电池使用时间长，而这三项需求是互相冲突的：
功能丰富，往往会消耗电力，需要更大、更重的电池，产品体积和重量都会相应加大；
轻巧，则要求产品功能尽量少、使用更小更轻的电池；
而电池则由于技术限制，能量密度有限，必须加大体积和重量才能提供更多电力，才能提供更长的使用时间。
因此，产品经理必须在相互冲突的需求中找到平衡点，将要求明确在产品需求文档中。
3.7 可追溯性
每项需求，都应该被记录和唯一标识；
每次需求变更，都需要进行评审和记录；
以便在整个产品生命周期中，对需求进行追踪和管理。
4 产品规划，培训资料
PM11 需求分析报告（案例，77页）
PM61 需求收集（培训资料，31页）
PM62 需求分析（培训资料，35页）
PM70 如何做好需求分析（培训资料，18页)
PM72 需求追踪（培训资料，43页）
PM77 如何挖掘客户需求（培训资料，51页）
PM79 如何将客户需求转化成设计需求
PM106 怎么撰写一篇好的PRD（英文，26页）
PM116 新产品开发的需求管理（培训资料，131页）
PM117 大模型时代下的用户研究（资料，226页）
PM126 需求评审流程规范（规范，5页）
由于篇幅有限，本文只截取《PM61 需求收集》的部分内容：
5 培训资料，如何获取
上述所有培训资料，都已经上传到我的知识星球：产品人生。
只要加入产品人生（文末有码，扫马加入），就可以免费下载和学习！
我的硬件产品开发知识体系，来自百年名企飞利浦，来自我多年的产品开发和管理实践，来自我长期持续的思考和写作。
