上篇介绍原始需求（RR：Raw Requirement）的获取，但原始需求对于企业尤其是研发人员来说，无法直接使用。必须由专业人员或团队（如RAT，需求分析人员）进行分析、过滤和标准化，形成初始需求（IR，Initial Requirement）。这个转化过程的核心就是从“客户怎么说”转化为“客户问题与需求是什么”。

初始需求是站在客户视角，以准确的语言（完整的背景、标准的格式）重新描述的需求。从原始需求转化为初始需求可以遵循以下流程。

示例：

原始需求：产品自带锂电池，容量要大

针对这条原始需求，我们的产品经理如何转化成初始需求呢？产品经理（或RAT）可以通过“剥洋葱法”逐层追问：

1.      用户具体遇到了什么问题：经过了解，原来用户在使用便携式路由器时，感觉没多久（1.5小时左右），路由器就低电量了。经过统计，该问题确实存在，影响客户上网体验。

2.      在什么情况下发生：路由器满电，正常办公，包括浏览网页、收发邮件、远程会议等。也就是确认了应用场景。

3.      希望能支持多久上网：越久越好，至少3小时。

4.      当前路由器电池配备：时下便携式路由器多配备1800mAh - 2500mAh锂电池，基本配置。当前主流充电方式为Type-C。

5.      是否可以扩大电池容量：可以扩容，结合“便携、小巧”（另一条原始需求，该需求定义便携路由器的外观、颜色及大小，即长*宽*高），电池容量最大5800mAh。

汇总得到初始需求

在原始需求转化为初始需求时，产品经理（或RAT）需遵循以下原则：

1.      不直接采纳客户方案

2.      还原问题而非用户的情绪

3.      尽量量化

4.      判断市场的共性

5.      验收标准

以上示例仅描述如何将原始需求转化为初始需求。这个转化的核心不是“翻译”，而是“分析”，在转化的过程要避免“原文照搬”、“遗漏场景”、“无法验收”、“忽略价值”，也就是把客户的情绪、抱怨和自己的想法（用户自认的解决方案），还原成：场景+问题+量化指标+验收标准。

当产品经理分析得到初始需求后，需要将初始需求归纳到系统特性（SF：System Feature，也可称为产品特性）。为什么要引入“系统特性”这个概念呢？是因为引入“系统特性”是为了把开发工作从“我要做100个功能”转向“我要为客户解决相关问题提供5项产品能力”，确保所有努力都精准地落在客户价值上。产品特性的引入，建立了从“市场”到“技术”的沟通桥梁，也是作为投资决策和优先级排序的对象。

系统特性是“客户视角下，可见、可理解并能带来价值的重大产品能力”，是客户能感知、能理解并愿意为之付费的能力。每条特性都是满足客户特定需求的端到端解决方案。它不仅是产品的功能需求或非功能需求的归类，更是连接客户需求与产品实现的桥梁，也是产品版本规划和市场宣传的基石。

在需求分析、产品设计中，系统特性是为了满足用户需求而具备的核心能力。系统特性回答客户“这个系统（产品）能帮我解决什么问题？”以及“这个系统/产品运行起来有多可靠？”这两个问题。

如上文的初始需求（IR-2026-001），如何归纳到产品特性中。注，因为该企业的路由器本身就配置了锂电池，对应的产品特性为“持久续航”。这条特性是企业产品已有的特性。那么，我们分析得到的相关初始需求可以直接归纳到该需求下。（注：如果初始需求无法归纳到当前已有特性，则需新增特性。）

特性名称：持久续航

主要功能：

1.      提供锂电池，电池容量5300mAh（根据成本，将≤5800mAh具体量化）

2.      Type-C充电

3.      ……

产品经理把“初始需求”归类到“系统特性”，本质上是开展了分析（需求→问题/机会）和设计（问题/机会→特性）两步骤的工作。这是产品经理最核心的价值创造工作之一。