一、嵌入式产品概述
1.1 什么是嵌入式系统
嵌入式系统，说白了就是「藏在设备里的计算机」。它不像你桌上的台式机，也不像手里的手机——它被设计用来执行特定任务，而不是通用计算。
我经常跟刚入行的朋友说：「你身边能通电的智能设备，十有八九都有嵌入式系统」。微波炉、智能电表、汽车ECU、医疗监护仪……这些设备的核心，都是一块小小的嵌入式系统在干活。
嵌入式系统有几个关键特征：
- 专用性：为特定功能设计，不是啥都能干
- 资源受限：内存小、CPU慢、存储有限——你得精打细算
- 实时性要求：很多场景下，响应慢了就是事故
- 可靠性优先：死机了可不是重启那么简单
核心区别：通用计算机是「我啥都能干，但可能干得不够好」；嵌入式系统是「我只干一件事，但必须干到极致」。
举个例子。我参与过一个智能门锁项目。那款芯片只有64KB的Flash，4KB的RAM。你想想看，一个Linux系统光内核就得几MB。但在这种资源下，我们照样实现了指纹识别、蓝牙通信、低功耗待机——这就是嵌入式系统的魅力。
1.2 嵌入式产品经理的角色与职责
嵌入式产品经理，这个角色挺特殊的。你不能只懂市场，也不能只懂技术。你得在两者之间搭桥。
我个人习惯把嵌入式PM的职责分成三层：
第一层：需求定义
- 搞清楚客户到底要什么（注意，客户说的≠他真正要的）
- 把模糊的需求翻译成技术团队能理解的语言
- 做优先级排序——哪些功能必须做，哪些可以砍
我在项目中遇到过一件事。客户说「我要一个低功耗的传感器节点」。结果一聊才发现，他所谓的「低功耗」是电池用三年。但实际应用场景是每天上报一次数据，每次工作10秒。你看，如果不深挖，团队可能就按「持续低功耗」去设计了，那成本可就上去了。
第二层：技术协调
- 理解硬件选型的约束（成本、交期、性能）
- 协调固件、硬件、测试团队之间的节奏
- 识别技术风险——比如某个芯片供货周期拉长，你得提前预警
我的经验：嵌入式产品经理最好能看懂原理图和代码框架。不一定要自己写，但得知道团队在说什么。否则，你很容易被技术团队「带偏」——不是他们故意，而是你听不懂，就只能被动接受。
第三层：生命周期管理
- 从概念到退市，全程跟踪
- 每个阶段的关键决策点，你得拍板
- 出了问题，你是第一责任人
嗯，这里要注意。嵌入式产品的生命周期管理，跟纯软件产品差别很大。软件可以随时OTA升级，但嵌入式产品一旦出货，硬件就焊死了。你不可能让用户拆开设备换芯片。所以，前期的决策失误，后期几乎无法弥补。
1.3 产品生命周期模型（PLC）简介
产品生命周期模型，英文叫Product Life Cycle。说白了，就是一个产品从「出生」到「死亡」的全过程。
嵌入式产品的PLC，我一般分成五个阶段：
| 阶段 | 核心任务 | 关键输出 |
|---|---|---|
| 概念阶段 | 市场调研、可行性分析 | MRD、立项报告 |
| 设计阶段 | 系统架构、硬件选型、软件设计 | 设计文档、原理图、BOM |
| 开发阶段 | 硬件打样、固件开发、联调 | 样机、测试报告 |
| 量产阶段 | 小批量试产、大批量生产 | 量产验证报告、出货 |
| 维护阶段 | 售后支持、版本迭代、退市 | 维护记录、EOL计划 |
每个阶段都有它的坑。我曾经在一个项目里，概念阶段只花了2周就匆匆立项。结果到了设计阶段才发现，选的主控芯片根本满足不了功耗要求。没办法，只能推倒重来。那次教训让我明白：概念阶段多花一个月，开发阶段能省三个月。
避坑指南：我曾经见过一个团队，在开发阶段发现硬件设计有缺陷，但为了赶工期，硬是「打补丁」式地改固件来绕过去。结果呢？量产之后问题频发，售后成本直接吃掉了一半利润。所以我的建议是——该返工时就返工，别心存侥幸。
为什么会这样？因为嵌入式产品的硬件和软件是深度耦合的。硬件上的一个小问题，软件可能要用十倍的工作量去弥补。而且，这种弥补往往不彻底，迟早会爆发。
你想想看，一个智能家居网关，如果Wi-Fi模块的天线设计有问题，固件再怎么优化信号强度，也解决不了根本问题。用户拿回家，隔一堵墙就断连，你说这锅谁来背？
所以，嵌入式产品经理必须理解PLC每个阶段的交付物和评审标准。不能跳过，不能压缩。每个阶段都有它存在的理由。
总结一句话：嵌入式产品管理，本质上是「在资源约束下，做对的事情，并把事情做对」。PLC模型就是帮你找到「什么时间该做什么事」的那张地图。
好了，这一章我们聊了嵌入式系统的基本概念、产品经理的角色，以及PLC的五个阶段。下一章，我们会深入概念阶段，聊聊怎么做市场调研和需求分析。到时候我会分享一个我踩过的坑——关于「伪需求」的识别，挺有意思的。