作为一只初级硬件产品经理，有幸找到适合的方法论，踏上升级路。一起走吗？
深深记得两年前决定要成为（智能）硬件产品经理的孤独夜晚，亲人的劝告与不解声声入耳——“为什么要找罪受呀，你想做的这个工作就是听起来好听，说好听点是‘经理’，不好听就是打杂的嘛”。
不是的，我在心里默默地说，就算是打杂的，也是梦想做出点有价值的商品的！
一晃两年过去，从跨行的菜鸟走到现在，也有幸经历了数个大大小小的项目。在疼痛中学习，在责骂中成长，坎坷路上幸而能遇到互帮互助的同伴，也幸而摸索出了一套适合自己的方法论，由此更加坚定的在升级路上走下去，你要一起吗？
本文主要从行业知识，软/硬件基础知识，必备文档，流程等几大方面，阐述硬件产品经理的知识体系，以及搭建该知识体系的方法论。比较适合我自己，但希望对你有点儿帮助。
一、产品经理的不同阶段
为什么用“升级路”这个说法，因为私以为产品经理的职业修炼就是不停的遇到困难，解决困难，就像游戏里打怪能够升级一样，解决困难之后你也就获得了相应经历，得到成长。
不过，经验达到一定程度后增长就放缓起来，必须要经过某些特定契机，以让自己的职业层次得到升华，这样自身的经验积累就又能踏上一个快车道。
类比于游戏里的“一转”、“二转”、“三转”（如DNF里的“剑魂”到“剑圣”再到“剑神”），我将硬件产品经理的成长粗暴的分为三个阶段——没错，就是“初级”、“中级”、“高级”。
这三个阶段的关注点有所不同：
初级：关注产品怎么做出来？
简单的说，就是在老板或市场团队的授意下，配合（或兼任）项目经理，针对一个已被评估能够为公司带来利润的产品概念，和团队一起将概念落地，将产品实现。进而配合生产团队和市场团队，将产品转化为商品，实现既定利润目标。
中级：关注产品应该怎么做？
中级的硬件产品经理，在通晓本公司的产品及产品簇的基础上，开始将目光放到市场，关注（现有的及潜在的）竞争对手。此外，他/她还对品牌建设和渠道推广有所了解，因而能够结合公司产品优势，在变幻莫测的竞争市场上，规划出一条最适宜的产品迭代路径。
高级：关注应该做什么产品？
之所以能被称上高级，概因其已具备了强大的资源整合的能力、洞悉趋势的能力，以及团队搭建和管理的能力。他/她能够把握人们需求的变化，并在需求的潜伏期就提前布局顺势而为。因而，他/她总是能站在风口，品尝蓝海市场的第一杯羹。
我正处于第一阶段，时刻关注着产品怎么“快好省”做出来。
在我的漫漫升级路上，我发现90%以上的困难都来自于人，而为了更好更有效率的解决人的问题，一个扎实的知识基础是不可或缺的，这就来到了今天的主题：如何搭建自己的知识体系，令自己的知识更加深厚，因而能更有底气的与人交流。
二、知识架构
总体上看，硬件产品经理的知识架构应该包含五个主要方面：
1. 行业知识
这部分知识是告诉产品经理应该做什么产品。行业是立身所在，若产品经理不清楚自己行业自己公司是做什么的，面向的用户是什么样的，做出来的只能是一团乱麻。
行业按照大类来说有IT通讯、家电家居、汽车工业、商业贸易等数十种；再细分的看，IT通讯业又可分为纯软件、互联网、安防监控、电子数码、通信通讯等十数种行业。
2. 流程
大家不要轻视流程，正确的认识流程能让你做事有章法有条理，能将各个环节中涉及到人、物、料、法几大因素串在一起，让所有干系人都朝着同一个目标努力，推动产品更快落地及盈利。
3. 必备文档
产品经理会经历一个产品的全生命周期，所以必备的几大文档都是会涉及到的。此外，产品经理在项目过程中，有时会客串项目经理的角色，所以产品方案、项目立项书、项目章程等也是需要熟练掌握的。
4. 硬件基础知识
这部分知识是告诉产品经理应该怎么把产品做出来。硬件的基础知识在很多行业都是通用的，涉及到PCB板卡、器件选型、各种硬件接口、各种网络及通信协议等。
当然，若是针对特定细分行业，仍是有部分独有的硬件知识需要掌握的，譬如：卫星通信业，产品包括抛物面天线，而天线的上变频放大器(BUC)，或下变频低噪声放大器(LNB)等关键器件的相关知识就需要重点了解。
5. 软件基础知识
这部分知识同样是告诉产品经理应该怎么把产品做出来。一款硬件产品，大概率上是会有嵌入式软件，就是嵌入在硬件中的操作系统和开发工具软件。形象的说，硬件是身体，软件是灵魂，系统层面上来说，嵌入式软件就是让硬件能够跑起来。
此外，若产品涉及到平台化，即能与其他智能硬件产品相互通信，那就还会涉及到一个管理平台软件，这部分的知识也要略作了解
三、行业知识
笔者所在行业，是一个方兴未艾的朝阳行业——卫星通信，属于IT通讯业下的细分行业。
卫星通信是利用卫星转发器作为中继站，通过反射或转发无线电信号，实现两个或多个地球站之间的通信。卫星通信是现代通信技术与航天技术的结合，并用计算机对其进行控制的先进通信方式。
根据上下游关系，卫星行业又可分为卫星制造、发射服务、卫星服务和地面设备制造四大领域。作为一个硬件产品经理，我目前扎根的领域就是地面设备制作，这也是目前卫星技术最具产业化的应用方向。
我大学专业是能源与动力工程，隶属于机械院，主要研究的是（汽车）发动机，核心学科是机械工程、结构力学、材料力学、热力学、燃烧学等，可以说与卫星通信行业相差甚远。工作之后，开始有意识的接触电子相关知识，曾经做过一款基于Arduino的智能化物料托盘。
在踏足卫通行业之前，可以说我对具体的行业知识知之甚少，相信很多跨行的产品也和我遇到过同样的困境。
而为了快速攀越行业知识门槛，我做了以下几件事：
1. 从过去经历找共通点
顾名思义，就是发现过去经历中与行业相关的部分，加强亲切感，减少疏离感。这一点很重要，因为人对未知的事物总是感到恐惧，当你两眼一抹黑抓瞎的时候，往往是硬着头皮做事，事倍功半。
对我来说，因为我有一个消防员弟弟，恰好就是通信兵，因此闲聊时他会告诉我他的日常工作。记忆里比较深刻的一次，他说他会使用卫星通信便携站直接将火灾现场的画面传到指挥中心，便携站上架设了一个“锅状天线”。我记得当时我追问这个锅状天线是不是就是小时候收电视信号的那种，得到否定的答案后还疑惑了蛮久。
入行后不久，我就带着这个疑问向行业前辈请教，在解惑的同时还进一步了解了偏馈天线与正馈天线的区别，U/V/C/Ka等波段信息等。那基于这个问题所得到的答案，我在补充基础知识时也就有了一定的方向，并且能相互映照加深记忆。
2. 从公司业务找切入点
就更为直观，了解公司业务的同时，也就进一步加深了对行业的理解。
了解公司业务最快的途径，就是浏览公司官网，找到公司对外提供的产品与服务，解决方案与应用。只要公司不是垄断企业，在市场上是一定有竞争的，那再以产品名作为关键词进行搜索，就很容易进一步了解到产品的受众及行业状况。
此外公司在行业内生存，必然是有产品彩页/产品手册等提供给客户的。
我的做法是这样的：
对某本产品手册逐行研读，遇到不懂的名词就记录下来。
针对不懂的名词，从网上搜索专业解释，并将名词解释采集到笔记本或电脑表格里。
在有了一个大概了解之后，向公司里的老员工请教。
再拿出另一本产品手册研读，这个时候可能还会遇到新的不懂的名词，再重复以上过程。
这样形成一个闭环的学习回路，知识在脑海里反复验证记忆，不易忘记，同时还和日常工作紧密关联。
值得一提的是，公司一般会针对不同行业或领域提供不同的解决方案，所以产品手册一般会有几本，各有侧重。但是产品都是相通的。当你把一本手册摸熟之后，再看其他的手册，即便是有新的内容，也并不多，这样未知的领域是不断收窄的。
3. 拜读专业文献
是在经过以上两步学习，对行业知识有了一定的了解之后进行的。此时你获得的知识都是碎片化且较为片面的，需要一个系统帮助你将这些碎片知识整合起来。
在这里我并不推荐独自梳理，因为这样见效慢且错漏多。我的做法是先搜索行业内的专业考试项目，然后阅读标准的考试教材。像在通信行业，就有一门考试非常出名——“全国通信专业技术人员职业水平考试”。
对于产品经理来说，很难在短时间内在一个专业深耕到一定水平，所以我推荐初级职业水平考试的培训教材：《通信专业综合能力》和《通信专业实务》。将这两本书熟读几遍，我相信面对业务范围内七成的问题都能做到心中有底。
4. 打入专业圈子
这一方法可以说从最开始就已经同步进行了，你进入行业内，与公司里的前辈交流，本身就是进入专业圈子的表现。
当然，除此之外，我还常用其他几种方法进一步扩大知识圈：
多参加各类展会，了解上下游供应商的产品。在笔者所在卫星界，有个每年都会举办的“卫星大会”非常出名，细心一点能找来很多往年大会上各公司产品的宣传手册，拜读之后收益匪浅。更可以亲身入会感受，实际参与专业圈子人士的交流。
关注行业内有知名地位的网站，像是卫通行业，比较著名的网站有中国通信网。平时多关注市场部门的同事都在什么网站上搜索信息，就能得到不少启发。
关注相关微信公众号，较高质量的微信公众号有“卫星与网络”等。平时多关注行业前辈都在看什么公众号就好。
四、流程
产品经理要对产品负责，大多数情况下不是职能上的管理者，但又是产品实际上的管理者。
换句话说，硬件产品经理大多数情况下并不是团队内结构/硬件/嵌入式工程师等的直接上级。这种情况下，优秀的产品经理一定要学会合理组织团队，拉动资源及有效沟通。
硬件产品经理的工作会受到很多现实条件的约束，工程师的时间总是不够用的，成本总是要被紧紧控制的，项目总是要在时间节点前完成的。因此，作为硬件产品经理，永远需要考虑“什么事情应该优先完成 / 什么事情应该马上就做 / 什么事情这次必须要做 / 什么事情这次可以不做 / 做这件事情有没有更好的方法？”
为了更好的推动产品落地，产品经理需要借助一定的技巧和良好的流程，为团队成员营造良好的研发环境：
确保团队成员手头正在做的始终是优先级最高的工作。
要求团队成员评估能否在规定时限内完成安排的任务量，若他们认为在时限内无法完成，需要和团队成员沟通时限内能够完成哪些部分，和目标有多大差距，有没有可接受的Plan B。
在上游工作完成后，及时将接力棒协调转交给下游环节，不拖延。
有效预见下一个阶段产品的演进空间，确保在发生产品迭代及需求变更的时候，只需要很少的返工量。
由此才能创造一个良性循环：团队成员不会质疑产品经理的需求及安排，每个人都尽心尽力的做事，不相互扯皮拖后腿。
下面从三个角度阐述我对流程与管理方面的认知：
1）硬件产品的全生命周期。
2）硬件产品经理在特定阶段的工作流程。
3）危机处理。
1. 硬件产品的全生命周期
作为硬件产品经理，要对自己负责的产品的全生命周期进行深入的了解。
一般而言，硬件产品的生命周期分为六大阶段，如下图所示：
2. 硬件产品经理在特定阶段的工作流程
硬件产品的不同生命阶段，项目组成员的组成不同、目的不同、工作内容的侧重点不同，产品经理所起的作用也不尽相同。
因为涉及到太多细化的阶段，如产品推广阶段里的大批量生产，就涉及到供应链管理，标准工艺流程确定，精益生产管理等各种环节，环环相扣缺一不可，就不是本文能简单阐述完的了。
下面我将针对产品经理经常挂在嘴边的“需求”，来介绍一下我在接到需求后的处理流程。
首先，我将需求分为两种：
1）新发起的产品项目/需求。
2）现有的产品项目迭代/需求变更。
公司里面一般会有专门的需求分析师(BA, Business Analyst)，或承担类似作用的角色（如用户调研小组或客户管理小组，可能属于商务部或市场部），在基于业务发展的需要，或对用户反馈及产品数据的分析，或竞品分析的基础上，提出新的需求，甚至整理规划好一系列的产品需求簇。产品经理需要从这些原始需求里面进行筛选提取，然后执行。
这里要插一句，很多产品经理未入行前总对这个岗位有一定误解，觉得自己的使命就是要集公司之力打造一款跨时代的产品（大概率上还是产品经理自己提出来的），有这种梦想没有问题，但错在没有摆正自己的位置。
原因有两个：第一你没有积累/经验/资本；第二你没有相应的眼光。
我的建议是：大胆假想，小心求证。
转回正题，下面先说第一种情况下（新发起的产品项目/需求）我的工作流程：
流程很简单，共有五个节点，在每个节点处做正确的事，以使项目顺利推动，项目干系人都明确了解项目进展，从而处处有着落，事事有回音，最终形成闭环。值得一提的是，当项目进展过程中，原始需求发生变更时，同样需要BA进行邮件确认，产品经理确认后以邮件回复日期（可能延后）。
再说第二种情况下（现有的产品项目迭代/需求变更）我的工作流程：
这里需要指出：为什么存在需求累积这一步？
当“需求”被客户提出时，通常是没有经过筛选的，这个需求完成之后，能否真正解决客户的问题实际上也未被仔细考量过。因此，这种原始需求用“意向”来表达更为准确。产品经理需要做的（而又经常被忽视的），是对客户提出的大量意向进行评估与转化，分析出内含的真正的需求点。
3. 危机处理
为什么要把危机处理单独拉出来讲，那是因为产品在全生命周期中将会遇到太多的坑了。这里的坑，一个处理不好，就会变成产品的危机，甚至演化成团队的危机，所以危机处理尤为重要。
产品的危机有两种直观表现：
1）产品研发与推广的延期。
2）产品推出后，无人问津甚或受到市场的大量负面反馈。
先说第一种：产品研发与推广的延期。
作为硬件产品经理，我们对项目的进度负有直接的监管或控制责任（不是所有的项目都是产品经理和项目经理做搭档，更多的时候是产品兼任项目），所以最开始就应做好风险评估与风险控制，不能眼睁睁看着危机发生。
然而，当危机真的不期而遇，我们能做的就是“拉响警报”，主动去协调资源，解决当前危机，避免或缓解项目延期。
如何协调好资源，我有几个小tips要分享给大家：
①优先内部协调，能内部消化的问题尽量内部消化。
举个例子：
某款智能监控设备项目内含信号收集模块、信号处理与发送模块、电源管理模块三大模块。在项目伊始确定任务边界时，划定三位硬件工程师分别完成三个模块的设计。
当信号收集模及与信号处理与发送模块完成设计准备打版时，发现电源管理模块设计遇到问题，某个多路稳流供电的电路迟迟不能确定。这个时候，不妨协调另两位工程师暂且放下手头工作，帮忙审核原理图，做好逻辑确认，甚至帮忙lay一下板，优先解决这个项目瓶颈。
②决定开口向外部要资源时，做好前期准备工作。
当遇到当前项目资源无法解决的危机时，请直接一点，及时向外部索要资源，但我强烈建议你做好预案——需要多少人，需要具备什么样的技能，需要几天时间，怎么和团队成员配合，这些问题请你统统和团队成员商量好再做决定。
另外，为达到更好的效果，建议你私下里找你中意的人选聊聊，了解其手头工作量和他/她支持你工作的意愿。
③在合适的时机说合适的话。
当你做好预案，满怀忐忑的向老大开口要资源协助时，不妨选择一个合适的时机，如：早晨10点到11点的时间段，这时候老板受生理影响最小（不饥饿不烦躁不困倦），更愿意给你时间阐述自己团队遇到的难处。
此外，切记不要夸大自己的困境，老板自有其判断；切记主动提出解决方案，不要让老板帮你想办法；切记不要替老板做决定。这就是说合适的话。
④拿到资源立马开动，及时报备。
深知这些资源都是“借来的”，容不得挥霍，因此确认好资源到位后就应该立刻组织团队成员开动，踏踏实实填坑。
此外，项目的进展要及时向上级和资源借出方做好通报，让他们知道你的项目在得到支持后确实有所进展，前去帮忙的人手也有在按照计划工作，而不是被你拉到其他项目上“帮忙”。
现在来说第二种危机：产品推出后无人问津甚或受到市场的大量负面反馈。
产品推到市场上接受用户检验时才发现无人注意或槽点满满，产品经理负有不可推卸的责任。
一般而言，导致这种状况有两大方面的原因：
1）市场定位不准。
2）需求执行虎头蛇尾/与竞品差距太大/产品生产质量太差/产品没有售后等。
笔者的产品生涯中就“有幸”经历过这种危机，也感受过那种被客户怒怼时的窘迫和无奈。当时我没有好的办法来应对这种危机，全赖一位产品前辈的提携与鼓励，现在我将当时他的做法分享给大家：
对证明市场决策错误的产品，及时停产，及时止损。
针对市场反馈的负面意见，承认自己产品的不足，迅速启动版本迭代计划，并给出新品推出时间节点。
对已购买产品的用户，推出“随心换”服务，并承诺新品出来后老用户能够以折扣价购买。
虽然我们通过市场分析、用户分析等方法提升产品的市场决策准确度，通过精心打磨每一款产品来提升产品的用户体验，但不可否认的是：“爆款产品”背后隐藏了太多销声匿迹的“失败产品”。
连微信这样的大怪兽也有曾被犹豫怀疑差点放弃的时候；大疆的一款相当成功的OSMO灵眸系列三轴云台，其背后也有OSMO RAW这种从未真正打开过市场的产品。
当我们遇到这种产品危机时，是及时放弃量产转为技术储备，还是秉持匠人精神继续打磨，就要看管理者的智慧了，仁者见仁，智者见智。
五、必备文档
可能会有朋友觉得文档和流程两者都挺“虚”的，没有软硬件基础知识来的实实在在。
其实不然，落于纸面上的很多东西能够帮助我们更好的沟通。就像我之前说的那样，产品经理日常工作中90%的困难都来自于人，基础知识能令我们说的话更有说服力及可信度，必备文档和流程能令我们做的事更具条理性和逻辑性。两者缺一不可。
下面和大家聊一下产品经理日常工作中经常出现的场景：
场景一：
刚入职，老板让你先对自己公司的产品熟悉一下。你找了一通资料，粗略的看了一遍，有了一个大致的印象之后向老板口头汇报了一下。下次老板问起来，发现已忘了个七七八八。
场景二：
入职一个月，开始在产品总监团队里面打打下手。产品总监让你找到其他公司的同类产品，并评价其相对于本公司产品的优劣点。你勤勤恳恳的找了数家公司的产品，从你能想到的各个方面进行剖析，得出结论，竞争对手家的产品没有一处比得上自家产品的。
场景三：
入职三个月，开始独立维护一个小批量量产的产品（对硬件来说是量产，对软件来说可以是上线）。此时各方的要求纷至沓来，生产方面（公司自己工厂/OEM/ODM）提出某个设计非常耽误生产，设计方面提出有个功能点忘记加上去，老板又对你说某个功能点别人家做了我们家也要做。你束手无措，一团乱麻。
场景四：
入职半年后，某次产品会议上市场部同事问起来咱们现在出货的产品算是第几代了，你支支吾吾的说差不多是第二代。老板大摇其头，明明外观都大改了三次，怎么还是第二代？这在市场推广时怎么宣传？
以上场景是不是似曾相识？
不管你是刚入行的小白，还是已工作三五年的精英，应该都能回想起被这些难题所支配的恐惧。
我在决定成为产品经理前，也没有预料到会有这些花样百出的坑在前面等着我。而经历这些困境之后，我渐渐地理解了家人口中“打杂”“背锅”的产品经理，其真正的日常工作是什么，也进而心怀敬畏，脚踏实地，仰望星空。
在这里我希望能把在困境中挣扎学习到的知识，分享给所有正在面临这些困境的人以及所有有需要的人。
1. 场景一：熟悉公司的产品
其实对于你而言，在历经了行业知识的搜集阶段后，应该已经对公司产品有一定了解了，接下来我们要做的，其实就是“把玩”产品实物：
亲自参与产品的生产全过程，先在脑海里建立起印象，理解产品各个部位的组成和功能。
把自己代入到用户视角，了解产品的核心功能，及其能帮助解决你的什么需求。
再把用户感抽离出来，目光放大到整个市场环境，了解市场现状及竞争对手的产品。
形成一份《XXX产品体验报告》，用文字帮助梳理思路，使其条理化，系统化。
对于产品体验报告，我认为应该具备以下几个方面：
2. 场景二：竞争产品分析
我们在撰写用户体验报告的时候已经多多少少接触了行业内较为出名的竞品。而这一阶段要做的是尝试找出产品的迭代点，这是建立在对产品有了一定程度的认知之上的。而产品的优化，除了基于技术优势的创新及率先解决用户的痛点，还可以参照竞争对手的产品。
获得市场认可的硬件产品的每个功能点都有其存在理由，是付出了很大代价以通过市场考验的。
此时成本最低的方法，是以独有的方式在自己的产品上复现竞品的功能点，并力争做到更好。在我看来这就是竞品分析的意义所在。
要做出靠谱的竞品分析，我认为需要经过以下过程：
对于竞品分析报告，以下几个方面对我而言是需要具备的：
值得一提的是，竞品分析之后不是无脑的复制，而应该对这些功能点做出筛选，了解实现其的技术难度和带来的收益，甚至我们可以提出新的功能点以同时实现竞品的多个功能。
同时，竞品也是在不断优化的，我们同样需要对竞品保持跟踪（这又是另外一块需要剖析的方面了）
3. 场景三：需求收集与归纳
我们需要的是一个成体系的记录方案，帮助我们梳理从各个方面不定时不定量涌来的需求，这就是需求池。
对于硬件产品，具体的需求可以进行如下分组：
对于需求的类型，可以从以下几个方面进行理解：
功能：产品本身的功能点，能够解决用户某一方面的需求，包括PCB板卡的功能，设备对外接口等。
结构：这是硬件产品区别于软件产品的一大特点，硬件产品有其物理构造，因此硬件的设计会有工业设计(ID)及结构设计(MD)。ID大多是基于美学的考量，而MD更多涉及到产品能否正常实现其功能，是否好用。
工艺：这是硬件产品的另一大独有特点。结构设计只是模型上概念上的，实物的落地还有很多变数。从图纸到实物到成品，中间经过很多的工序环节，对应的就有机加工工艺，做线工艺及装配工艺等。
测试：这里的测试分两种——产品正常出货的测试及新功能执行前的测试。对于前者，测试能够揭示质量问题，对这些问题进行分析，能找出影响产品质量的因素，进而找到防呆方式避免后续此类问题；对于后者，测试能够验证功能是否可以正常实现，进而帮助团队在设计层面加以改进。
客户体验：这里的客户单指正式购买使用产品的用户。一般而言，体验或者使用产品的可以是不同部门的同事，参观者甚或你自己，但这里我们尤其关注日常使用产品的客户，他们对产品的使用最具发言权。当然，有时候客户也会提出些天马行空的想法，因此对于客户体验一定要加以鉴别。
对需求的来源，可以有以下几种途径：
高层管理：团队直接汇报人、产品总监、大Boss等都算。一般而言，（硬件行业的）高层管理人员都在行业内浸溺多年，他们的眼光和阅历都较为丰富，往往能对产品的设计提出高屋建瓴的建议。
技术建议：包括ID设计、MD设计、硬件工程师、嵌入式工程师等技术人员。大家往往都能从其专业性角度提出较为深入的建议。但如何将各方面的意见与建议统筹起来，并根据实际项目进度予以协调非常考验功力。
生产反馈：属于硬件产品独有的需求来源途径。之前说过硬件产品实物的落地需要经过机加工、做线及装配等工序，（结构）设计层面的优劣在这一环节体现的淋漓尽致。好的产品不独使用起来方便有效，其生产制造环节也可以较为高效——即“Design for Manufacturing”。生产反馈的来源可以是生产部主管，如果是ODM/OEM的话也可以是生产对接人（大部分时候是项目经理或产品经理）。
用户反馈：可以是用户直接反馈或市场部代为收集。若想获得用户直接反馈的需求，就需要深入产品使用第一线，倾听客户在说什么，了解他们实际使用产品的环境；而市场部代为收集的需求，很多时候就是被转述的第二手信息，其正确性和专业性要打一个折扣。
对需求的状态，只可以有以下三种：
1）拒绝：产品经理经分析后觉得没必要做或不可能实现的需求，或者产品经理没法判断转而召开需求评审会，经过判断认为不适合做的需求需要明确予以拒绝。同时需要备注好拒绝原因，并向相关干系人予以解释。
2）开发：所有未被拒绝的需求均需纳入开发状态。当然，对于待开发的需求需要理清轻重缓急，建议使用“重要性-紧急性评估法”进行评估——即对某项需求的重要性及紧急性进行1/2/3评分，再将重要性乘以紧急性，对得到的乘积进行排序，乘积越大约优先执行；乘积相同的话，以紧急性评分进行排序；紧急性评分相同的话，以其商业价值进行评分（即哪一项执行后的获利，主观性较大）。
3）完成：开发完成的需求要及时予以状态确认，并将需求的最终执行结果和效果记录下来。
对需求做好分类之后，就可以初步构建我们的产品需求池了，这需要我们持续性的加以维护。要培养勤做会议纪要的能力，也要养成随时随地记录需求的好习惯。
因为你会发现需求的汇集途径太多了，有口头通知，会议提出，邮件提出，甚至还有微信（群）提出等。如果我们没有养成勤做记录的习惯，就很容易锅从天降。
4.场景四：产品迭代
随着需求池的构建，产品就会处于一个较为稳定的迭代过程，这个时候要记得做好产品的迭代记录。
产品的版本迭代应该有一定的节奏，我认为以下标准达到其中之一即可进行：
硬件架构的更新换代
外观的更新换代
以上原因引发的产品迭代，应该算是迭代了一个大版（如V1.5到V2.0）。相对应的，如果仅是增添了某个功能点，或者为满足不同行业的客户需求定制了某些产品子类（调整了部分功能点的有无，主体结构没有变动），应该算是迭代了一个小版（如V1.4到V1.5）。
六、硬件基础知识
与我而言，硬件基础知识分为三大版块：结构相关、电子相关、生产相关。
1. 结构相关基础知识
我在这里把结构相关的知识划分为两大部分：
工业设计( Industrial Design, ID)：主要是从外观的角度，实现美感的塑造，帮助产品塑造品牌形象。
结构设计(Mechanical Design, MD)：主要是从材料及工艺的角度，实现产品外观的落地，帮助产品实现其预定功能。
为实现这一块儿的知识架构搭建，我采用了MD为主，ID为辅的学习思路：
1）了解材料的相关特性及成型工艺
一般智能硬件的产品，其材料主要是塑料及金属两大类：
塑料材料包括：PVE、亚克力、尼龙等，其主要特性是密度小、易塑形、造价相对较低。（在这里推荐大家阅读化学工业出版社出版的《塑料品种与选用》）
金属材料主要指：合金类，如密度小强度较高的铝合金，密度大但有自润滑性的黄铜等。（推荐大家阅读机械工业出版社出版的《金属材料常识普及读本》）
2）了解产品的空间特性对功能的影响
这里所说的空间特性，指空间位置、电磁抗干扰性和散热性等。
空间位置是指：一些电线、扎带、卡线贴等不会在设计三维图里显示的小组件，从美观和便于生产的角度考虑，在走线时会收纳在产品壳体的角落内。所以，产品在设计时，除了必要的功能组件（PCB、电源、传感器等），还需要根据实际预留一定的空间位置。
电磁干扰是指：降低信号完好性并干扰电缆信号的电子噪音，分为传导干扰与辐射干扰两种。为避免传导干扰，系统内强电和弱电的区域就要隔开；为避免辐射干扰，可在高频信号区域添加金属屏蔽罩。
散热性：PCB板卡上的CPU、FPGA、DSP等芯片发热量比较大，为避免影响系统的正常工作，需要将这些热量快速散发出去。一般使用强制散热的方式进行处理，散热效率高，散热快（与之对应的就是自然散热，效率低速度慢）。可用的方法有加装散热块、风扇强制换风、热管导热等，这在设计之初就要加以考虑。
3）实操产品的三维建模
三维建模是利用软件将设计者的理念形成数字化实体，以方便验证的过程。
市面上通用UG、ProE这些软件（我习惯于使用Solidedge）绘制各组件的零件图，再组装成装配图。我在此前经验的基础上，尝试在工作中承担部分简单组件的制图，这也进一步加深了我对建模的了解。
4）实际跟进产品的落地
这一步我又称其为“实体化”，当模型验证合格后，需要实际制造出来，设计者会提供三维或二维图纸给到工厂，根据材料及加工工艺的不同，以一定的周期生产出来。
没有哪家公司具备全产业链，所以多数加工会发外协。跟进产品落地的过程，实际上也是加深学习的过程。
对于机加工件，不复杂的铝制零件一般两天就可以做完（包括备料，上机，加工，检验整个过程）。零件若需进行后处理如表面阳极氧化，发黑等又会需要额外时间。
对于塑料件，若有现成模具和塑料颗粒，不复杂的小零件一天就可以生产成百上千个出来。如果没有模具（有金属模、失蜡模等），则开模的周期可能会长达1个月或更久，成本则数以万计。因此，设计时可尽量考虑市场上现成的零件。
5）培养自己的审美水平和产品感
我认为在对材料有一定了解的基础上，才可以对产品的外观、材质、手感、颜色配搭提出较为靠谱的建议。
除此之外，我们平时也要注意提升自己的审美水平，这方面没什么一蹴而就的方法。
我的建议就是：让自己变得敏感起来，多看竞品的整体设计，多学习优质的PPT版面设计（研究其配色和风格），生活中发现美的地方就及时记录下来。
我经常使用几款很美的App，色卡、形色和Cuto，推荐给大家：
2. 电子相关基础知识
电子相关知识包罗万象，涉及面非常广。我从自己日常工作有所接触的角度将其划分如下：
基础知识：技术方面主要是通信知识（通信和网络）；器件方面主要是各种传感器/接口/电池和电源/存储器/处理器等。
PCB相关知识：PCB板卡的设计，PCB光板的生产及贴片生产三大部分。
FPGA相关知识：严格来说FPGA也应归类到基础知识内，只是因其承担了非常核心的作用，需要单独拿出来学习。
为综合如此深广的知识，形成一定的知识架构（当然可扩展可延伸的地方还太多太多），我主要做了以下努力：
1）工作中积累器件方面的知识
项目开展时可向硬件工程师了解各种器件的特性；闲暇时可找到器件官网或供应商，索取产品手册，详细了解产品功能（作为产品经理，可以不会画板子，但需要了解各器件的功能）.
2）以考代学积累网络方面的知识
所谓以考代学，就是通过备考“全国通信专业技术人员职业水平考试”，阅读《通信专业综合能力》和《通信专业实务》等专业书籍，快速全面掌握重点知识.
3）配合硬件工程师设计PCB板卡
作为硬件产品经理，我会在收集完所有需求后，将其细化为具体规格，并协调配合硬件开发工程师一起给出产品总体设计方案，主要是确认整个系统的硬件架构，并按照功能来划分各个模块。
4）配合硬件工程师将PCB板卡落地
PCB板卡绘制完成后会有一个交叉评审，评审通过后硬件工程师会生成生产所必须的文件。当你经过数轮完整的PCB设计到生产的流程，就会对过程中的要点有一定的了解了。
生产所需文件包括Gerber文件夹（内含Top顶部信号层、Bottom底部信号层、Silk丝印层、SMK阻焊层、Paste锡膏层等文件），钻孔文件（.drl后缀），贴片坐标文件（.txt和.xls后缀）以及物料清单BOM。
将这些文件做好分类给到PCB光板供应商（如嘉立创），钢网供应商和SMT贴片供应商。
PCB板卡上除能够上机贴片的元件，还有一些插件是需要焊工手动焊接上去的。要做好插件的配料，并将这些物料的位号标注好，方便焊工工作。
3. 生产相关基础知识
这里所说的生产，是指在原材料均准备就绪的情况下相关的装配和测试工作。
实际生产中，往往还会涉及到的配料、PFMEA过程失效、精益生产等流程或方法，此处暂不涉及。
相关的知识架构图如下所示：
基于此前在生产线上的经历，我主要使用“串联法”将生产中涉及到的“人、机、料、法、环”五大因素纳入自己的知识体系：
1）向一线装配员工请教装配知识，了解其装配诉求。
这里的装配诉求，除了工作环境及辅助生产的工量夹具等，还有很多对设计改进很有帮助的信息。
举个例子：为使导光柱安装稳固，需要打上硅橡胶，在导光孔很多的情况下，挨个安装导光柱非常耗时。这个时候就可以提醒设计者将导光柱设计成连体式，一次打胶一次安装完成。
当然这里还涉及到成本的问题，单个导光柱往往市面上很容易买到，连体式导光柱则需要开模定制，两者价格相差很大。这就需要产品经理做成权衡——即更改设计带来的收益能否弥补前期的投入，这是一个很有意思的话题，以后再聊。
2）向焊线员工请教焊接及做线知识。
贴片后的PCB板卡，有时还需焊接上接插件；设备对外接口与PCB板卡之间连接的供电线缆、数据线缆的备线与焊接等等，均需焊线员操作，产品的质量就隐藏在这些小小的细节里面。焊线员的经验很重要，其所依照的线序文件等也非常关键。
3）向工艺员请教工艺知识。
为使生产快捷出错率低，产品质量保持一致性，常常需要SOP工艺文件。
它包括：物料处理程序、线序文件、生产操作程序、质量控制程序等，一般由工艺员编织。
一份好的想法，不一定能有好的设计；一份好的设计，不一定能很好落地；一份很好落地的产品，不一定能得到很好的执行。在这里，SOP工艺文件就是帮助我们将产品的落地很好的执行起来。影响产品外观、质量、客户体验的大量的工艺知识就隐藏在SOP文件里。
4）向质检员请教检测知识。
什么样的产品才能认定合格？来料物料应该如何检查才能大概率避免不良品影响生产进度？设计的更改是否有效，又是否对其他组件产生了干扰？
质检员深深影响了我们的售后工作，是“抓大放小”还是“不达标准绝不流出”，公司对产品质量的理念也决定的了这家公司是生产不用的产品，能用的产品还是好用的产品。
七、软件基础知识
我目前所在的公司，是一家卫通行业声誉斐然的独角兽企业，技术积累雄厚，产品推广渠道深广，涉及到的产品种类很多。
就我所处部门而言，平日里经常接触到的涉及到软件部分的产品主要有两大类：其一是硬件产品内的嵌入式软件；另一类是网络管理系统软件。
因为非计算机相关专业出身，此前我在与相关研发伙伴交流时遇到过一些障碍，主要还是集中在相关专业知识上。当我提出一个需求时，往往因为表述不明确而造成误解，更有甚者会被忽悠的团团转。研发小伙伴们的做法也不能说错，只是在面对一个不懂技术的产品经理时耐心很容易消耗掉罢了。
为改善这种境遇，我主要做了两件事：读书和考试。听起来大家可能会失望：“读书和考试谁不会啊？大家都是社会人了，更快捷的办法有没有？”。我的答案是：“至少我没有。”对我而言，这种见效最慢的办法，恰恰是效果最好的办法。
此前我也尝试过一有问题就去请教，次数少没关系，次数多起来一方面耽误研发小伙伴的工作进度，另一方面无形中也降低了你的可信度（“你怎么连这都不会呀？”）。
那是不是说（智能）硬件产品经理就要像软件开发人员那样，学习计算机相关专业所有书籍（四年甚或七年）呢？
我的建议是：最好不要。
一方面没有精力与时间，众所周知产品经理的工作很是碎片化，连在周末周日想要匀一整块学习时间出来都比较难；另一方面没有那个必要，我们的目的不是转行成为一个软件开发工程师，而是要高效的与软件开发的同事进行交流。
在最开始自学的时候我其实就犯过类似错误，比如：尝试完全掌握一门语言（我的选择是Python），后来发现一个完整的软件设计中的不同开发阶段，大家所用的语言甚至都不尽相同。
在走过一段弯路之后，我逐渐体悟到一个道理：我不需要关心你具体是如何实现产品的，我关心你做出来的产品所遵循的逻辑结构是否正确，呈现的效果是否能够满足我的需求。
在这里，为了提高自己的学习效率，使对编程相关技术的学习过程不至太过枯燥乏味而放弃，我从市面上一大堆相关书籍中淘到了两本书：《大话数据结构》和《大话设计模式》。
这两本书都来自于同一个作者——程杰，两本书的侧重点不同，但都帮助我建立了一个与研发小伙伴交流的知识基础。
另外，硬件项目与软件项目的大致流程是相同的，但具体到相关过程上又有很大的区别。
因此，我在硬件项目上的经验不能完全套用进软件开发项目。为了更好的参与软件开发项目的过程，我了解到一门职称考试——“全国计算机技术与软件专业技术资格（水平）考试”，俗称“软考”。软考分中级和高级，高级考试中的某一门，其教材《信息系统项目管理师教程》非常有用，建议大家看看。
目前我还没有能力建立起一个硬件产品经理应该具备的软件知识架构，只能把我的学习方法推荐给大家，勿怪。
1. 数据结构与算法
《大话数据结构》，是一本定位于读者自学的书籍，区别于教材形式，这本书能够让初学者“独自”全盘掌握知识。
它通过趣味引导的方式，用一些小故事小题目等形式作为文章开头，引导大家从较熟悉的知识开始学习；同时图文并茂和代码详解并存，一方面让我对算法知识了解的更深刻；另一方面减少了我在学习过程中的挫败感（按照给出的代码示例，我就能够正确运行，这是很重要的）。
下面是我在阅读这本书之后的部分学习笔记：
2. 面对对象的编程方法
《大话设计模式》，同样定位于读者自学，其最大的特色就是重视过程，贴近生活。
这本书能够给出问题的解决方案或程序样例的详细的演变过程（通过描述小菜鸟与大鸟之间的对话），这就变相的降低了学习门槛；另一方面也通过描述生活工作中常见的场景，来引入面对对象进行编程设计的23个设计模式，趣味性十足，学习过程没那么枯燥了。
下面是我在阅读这本书之后的部分学习笔记：
3. 信息系统的规划与管理
这门课我正在学习中，我将其划分成四大部分：基础知识、项目管理理论与方法、项目管理理论与方法-文档相关、综合管理。每个部分都有非常细致的内容可以说，我后期将不定期更新笔记。
下面是我对这么课划分的知识体系，大家可以参考着一起学：
八、不忘初心
啰啰嗦嗦说了那么多，其实也还没有将硬件产品经理解决问题时所应具备的知识基础覆盖完整。其实大家也能看出来，选择了硬件产品经理这条路，就是让你的知识域向“广”的方向发展，而很难再具备深耕某方面知识的条件。
做一款好的产品不易，成为一名优秀的硬件产品经理同样不易。这份升级攻略请你收下，若你有兴趣一起走，我们将携手并肩；若无人相伴，我亦将砥砺前行。
路漫漫。
原标题：我的PM进阶之路：硬件产品经理如何构建自己的知识架构？
本文由 @Smile（微信号：smile7853）原创授权发布于爱盈利。未经许可，禁止转载。
【投稿人原创】 本文由投稿人原创发布于爱盈利，未经投稿人许可，禁止转载。如有侵权联系:8088013@qq.com
