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