2. 机器人产品经理的角色定位

2.1 本章业务场景

你刚从消费电子转到机器人行业,第一次接手一款商用清洁机器人的PRD撰写。开完第一个立项会你就发现:机械工程师要“避障精度”,算法工程师要“场景泛化度”,市场部要“成本低于竞品”,工厂要“产线可装配”。所有人都在催你输出“需求”,但没人告诉你哪些需求该进PRD、哪些该砍掉。本章帮你定位机器人产品经理应该长什么样——以及你和这些角色的边界在哪、需求从哪来。

2.2 机器人产品经理能力模型

机器人PRD需要同时驾驭硬件、软件、机械、算法和商业逻辑,能力模型呈 T 型结构:纵轴深度扎根机器人的行业知识;横轴覆盖从用户场景到交付验收的全链路管理。

能力维度核心要求典型交付物/输出
用户研究与场景分析能走进客户现场(工厂/医院/商场)观察真实作业;用 AEIOU 框架拆解任务场景卡片、用户旅程图、痛点清单
系统架构理解力看懂机器人系统框图(感知→决策→执行);区分传感器、执行器、控制器依赖功能-模块映射表、SOTIF 安全边界
需求优先级与范围控制平衡工程难度、商业价值、法规合规(如机器人安全标准 ISO 10218)MoSCoW 清单、PRD 范围一览
跨语言沟通与翻译把机械工程师的“传动比”、算法工程师的“路径规划时延”翻译成客户能理解的业务语言跨岗位术语对照表、PRD 词汇表
验证与验收设计建立客观通过标准,防止“我觉得扫干净了” vs “覆盖率仪表盘达标”验收指标矩阵、KPI 仪表盘原型

业务问题:机器人PM最常见的陷阱是试图成为“小号的技术总监”。你的价值不在于比架构师懂代码、比机械总工懂材料,而在于把模糊的商用场景翻译成可工程化的需求单元。

2.3 与其他岗位的协作边界

机器人PRD不是一个人的独白,而是一张与各岗位“握手”的契约。每个角色在PRD中有明确的输入输出边界:

  • 系统架构师:PRD提供“功能场景+性能指标”,架构师提供“模块拆解+接口定义”。边界:PM不决策总线协议,但必须确认协议是否支持PRD中的延迟要求。
  • 机械/硬件工程师:PRD描述“作业环境极限”(如地面类型、温度、IP等级),工程师设计物理方案。边界:PM不画三维图,但要提出防护等级和可维修性(如电池更换无需工具)。
  • 算法工程师:PRD定义“行为规则”(如遇到正在充电的同类设备应绕行并预留5cm间隙),工程师实现软件逻辑。边界:PM不写一行代码,但必须给出清晰的 if-then 规则列表。
  • 测试/质量工程师:PRD包含验收标准(如单次充电覆盖面积≥800m²,避障成功率≥99.5%),测试据此设计用例。边界:PM不设计测试用例,但需确认通过/失败判据可测量。
  • 产品市场与售前:PRD输出“目标客户画像与竞争定位”,市场部提炼卖点。边界:PM不负责定价,但需提供保本成本阈值。

2.4 需求输入来源梳理

机器人PRD的需求不来自凭空想象,而是从以下五个“水源”过滤而来:

  1. 用户访谈与现场调研(核心水源):用结构化访谈脚本收集“极痛苦场景”与“期望行为”,输出原始需求卡片。典型问题:“您最头疼的清洁盲区是哪里?希望机器人先通知您再处理,还是直接上报后台?”
  2. 竞品分析与标杆拆解:拆解竞品PRD(如果能拿到)或产品评测报告,关注“功能溢出”和“力不能及”两类缺口。
  3. 技术可行性预研:算法/硬件预研纪要,明确当前可实现的“性能天花板”(如激光雷达在强光下的测距衰减)。
  4. 法规与行业标准:CE、FCC、机器人安全标准(ISO 13482、GB 11291)、行业准入条款(如商用清洁机器人的 EPA 规范)。
  5. 内部干系人诉求:市场、售后、制造、合规的口头或书面请求——但必须经过“价值-成本”筛选才能进入PRD。

用户访谈技巧:不要只问“你想要什么功能”。改成“请描述上个月最糟糕的一次清洁中断事件”,引导用户讲述完整场景,再从中提取需求原语。

2.5 能力、边界与输入的关系视图

机器人产品经理角色定位框架 机器人产品经理 用户研究 + 场景力 系统理解 + 翻译力 优先级 + 验证力 系统架构师 硬件/机械工程师 算法工程师 测试/质量 用户访谈卡片 竞品拆解报告 技术预研纪要 法规/标准 ← 核心能力层(支撑PRD质量) → 协作层(明确责任边界) → 输入层(需求来源与筛选漏斗)

2.6 本章关键交付物模板

完成本章学习后,你应该能独立产出以下两份文档(模板可直接在PRD项目中复用):

  • 《机器人PM能力自评表》:按五个维度打分,并列出2-3个提升行动项。
  • 《需求输入追溯表》:格式参考下方代码示例,确保每条PRD需求都能追溯到原始输入源。
【需求输入追溯表】               
需求ID  | 描述                         | 输入来源         | 来源类型   | 关联协作方
--------|------------------------------|------------------|------------|------------
REQ-001 | 低电量自动回充时避让障碍物     | 商场保洁主管访谈  | 用户访谈    | 算法/硬件
REQ-002 | 支持两天以上离线地图缓存       | 技术预研纪要      | 技术预研    | 系统架构师
REQ-003 | 充电桩防水等级 IPX5           | 行业标准GB 11291 | 法规/标准  | 机械/质量

常见协作边界冲突:工程师说“这个需求做不到”时,不要立刻妥协或直接压短期排期。应该先要求对方提供“性能受限的具体数据曲线”(如多久、多大概率失败),然后回到用户访谈记录看是否真的不能接受那个级别的“不完美”。往往第三次对话时双方会发现一个折中方案。