精华内容
下载资源
问答
  • 智能硬件产品经理手册

    千次阅读 2019-03-11 21:30:38
    智能硬件产品经理手册 为了帮助新从事智能硬件的产品尽快的熟悉智能硬件部产品流程,掌握各种数据,平台工具的使用方法,以及提高产品设计能力。特以智能硬件产品经历为例制定适合转型到智能一到三年的PM/PD工作...

    智能硬件产品经理手册

    为了帮助新从事智能硬件的产品尽快的熟悉智能硬件部产品流程,掌握各种数据,平台工具的使用方法,以及提高产品设计能力。特以智能硬件产品经历为例制定适合转型到智能一到三年的PM/PD工作手册,方便新工作。

    概述

    智能硬件PM/PD手册包括:有调研方法与工具,Feature List,Demo,MRD,如何进行UE,商务,技术,需求沟通,会议纪要,邮件记录,项目流程等内容。

    1.1目的

    制定本手册的目的是使刚到智能硬件的PM/PD更详细的了解,智能硬件产品设计的相关工作流程和细节,从而加强PM/PD的专业性。提高产品设计和把握项目的能力,更快的进入智能硬件工作。

    1.2目标

    • 熟悉各类平台和工具的使用方法
    • 掌握产品栏目调研和需求分析的方法
    • 熟悉项目流程和提高细节执行的能力

    1.3适用范围

    所有智能硬件入职不久的PM/PD同学。

    2.需求阶段

    通过对智能硬件用户需求调研,分析核心需求点,明确产品方向,功能点,输出demo,与组内分享并确认产品feature list,和demo,启动项目kickoff,输出对应的UE需求以及资源需求,撰写PRD,需求准备完成后进行产品评审以及技术评审。

    2.1需求调研

    具体内容:用户需求调研得出用户需求点。

    注意事项:

    • 明确调研对象和目标;
    • 清晰规范的调研大纲;
    • 有说服力的数据支持;
    • 准确合理的调研结论。

    对应产出:调研报告

    2.2 Feature list及demo

    具体内容:根据调研结论输出产品功能列表及产品demo图。

    Feature:即产品功能点列表,对应覆盖的需求点,及该功能点优先级。

    Demo图:

    即系产品页面线框图,原型图,可用axure、visio、PS、fireworks等任意擅长的工具,去完整的表达出产品各个模块的功能位置,以及所有交互行为,可保证UE同学利用DEMO设计出完整的页面效果图,技术同学可利用demo开发出完整的功能。

    文案要尽可能接近真实,强化及弱化的功能点表达清楚,web/app端产品,尽可能按照页面实际图片元素的比例,进行示范。

    对应产出:feature list,demo图。

    Featurelist 示例:

    Demo图示例:

    2.3调研分享

    具体内容:分享调研内容,收集建议,确认feature及DEMO

    对应产出:会议纪要

    会议纪要组注意事项:主要包括时间,地点,人物,会议议题,讨论内容,会议结论,确定问题, 遗留问题。后续计划及跟进人等

    会议纪要范例:

    2.4Kick off

    具体内容:

    • 确认技术人员技术接口人,统一安排
    • 启动项目,根据资源引入成本,技术成本,等因素讨论,并最终确定项目feature

    特殊说明:并非所有项目均需进行,启动大型项目或重要并完整的新项目时进行kickoff.

    对应产出:会议纪要,确认PM、FE、RD、QA对应负责人,明确接口人,技术人员对应一个PM接口人。

    2.5资源引入

    具体内容:商务合作需求,商务接口人

    提出方式:邮件方式详细描述资源需求,

    资源需求要点

    • 项目背景,
    • 具体资源需求。
    • 有无指定合作方,
    • 相关产品及技术接口人,
    • 资源到位的期望时间,

    对应产出:需求邮件及资源到位的情况。

    2.6,UE效果图

    具体内容:提请UE需求——UE接口人。

    提出方式:邮件方式,将详细描述UE需求发出,附Demo图,若需交互设计师执行交互设计,请与交互设计师优选沟通,完成交互设计设计稿后交付视觉设计师执行。

    UE需求要点:

    • 项目背景;
    • UE需求点,(包括文案);
    • 线框图即可,避免影响UE设计发挥空间;
    • 期望时间;

    UE需求沟通:

    • 新人第一次沟通需求需指导人示范,要点详尽描述;
    • 第二次沟通时,需新人主导,指导人旁观把控;
    • 提出组内确定后的需求,避免频繁更改;
    • 需求描述时告知预计效果,而不是告诉我要什么;

    对应产出:邮件需求及UE效果图交互设计图。

    2.7 PRD撰写

    具体内容:输出产品详细需求文档,清晰描述产品功能逻辑,策略及统计需求。

    对应产出:PRD,最终版本需上文档保管中心对应所立项目。

    2.7.1,PRD定位

    PRD受众:FE/RD/QA等。

    PRD重点,需求的定义,而不是需求的实现。

    2.7.2,清晰的结构

    适当拆分:例如大型栏目,进行复杂功能改版,复杂产品管理后台的。

    提供完整的流程:文字概述,流程图。

    利用目录控制大局:目录不宜太细,且提供,链接指向相应页面,各级目录编号不建议使用:一、1、(1),推荐使用1、1.1、1.1.1。

    突出重点:需要强调的内容,都用粗体,或不同的颜色标出,必要时使用截图,尽量用流程图,列表,对比等形式展现,避免大量文字模糊不清。

    2.7.3合理的顺序

    根据用户的使用流程进行描述:适用于新的产品,入口-使用-退出。

    根据功能的依赖关系:适用于产品的新功能,新升级,使用文字开锁或流程图。

    使用表格和截图:对同类信息适当使用表格归纳,对承载很多功能的页面应使用截图帮助理解。

    2.7.4完整的细节

    • 分清主干与分支,提醒合理的优化描述。
    • 各种情况下的假定。

    用户状态的记录策略,如切换TAB,下次进入是否为其记录上次状态,这里特殊字符的限制,比如:定宽式样设计的字数上限。

    各种错误的提示信息:所以PRD给出各种预期到的错误,详细错误号,及对应信息可由RD提供列表。

    对其他产品的依赖及影响:是否需要其他产品提供支持或对其他产品构成影响。

    2.7.5严谨的措辞

    不使用含糊词句:

    • 形容词,例如非常、及其。
    • 含糊不清,例如可能大概也许等。

    不要和其他产品类比:例如:同开放平台改版保持一致等。

    预期到会变动的地方需明确指出:预计后期升级的困难,帮助技术设计时考虑到可扩展性。

    字数类描述:使用字节,不要使用字(防止理解不同、可用字进行补充说明)。

    必要的备注说明:提示信息必须明确真实文案,与需求描述文字区别显示。

    2.7.6变更需求

    技术评审前:变更需求需要有版本记录,需要随版本号给出日期,各版本的修改内容,提供各版本PRD撰写人。

    PRD修改记录示例:

    技术评审后:

    原则上不允许随意变更需求,除非有重大失误或影响用户体验方面可以变更需求,变更需求需要获得指导人确认后,召集项目相关同学沟通变更内容,口头达成一致后更新PRD,对应变更内容,需以批注形式标注。上传文档保存处,邮件通知项目相关同学PRD已更新及更新内容。

    2.8产品评审

    具体内容:PM内部讨论及确定PRD及UE图。

    争议处理:产品凭内部评审过程中,如遇到意见分歧的情况,可通过如下几个方法进行处理,用准确的数据说话,必要时可进行AB测试,线上尝试。

    注意事项:欢迎提出不同的建议和意见,内部评审务必达成产品需求内部一致,但是需要发在产品内部群或者产品内部会中,避免到技术评审后在公共群及公共会议室PM/PD组内才发表不同意见,影响PM专业度,或者技术误认为产品内部没有达成一致就提出开发需求。

    对应产出:会议纪要修改后的PRD既有意图。

    2.9技术评审

    具体内容:与负责项目的技术人员进行技术评审,评估实现难度,问题以及风险点。

    评审准备

    • 用于评审的PRD及效果图务必是产品内部确认后的版本。
    • 至少提前一天发图片的及效果图,给参与评审的同学充分的熟悉内容时间,评审需在会议室进行,尽量避免在休息区进行,提前发出会议邀请。
    • 提前五分钟,到达会场,准备好投影等相关设备。

    对应产出:

    • 会议纪要,通报修改点。
    • 修改确认的PRD及效果图,并上传至文档保管处。
    • 跟进技术排期。

    3开发阶段

    3.1立项

    具体内容:评审通过后,项目负责人立项,项目正式开始启动,进入开发阶段。

    对应产出:需求分析邮件,排期。

    3.2跟进开发

    具体内容:PM/PD跟进前后端开发进度,处理开发中遇到的问题,如需求有调整和改动,需及时更新加的。推进项目顺利进行。

    注意事项:开发过程中尽量避免修改需求,如遇重大问题,需要修改,见2.7.6变更需求部分操作。

    对应产出:前后端开发顺利完成,如修改需求,更新PRD邮件通知。

    四,测试阶段

    4.1配置数据

    具体内容:配置现场真实数据,需要人工配置的具体的数据内容。

    操作步骤:如配置推荐数据需提前向市场运营组提出需求。

    对应产出:线上真实数据,达到上线数据要求,邮件记录通报。

    4.2效果确认

    具体内容:PM,UE,对前后端开发效果进行确认反馈问题及时修复调整,使之达到预期效果可上线状态。

    注意事项:

    • 第一轮提测时发出测试版本供PM,UE确认样式和页面功能及时修改。
    • 最后一轮提测时,发测试版本。PM、UE再次确认,此时不影响功能的小问题,可先行上线后续修改,避免人员反复修改。
    • 新人第一次上线项目确认效果,由指导人把关,积累一定经验后客,自己掌握效果,确认无误后务必发出去的邮件。

    效果确认点:PM确认产品功能及页面,UE确认,页面设计及交互效果。

    对应产出:修复问题,PM、UE邮件记录。

    4.3内测组投放

    具体内容:QA投放公测版本。到荣誉内测组,跟进内测组用户,反馈的问题和建议,推动完成bug修复,收集到的用户建议转化为相关需求,作为后续迭代计划。

    对应产出:邮件记录,需求收集整理录入到文档管理的产品需求池,产品视图-spark需求管理。

    4.4BUG修复

    具体内容:跟进QA发出的测试问题,推动完成BUG修复。

    对应产出:测试报告。

    五 上线阶段

    5.1上线通报

    具体内容:上线前一周或更早时间,邮件通报版本上线公告介绍上线发布内容。

    通告形式:release notes+功能介绍。

    具体操作:

    邮件通报项目组相关人员,及公司全组release notes+功能介绍,release notes尽量简明扼要,列举出版本发布的新功能及优化功能点,并附上相关的功能截图介绍。

    对应产出:邮件记录官网应用升级提示,release notes。

    示例:

    5.2效果回归

    具体内容:

    PM QA等对线上效果进行再次确认,如有必要请UE同学,确认页面及功能模块的设计实现完成度与UI问题。

    针对QA测试的BUGLIST,PM需要确认debug的优先级,建议如下:

    • 原则上,开发项目中的所有bug,在项目时间允许的条件下都要完成debug;
    • 若版本持续迭代更新,严重影响用户体验的导致功能缺失,影响产品可用性的bug必须在产品上线前解决;
    • UI问题以及产品中用户直观可见的BUG视影响产品可用性的严重程度,进行针对性解决;
    • 优先级稍低的bug。可放在后续版本计划中review优先级,加入到debug计划;

    对应产出:bug review 会议召集、邮件记录输出。

    5.3小流量因素,(投放内侧组)or A/Btests

    具体内容:

    选择部分用户或者终端进行升级,进行小流量引流,投放内测组,效果,观测,平稳过渡,若有需要进行ABCtest,则进行部分用户小流量上线验证。

    • 小流量引入的好处:新功能有待验证,避免用户大幅度反弹,降低风险。
    • 适用于A/B test的情况,在不确定两种设计方案的前提下,将两种方案分别投放到随机用户中进行测试,对两种用户数据进行对比,从而为方案选型提供决策参考。

    当然,无论是小流量引入还是A/B test,都只是手段。PM同时更应该注重数据和用户需求的研究与分析,利于各种简单有效的手段进行验证测试,避免产品功能风险。

    另外,a /bbeat需要有足够的UV样本量. A/Btests核心是分流,如果样本量太少,有可能会被偶然因素影响,对结果判断会有干扰。

    5.4开放正式入口

    具体内容:

    • 首页、产品模块对应的分类推荐,相应的分类入口展现。
    • 通知研发人员开放入口,协调市场运营在首页推荐位进行推荐,并邮件同步给相关人员。
    • 对入口的点击效果进行跟踪,同步点击数据。

    方式:提前通过邮件申请首页推荐位入口和周期,经和市场运营团队协商一致后,有运营进行操作。

    对应产出:邮件通知入口开放,效果数据同步。

    6运营阶段

    6.1效果评估

    具体内容:开放入口数据统计稳定后,累计两周左右数据后,进行对比分析,给出线上,后续迭代计划。

    对应产出:效果评估报告、邮件发出。

    效果评估示例:

    6.2项目总结

    具体内容:对于流程周期较长的项目进行项目总结,主要对项目中自己或其他角色做得好和不好的地方,以及后续改进方法进行总体阐述。

    对应产出:项目总结报告邮件发出。

    6.3运营推广

    具体内容:

    • 产品相关的设计物料,产品亮点,FAQ等;
    • 媒体网站,用户BBS,微博,微信等用户渠道的推广,广告,软文;
    • 数据收集及分析,针对推广效果,做评估;
    • 新的渠道引入,留住新用户;
    • 相关运营工作活动专题等。

    对应产出:PV/UV/VV使用时长等关键指标上持续优化。

    6.4持续优化

    具体内容:产品持续优化,迭代。

    对应产出:迭代计划。

    7.总结

    本篇列举了一个日活千万的智能硬件平台软件部分的生产流程,可有效地帮助从事智能硬件的产品人员,产品策略能力的快速提高。

    当然快速提高的前提是基础扎实,产品的基础工作是不经一番彻骨寒,岂得梅花扑鼻香,成功走出来的产品几乎是砥砺过开发、实践过营运、更是经历过市场用户的检验,这种经历也许痛、也许苦,但最终一定会使产品的思想更丰盈

    展开全文
  •  智能家居产品,其设计、研发、生产过程的苦逼...智能家居产品同样属于智能硬件的范畴,那么究竟做智能硬件产品经理与做互联网的有什么不同?知乎上的忘象Van,以其曾在互联网公司和智能硬件公司任产品经理的经历,
    原文地址:http://www.qianjia.com/html/2015-03/09_245544.html

     智能家居产品,其设计、研发、生产过程的苦逼,相信在行业中的伙伴都深有体会,而其中体会最深的莫过于被称为“产品汪”的产品经理。智能家居产品同样属于智能硬件的范畴,那么究竟做智能硬件产品经理与做互联网的有什么不同?知乎上的忘象Van,以其曾在互联网公司和智能硬件公司任产品经理的经历,从定位、KPI考核、关注点、项目追求和成本意识的五个差别,为我们做出了详细的解答。

      我做过手机PM,也做过互联网PM,感觉这个问题就是为我量身定做的。所有的区别都可以用一句话概括——硬件PM是生意人,互联网PM是设计师。

      产品经理是近年来严重泛滥的一个词,而且由于互联网行业的强盛,导致大家对这个岗位的认知完全变成了互联网公司里面每天用Axure推敲原型,并成天和研发、设计纠缠的那个人。

      

     

      但实际上在互联网还没那么如日中天的“上古时代”,产品经理这个岗位就已经存在很久了。

      在我做手机(07年前)的时候,还是功能手机、以及WM/塞班/UIQ等前智能系统的时代,软件系统还不是主要竞争力。整个产品以外观、功能为主打,一款产品从策划到发布的过程一般是这样的:

      ▌做方案:

      1. 研究市场需求

      2. 出MRD,定义市场需求(定目标人群、定卖点、定关键特性、定价)

      3. 和ID(工业设计)团队一起出方案,出效果图

      4. 拿方案在内部评审可行性,直到比较有把握

      5. ID开始设计和打样,做Mockup

      6. 做市场调查,找用户提提意见

      7. 拿方案去对客户宣讲,看看客户的反馈(一般是合作过的老客户,比如运营商、渠道商;新客户都是拿成品去拓展的)

      8. 根据市场调研反馈修改设计

      ▌研发和生产阶段:

      1. ID团队出正式的方案(中间需要反复修改设计、去喷漆厂调色、做高保真Mockup)

      2. MD(结构设计)出结构方案

      3. 硬件出硬件方案

      5. MD和硬件一起选购元器件,定BOM

      6. 软件研发软件方案

      7. 开模,需多次修模

      8. 量产

      比较互联网PM和硬件PM的主要区别:

      

     

      ▌定位不同:领班 VS 参谋

      在上图中已经能看出来,互联网团队通常采用扁平化管理,产品、设计、研发、运营都是彼此协作的职能团队,职位高低上并无不同。由于团队中一般不专设项目经理,就把PM抓来同时兼任。由于这种“项目经理”并无分配资源的“实权”,又必须推动项目实施,所以“产品汪”天天跪舔“攻城狮”就一点都不奇怪了。

      而硬件团队中职能团队要广的多,老板难以掌控所有的工作,所以必须专设两类助手——产品经理(找业务方向)和项目经理(推动项目执行)。

      尽管PM也没有管人的“实权”,但因为身背业绩,所以在业务的发言权要大很多——比如例会上,一般是老板坐镇,所有团队负责人参与,然后产品经理和项目经理轮流汇报工作。在这个过程中,任何问题都可能被提出来,由对应职能部门负责人解释。一旦被被挑战,压力非常大。

      通过这种狐假虎威的问责机制,加上PM不直接出详细设计PRD(设计方案由ID出),因此PM和职能团队整天扯皮的情况要少很多。

      ▌KPI不同:用户考核 VS 收入考核

      互联网产品一般不向用户收费,很多产品在上线多年后都不能变现,用收入考核产品经理根本不现实。所以产品经理一般是与运营一起背用户增长、流量等。

      而硬件产品没有互联网那么多眼花缭乱的商业模式。无论市场眼光准不准、方案完成度高不高、产品有没有竞争力、情怀能不能打动人,最终都体现在一件事上——能不能把东西卖掉并赚到钱!

      所以硬件PM的KPI非常简单粗暴,就是收入和利润是否达标。

      ▌关注点不同:用户体验 VS 商业价值

      不同的KPI导向,导致两种PM的关注点也有很大区别。

      互联网PM更关注完整的用户体验,对用户心理的揣摩更细腻,比如用切换卡导航还是抽屉导航,用图标按钮还是文字链等等。

      而硬件PM虽然也关注用户体验,但更需要衡量每一点改善的投入产出比,如果不能带来销量的提升就尽可能砍掉。比如我从来没见过哪个传统电视机厂家把遥控器做的好用一些,因为这对销售帮助极小。

      总的来说,互联网PM更像设计师,眼中的产品是一件作品;而硬件PM更像生意人,眼中的产品是一桩生意。

      闲话一句:腾讯的PM业界一流,但创业有影响的比阿里少的多。也许是因为腾讯的PM更专注于设计,而不像阿里人天天看的都是生意吧?(猜的,别打脸)

      ▌项目追求不同:快速上线 VS 高完成度

      互联网常常拉一拨人几个月就上线顺便公测,效果不错就加大投入,效果不佳就赶紧换方向或砍掉。上线后就算有严重BUG,也不算事儿,有问题下一版升级就好了。

      而发布硬件产品,则需要从市场到设计、研发、生产、销售、售后全部团队的重度参与,一旦量产就不能容许有严重BUG。所以在立项起各阶段的检查就需要极为严格,在方案达标后必须及时关闭迭代,保证产品的高完成度。

      总的来说,互联网产品试错成本很低,可以小步快跑,随时掉头;而硬件产品试错成本很高,必须谨慎计划,严肃执行。

      ▌成本意识不同:不太关注成本 VS 非常关注成本

      互联网产品,一般初期投入成本很低(只有一些人力投入),用户增长的边际成本也极低。所以互联网PM基本不太需要考虑成本,更关心如何吸引用户。

      而由于每件硬件产品最终都是一笔交易,所以控制成本就极为重要。因此从元器件采购到确定BOM都需要PM深度参与,当然专业意见还是技术部门出,订货过程由项目经理跟。

      所以对配置斤斤计较,是硬件PM的职业病。

    千家网微信公众平台:

          搜索“千家网”或扫描下面的二维码,关注千家网微信,开启新闻资讯新旅程!


    展开全文
  • 最近在混智能硬件产品经理圈,一直在思考,产品的种类很多,硬件类的产品经理跟纯APP的区别主要在哪里呢?我想我们这里很多的各种类别的产品经理,大家都来说说,自己思维里,各种产品的差别跟主要能力?

    最近在混智能硬件的产品经理圈,一直在思考,产品的种类很多,硬件类的产品经理跟纯APP的区别主要在哪里呢?我想我们这里很多的各种类别的产品经理,大家都来说说,自己思维里,各种产品的差别跟主要能力?

    以下是来自@郭斌的回答:

    这个问题问的很好,现在大家最熟知的应该就是APP产品经理了,因为做app的公司太多了,但是产品经理还有很多种,数据产品经理、后台产品经理、硬件产品经理等等,当然懂UI懂设计的前端APP产品经理应该是目前需求最大,也最受欢迎的一类。 

    那么回到问题本身,智能硬件产品经理和纯APP的产品经理,到底主要区别在哪里呢? 

    首先,我们要了解什么叫智能硬件? 

    智能硬件,百度百科的解释如下: 

    智能硬件是继智能手机之后的一个科技概念,通过软硬件结合的方式,对传统设备进行改造,进而让其拥有智能化的功能。智能化之后,硬件具备连接的能力,实现互联网服务的加载,形成“云+端”的典型架构,具备了大数据等附加价值。 改造对象可能是电子设备,例如手表、电视和其他电器;也可能是以前没有电子化的设备,例如门锁、茶杯、汽车甚至房子。 

    智能硬件已经从可穿戴设备延伸到智能电视、智能家居、智能汽车、医疗健康、智能玩具、机器人等领域。比较典型的智能硬件包括Google Glass、三星Gear、FitBit、麦开水杯、咕咚手环、Tesla、乐视电视等。 

    因此智能硬件产品经理与传统的纯APP产品经理至少有以下区别: 

    1、知识结构的差异,智能硬件产品经理应该具备更深厚的技术背景 

    现在会玩APP的人太多了,基本所有智能手机用户都是app的使用者,那么app产品经理更多的是要玩过至少100款以上app并深入研究,对用户体验和视觉设计有自己的理解,懂互联网运作,了解一些安卓和ios的开发知识,最好是计算机专业毕业。而智能硬件产品经理除了要了解APP的相关知识外,还需要懂通讯协议、智能解决方案设计、硬件基本常识,最好是之前有过传统通讯和家电方面的工作经历。 

    2、行业背景要求也有差异 

    智能硬件产品经理,应该要具有通信硬件或家电硬件的行业背景,这样的人才能更加深入了解智能硬件。其实通信行业和互联网行业一直都是两个行业,通信行业曾经辉煌一时,犹如今天的互联网公司,曾经通讯企业也是多如牛毛,做交换机、小灵通、功能手机、通讯基础建设、发射塔等等的公司也曾遍布祖国大江南北。其实现在有很多互联网公司的技术骨干都来自这些传统通信企业,因此目前互联网公司有两种人,一种是土生土长的互联网人,他们从一开始工作就在互联网企业,具备互联网思维,懂互联网运作;另一类人他们因为传统通信行业的衰落而转向互联网这个新兴热门的行业,成为了另一类互联网人。因此,如果一个企业要做智能硬件,应该有意从这个领域获取人才。 

    综上所述,智能硬件还是一个新兴的概念,2015年也才刚刚被定为智能硬件发展的元年,对智能硬件产品经理的要求,应该也还没有完全被定型。但是它应该是科技发展的一个新阶段,那么对产品经理的要求应该是更高。

    本文由PMCAFF产品经理社区会员原创,版权归PMCAFF产品经理社区及作者共同所有。如需转载,请注明出处并保留链接。
    原帖地址:http://new.pmcaff.com/discuss/index?id=131048
    展开全文
  • 智能硬件产品经理需要具备的知识

    千次阅读 2018-06-28 11:31:47
    总结的不错,共享下
  • 这篇文章将围绕着智能硬件讲述产品经理,从产品经理的初阶,中阶以及高阶进行谈论。对产品经理有兴趣的小伙伴不要错过哦!产品经理是一个曾经很火热的岗位,当然目前热度依然在线。产品经理概念的火热和普及,是伴随...
  • 总之,智能硬件产品经理就是要全面,什么都要懂,具体多深就看你是不是主要负责这一块,你的职级,以及队友是否给力了。 在大团队,分工比较清楚,一般是硬件、APP、后台、数据分别有人负责,甚至好几个人负责一...
  • 智能硬件行业产品经理

    千次阅读 2018-07-27 19:58:58
    智能硬件属于一个新兴的行业,不同于传统的互联网产品经理,除了把控匹配硬件的手机端应用外,还需要与管控硬件产品的质量,并且在保证硬件产品功能的基础上,做到与软件端产品协调上市。  如上述所说,智能硬件端...
  • PRD模板、BRD模板、项目管理甘特图表格、产品规划实例、IPD的产品管理体系、产品研发管理体系书籍、实用性高。
  • 1. 智能硬件产品经理是否一定要有硬件背景?问题描述:合格的智能硬件产品经理需要了解硬件知识这个是必须的,但是想要做智能硬件产品经理是否一定要有硬件背景呢?答:产品经理的职责更多的是研究...
  • 先上结论:我认为,智能硬件产品经理一定要懂(了解)技术。我曾经在公众号上写了一篇文章,将产品经理概括为两大类:市场端产品与研发端产品,对应的各自职责区别非常大。如果一句话总结产品经理:产品经理就是技术与...
  • 硬件PM是生意人,互联网PM是设计师 在我做手机(07年前)的时候,还是功能手机、以及WM/塞班/UIQ等前智能系统的时代,软件系统还不是主要竞争力。整个产品以外观、功能为主打,一款产品从策划到发布的过程一般是这样...
  • 智能硬件产品开发全流程解析

    千次阅读 2019-09-09 13:32:25
    本文通过十八个流程点详解,为大家分享了智能硬件产品研发生产的全流程。 上篇文章我们聊了下软硬件产品经理的那些区别,这篇文章主要分享下硬件产品研发生产的相关流程。 上图所示的是一个智能硬件生命周期...
  • 智能硬件产品的开发流程涉及到各个事业部、产品规划部、研究院以及硬件产品中心;流程阶段划分为:市场调研阶段、产品立项阶段、产品需求评审阶段、方案设计评审阶段、硬件设计阶段、打样制作阶段、测试整改阶段、正...
  • 这是这个系列的第3篇文章,总结下这些年对智能产品的理解和思考,从产品经理的角度,聊聊如何从0-1打造款智能硬件产品。智能硬件类产品受限于硬件物理属性和成本,设计的时候要对这些限制有比较清晰的认识,不像纯...
  • 智能硬件产品经理 (15-30k·12薪) 职位描述: 负责硬件产品功能定义、性能测试,出具安装调试使用说明书; 负责软硬件结合产品的产品定义、市场调研、需求分析、竞品分析、产品功能设计和交互设计; 进行硬件的成本...
  • 去年 10 月,搜狗 AI 事业部总经理张博告诉 AI科技大本营(ID:rgznai100),翻译机只是搜狗做智能硬件的开始,接下里半年里,他们还将发布数款集成了搜狗 AI 技术的硬件产品。 3 月 18 日,搜狗举办了一场媒体沟通会...
  • 产品经理,项目经理必看。产品研发具体流程,特别适合新产品,新项目研发的总体把控,从项目方案收集、外观结构设计,硬件原理图PCBlayout、软件研发测试到试产、BOM变更...绝对是智能硬件产品项目开发经理,必看首选,
  • 未来的消费类电子产品,一定是以消费者(线下)体验为中心的。 近日,由镁客网旗下创业服务平台镁客汇组织发起,南京...在活动中,凭借着17年的智能硬件渠道营销经验,赛格南京电子市场总经理曹晓...
  • 嘉宾介绍邓晗,目前就职SHAREit资深产品经理,先后负责这个拥有18亿用户的海外巨头产品的互动娱乐模块、本地模块和游戏模块,产品位列2018年全球iOS与Google Play综合下载...
  • 开发智能硬件阶段

    2019-02-20 16:30:04
    一个智能硬件生命周期内所需要经历的全部流程,以及产品经理需负责的相关工作分为以下各阶段: 一、市场分析   如同互联网产品一样,除了在立项之前需要对市场规模、用户需求、竞品优劣势、BAT布局以及切入的...
  • 产品设计之初,都会考虑产品应该做成什么样,怎么做? 先不考虑这些,抛开这些东西,利用一个程序员...比如:智能AI音箱 状态:音箱、AI等 行为:播放音乐、语音交互等 上面只是简单列举了基本的,可能还有些...
  • 说明一下,我是一个从事面板显示行业的项目经理,跟硬件开发打交道较多,开发的产品是OLED、LCD屏,作为关键显示器件应用于智能手机、智能穿戴。下面说一下OLED屏的全新项目开发时程如何制订。 一个全新的OLED屏...
  • 汇集智能硬件、可穿戴设备、机器人、3D打印以及高科技硬件等方面的全球领先产品,适合科技发烧友、智能硬件创客、电子极客或者产品经理、工业设计师、概念产品爱好者、科技观察者以及对前言技术感兴趣的读者阅读
  • 智能硬件产品设计所需知识跨度大,很多产品经理不懂软件或底层技术,对于需要的把控往往没有信心,不敢确定某些需求是真假需求。 另外智能硬件的很多功能都能依赖于硬件的支持,直接影响产品的成本、可靠性、复杂度...
  • 物联网产品经理

    2020-03-23 23:54:00
    你可能听到智能硬件产品经理、AIoT的产品经理、AI 产品经理 物联网的产品经理也无法脱离产品经理的经典定义,管理产品的全生命周期,负责需求对接、产品定义,项目管理、营销推广,协调设计,研发,运营,市场的...
  • 任何一个硬件产品,大概需要的人包括项目经理,硬件工程师,软件工程师,外观及结构设计师,采购生产测试等等配套人员,关系到设计、研发、采购、生产等多个部门,其中硬件开发人员还可以细分为画原理图和线路板,...

空空如也

空空如也

1 2 3 4 5 ... 9
收藏数 166
精华内容 66
关键字:

智能硬件产品经理