产品经理知识结构图PMKS
产品经理组织架构
产品经理组织架构首先是产品管理层。
产品管理层是整个产品团队的核心，负责制定产品战略和目标、管理团队资源和协调各部门合作。
产品管理层通常包括产品总监或副总裁、产品经理经理等职位。
他们需要具备丰富的产品经验和领导能力，能够有效地组织团队，推动产品的整体发展。
产品管理层与高层管理层沟通，并向高层报告产品的发展状况、市场竞争情况和产品策略的制定。
他们还需要协调团队内部的决策和资源分配，确保产品能够按计划顺利推进。
其次是产品经理团队。
产品经理团队是产品开发和管理的核心力量，负责产品的设计、开发、上线和运营。
产品经理团队通常由产品经理、助理产品经理和产品设计师组成。
产品经理是整个团队的领导者，负责产品的整体规划和战略目标的制定。
助理产品经理协助产品经理进行产品调研和用户需求分析等工作。
产品设计师负责产品的外观设计和用户体验，确保产品符合用户的期望和需求。
产品经理团队需要具备市场分析、用户研究、项目管理和沟通协调等能力，能够有效地将产品意愿转化为具体的产品要求，推动产品迭代和优化。
最后是跨部门合作。
产品经理需要与其他部门进行紧密合作，包括研发部门、市场部门、销售部门、运营部门等。
与研发部门的合作主要体现在需求传递和产品开发过程中的沟通协调，确保产品能够按时按质上线。
与市场部门的合作主要体现在市场调研、竞争分析和产品定位等方面，以了解用户需求和市场动态，为产品设计提供参考。
与销售部门的合作主要体现在产品定价、销售策略和客户服务等方面，以确保产品能够满足市场需求并实现销售目标。
与运营部门的合作主要体现在产品上线后的用户反馈和用户体验的改进等方面，以确保产品能够持续地满足用户的需求和期望。
在产品经理组织架构中，产品管理层负责产品的整体策略和规划，产品经理团队负责产品的具体设计和开发，跨部门合作则是保证产品顺利推进和实现商业目标的关键。
通过合理的组织架构，可以使整个产品团队高效地协同工作，推动产品的持续发展和创新。
产品经理的知识结构目录!
产品经理的知识结构目录！个人日记 2009-05-31 13:50 阅读3 评论0字号：大中小前几天，有个朋友和我说，他们产品部想构建一个产品管理的知识库，由他来负责，他问我能否给一些建议，有个目录就可以，这样他就可以有目标地进行产品管理知识的整理了。
既然答应了这位朋友，我就得尽力完成，还好，只是要一个目录结构，如果还要内容的话，就真的要了老汤的命了，呵呵！我在设计这个目录的时候，没有完全按照产品经理的工作流程进行架构，而是把这个目录分为三个部分：1、产品经理的核心工作能力这也是联盟PMAS核心板的目录，主要是基于产品经理现实工作最需要的知识进行设计的。
2、产品经理的扩展工作能力这也是联盟PMAS扩展版的目录，主要是基于产品经理在工作中有时候会接触到的知识（现实情况如此，虽然这是经典定义中每一个产品经理所必须的）进行设计的。
3、产品经理的知识需要这就是联盟提出的产品经理个人素质模型中，扩展知识这一块的目录，主要包括：战略管理知识；项目管理知识；团队管理知识；时间管理知识。
以下为目录结构：PMAS核心板1、我知道我该做什么吗？1.1 产品管理到底是什么1.2 产品管理要做些什么1.2.1 战略管理1.2.2 战术管理1.2.3 根本目标2、我该如何去做呢？2.1 产品管理的基础是什么2.1.1我知道公司的产品战略是什么吗？2.1.2我知道我负责的产品需求是什么吗？2.1.3我知道公司3-5年的产品计划是什么吗？2.1.4我知道公司的年度产品计划是什么吗？2.2 初识三线五段模型2.2.1 核心思想2.2.2 注意事项2.2.3 根本目的2.3 什么是“三线”2.3.1 需求线2.3.2 成本线2.3.3 信息线2.4 什么是“五段”2.4.1 从何做起2.4.2 概念化阶段2.4.3 图纸化阶段2.4.4 技术化阶段2.4.5 商品化阶段2.4.6 市场化阶段2.4.7 一切重新开始3、产品经理方法篇3.1 产品需求的筛选3.2 产品概念的筛选3.3 产品业务流程构建3.4 产品的反设计3.5 如何写一份好的MRD3.6 用户原型的定义3.7 如何进行产品功能的分类3.8 产品项目的评审3.9 产品成本的控制3.10需求变更的控制3.11如何进行产品质量的验收3.12产品的回溯4、产品经理文档篇4.1 文档控制表4.2 文档的作用4.3 文档的原则4.4 文档的类型4.5 几个主要的文档4.5.1 需求矩阵表4.5.2 产品规划文档4.5.3 市场需求文档4.5.4 产品需求文档PMAS扩展版1、明确我的产品战略1.1 企业竞争策略上的把握1.2 产品竞争战略的制定1.3 行业发展的分析和预测1.4 产品发展所需资源的把握1.5 制定产品发展计划2、了解我的产品市场2.1 提出调研要求2.2 制定调研方案2.3 监督调研过程4.4 获得调研反馈2.5 知识扩展：调研方法和调研类型3、如何进行市场需求管理3.1需求管理的思路3.2 需求管理的方法3.2.1 需求矩阵表3.2.2 需求的属性3.2.3 需求筛选的标准3.2.4 需求变更控制4、如何进行市场细分4.1 市场细分的前提4.2 市场细分的方法4.3 市场细分的步骤5、如何进行产品组合5.1 产品组合的六种类型5.2 产品线延伸5.3 产品线填充5.4 产品线缩减5.5 扩展知识：产品发展的三种思路6、如何定义产品需求6.1 产品需求从何而来6.2 产品概念筛选的9个标准6.3 写一份好的MRD6.4 如何有效地对产品功能进行分类6.5 《MRD》和《PRD》模板7、如何制定产品价格策略7.1 影响价格策略的内部因素7.2 影响价格策略的外部因素7.3 常见的4种定价策略7.3.1 需求导向定价策略7.3.2 成本导向定价策略7.3.3 目标利润导向定价策略7.3.4 竞争导向定价策略8、如何考虑产品销售渠道8.1 产品管理者要关注的5种渠道8.2 找到最合适的渠道8.3 如何选择合适的渠道9、如何实现最终的交换9.1 资料的准备9.2 制作SKTs9.3 制定产品上市计划9.4 人员的准备和培训9.5 产品发布9.6 上市跟进9.7 上市总结产品经理的知识需要就不在这里说了，因为涉及的四大知识范围太大了，我也一直在学习，暂时还总结不出来，呵呵！以上是产品经理知识体系目录的架构思路，还有一种，就是按照产品经理的工作模块进行设计，其实也就是联盟P M人才模型的目录化，但是从我个人来说，还是认为上面的思路更符合当前国内产品经理的工作现状。
产品经理需了解的架构图／结构图知识
产品经理在工作过程中会遇到各种架构图（结构图），这些名词很容易混淆。
一般情况下，3-5年经验、善于总结归纳的产品经理才能逐步理解这些概念的含义，并且相对灵活的运用到工作中。
下面针对这些概念来系统地梳理一下，同时也是加深自己的理解和认知，希望能有所启发。
功能结构图就是按照功能的从属关系画成的图表，在该图表中的每一个框都称为一个功能模块。
功能模块可以根据具体情况分得大一点或小一点，分解的最小功能模块可以是一个程序中的每个处理过程，而较大的功能模块则可能是完成某一个任务的一组程序。
（百度定义）用通俗的话来说，功能结构图就是以功能模块为类别，介绍模块下其各功能组成的图表。
功能结构图一般不涉及具体的字段信息，只强调功能的逻辑关系。
以微信为例，我们可以看到整个微信分为4个大的模块：微信、通讯录、发现、我的。
发现模块里面有各种功能，比如朋友圈、小程序等等。
这里插一句题外话，一般人很少注意到微信底栏第一个菜单是“微信”，往往以为是“消息”“聊天”之类的。
网上各种各样的解释都有，我则更愿意理解为微信对自身的自信和坚持，正如微信自己描述的定位一样，它本身就是一种生活方式。
微信功能结构信息结构图是将产品的数据信息抽象出来，直观进行展示的图表。
它可以帮助产品经理理解复杂元素的构成，帮助开发进行进行表结构设计。
信息结构图的绘制通常晚于功能结构图，往往是在产品设计阶段的概念化过程中，在产品功能框架已确定、功能结构已完善好的情况下才对产品信息结构进行分析设计。
同样是以微信为例，下图列出了微信公众号文章涉及的一些核心字段。
这些能帮助产品经理和技术来理解整个产品方案的设计过程。
微信信息结构产品结构图是综合展示产品信息和功能逻辑的图表，也就是说看到产品结构图能快速了解产品的功能和信息结构。
某种程度上来说，产品结构图绘制出来，原型图上的信息和功能基本就已经确定了。
当然这个理解目前在业内没有形成一致的共识，只是一部分人这么理解而已。
很多时候产品经理在进行整理的时候，不自觉地将这两者融合在一起，因为功能是在页面里面的，围绕信息展开的，所以有时候并不需要分那么清，只要能把事情说清楚，不需要纠结。
腾讯-产品经理能力素质模型图(策划 运用5个岗位)
学习/提炼能力
带人的能力/知识…3
办公技能
项目管理
执行力/IQ
渠道管理
2
关联专业知识
产品规划（版本…
1
沟通能力/trade…
用户需求理解…
0
行业融入感…
市场/用户的调研…
危机预测与控制/… 营销与推广策略 运营数据分析
技术理解
AQ/EQ（心态/胸… 对外商务沟通… 行业认知
带人的能力/知识传学习
递
0.5
0 行业融入感/ownership
运营数据分析
技术理解
AQ/EQ（心态/胸怀）
对外商务沟通(BD\P3以
行业认知
上)
学习/提炼能力
知识传…4
办公技能
P2（专业等）
3.5 3
执行力/IQ
2.5 2
关联专业知识
1.5
1
沟通能力/trade off
0.5
0 行业融入感/ownership
运营数据分析
5
5
5
5
5
5
4
4
4
5
4
5
5
5
5
5
5
5
4
4
4
5
5
5
5
5
5
5
5
5
3
4
4
5
4
4
5
5
4
5
5
5
5
5
5
5
4
4
4
5
5
3
2
4
能力点变化 14
12
10
8
6
4
2
产品经理产品设计-产品高手必备——M-P能力模型
产品高手必备——M-P能力模型作为刚入门的产品小白，总会十分羡慕做出优秀产品的产品大牛。
而笔者告诉我们：要想成为产品大牛，我们可以建模通过梳理产品经理的能力模型，找到成为看到产品大牛的指南针。
在我刚刚入行产品经理的时候呢，我和很多职场新人一样看着身边的那些牛人，能非常熟练地完成工作，得到老板的赏识，最后又设计出与伟大的产品，为公司会带来巨大价值。
我就有一个疑问——到底要怎么样去提升自己，才能成为一个像身边那些一样优秀的产品经理。
这样的问题大半年一直困扰着我好几年。
直到我开始投身于面试工作了之后，我开始非常刻意的去观察去每一群产品经理候选人：包括从来面试，到面试成功，到入职，再到日常工作。
在我口试了有将近100位候选人后，我终于解开了这个惊愕，我发现原来在讨论了这么产品经理，上用其实核心就是集中在几种能力上，而这些优秀的人和我们平时最大区别就在于——思考问题的出发点上与加强的能力的侧重点不同。
在经过尝试，我把一个产品总监的职业生涯中所需要经理的能力抽象总结出了一个模型：M-P能力模型。
那么在我讲到能力模型之前，我想先请大家思考一个敏感话题话题，那么到底什么是产品经理，产品经理负责的到底项目经理是什么东西。
在我看来，产品经理一个是应用从想法诞生到需求制作再到市场推广再到商业变现的一个全操作步骤的组织者。
那么在我们清楚了描述这个定义之后，其实MP能力模型就呼之欲出了。
M-P能力模型：其实就是产品经理对他产品的整个生命周期掌控能力必须拥有的所的一个统称。
具体来说这个模型分为两部分：这样说可能会有点抽象，我来举个例子：假如说有一天老板跟你说：“小刘，我这边想做一个打车的APP”。
这个需求时候老板的这一句话对我们来说毕竟就是一个需求。
那么我们如何要将经纪人的需求落地呢，如果我们带着案例来思考下我们的日常工作场景。
可以发现工作步骤示例大概可以分为五步：第一步对于老板这个需求如果真要演变成一个app那毕竟不是那么简单。
PMBOK图解一项目管理框架
知识领域
启动
Hale Waihona Puke 规划过程组 执行监控
收尾
项目质量管理
质量规划
实施质量保证 实施质量控制
项目人力资源 管理
人力资源规划 项目团队组建 项目团队管理 项目团队建设
项目沟通管理
沟通规划
信息发布
绩效报告
利害关系者管 理
表3-45 项目管理过程、过程组 与知识领域的图解4
知识领域
启动
规划
过程组 执行
监控
收尾
项目风险管理
图2-6 组织结构对项目的影响
图2-7 职能式组织
图2-8 项目式组织
图2-9 弱矩阵式组织
图2-10 平衡矩阵式组织
图2-11 强矩阵式组织
图2-12 复合式组织
项目管理标准 （单个项目管理过程）
图3-1 PDCA循环
图3-2 项目管理过程组 与PDCA循环的对应关系
图3-3 绘制流程图的图例
表3-44 合同收尾 （依据与成果）
图3-11 项目过程组间的相互作用
图3-13 项目管理过程组 之间的三角关系
表3-45 项目管理过程、过程组 与知识领域的图解1
知识领域
启动
规划
过程组 执行
监控
收尾
项目整体管理
制定项目章程
制定项目初步 范围说明书
制定项目管理 计划
指导与管理项 目执行
监控项目执行 整体变更控制
项目收尾
项目范围管理
范围规划
范围定义
制作工作分解 结构
范围核实 范围控制
表3-45 项目管理过程、过程组 与知识领域的图解2
知识领域
启动
规划
(干货)产品经理必备的十张图
（干货）产品经理必备的十张图一、用例图用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。
用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。
主要分为系统用例图和业务用例图。
业务用例图主要是从业务的视角出发，通过业务建模并且对业务进行描述。
整体来说就是基于角色端需要操作模块的集合。
用户端需要操作的模块，实际上就是APP展示的模块。
当然只是通过角色进行区分。
需要注意的是，业务用例图主要是针对用户在产品中需要操作的事情为主。
下图就是售票产品用户需要去做哪些事情。
系统用例图主要是根据业务用例图分析得到的。
针对于业务用例图的用户行为分析后，从系统侧去建立对应的模块。
系统用例图是从使用者的角度，描述对应用户能使用产品做什么。
这样的好处，是让我们时刻以用户为中心，思考产品和功能。
很多小伙伴在做产品的时候，经常不能站在用户角度去思考问题，而往往站在了业务角色侧去考虑产品。
而系统用例图更好帮助产品经理规避了这点。
下图就是针对于上面售票产品用户侧需要做的事情，整理了用户侧和系统侧对应做的模块清单。
再举一个电商产品的系统用例图：业务用例图主要是针对于用户侧需要做什么？（同样，如果这个版本迭代涉及到的功能比较多，可以考虑业务用例图画一下用户在这个迭代版本中需要做什么）系统用例图是根据业务用例图中用户的操作，来把功能分配给用户和系统。
尤其是结合用户画像，哎哟！香得很……实用指数：★★★（三颗星）二、结构图结构图是指以模块的调用关系为线索，用自上而下的连线表示调用关系并注明参数传递的方向和内容，从宏观上反映软件层次结构的图形，结构图分建筑图和组织结构图。
结构图是在产品经理工作流中很重要的一步。
万丈高楼平地起，平地起前画架构。
而结构图搭建一旦确定，就不能更改了。
除非只有推倒重来。
所以必须在结构图之前一定要思考清楚，否则后面一直在填坑，对技术来说，可能需要走上重构的不归路。
运营可能会用到的11种图表类型,都在这里了
产品经理简称PM，是指在公司中针对某一项或是某一类的产品进行规划和管理的人员，主要负责产品的研发、制造、营销、渠道等工作。
产品经理是很难定义的一个角色，如果非要一句话定义，那么产品经理是为终端用户服务，负责产品整个生命周期的人。
产品经理需要考虑目标用户特征、竞争产品、产品是否符合公司的业务模式等等诸多因素。
近年来互联网产品经理火热，一起看下为大家精选的互联网产品经理学习文章。
DT时代，我们每天都会收获来自各种渠道的海量数据，它们是对我们上一步行动的反馈，但人脑消化数据的能力却是有限的——如何及时洞察数据中的涵义，就需要数据可视化工具的帮助了。
然而，图表的类型非常丰富，如何做出正确的选择，达到“一图胜千言”的效果呢？数据的五种关系首先，我们需要了解，数据通常包含五种相关关系：构成、比较、趋势、分布及联系。
构成主要关注每个部分所占整体的百分比，如果你想表达的信息包括：“份额”、“百分比”以及“预计将达到百分之多少”，这时候可以用到饼图；比较可以展示事物的排列顺序——是差不多，还是一个比另一个更多或更少呢？“大于”、“小于”或者“大致相当”都是比较相对关系中的关键词，这时候会首选条图；趋势是最常见的一种时间序列关系，关心数据如何随着时间变化而变化，每周、每月、每年的变化趋势是增长、减少、上下波动或基本不变，这时候使用线图更好地表现指标随时间呈现的趋势；分布是关心各数值范围内各包含了多少项目，典型的信息会包含：“集中”、“频率”与“分布”等，这时候使用柱图；同时，还可以根据地理位置数据，通过地图展示不同分布特征；联系主要查看两个变量之间是否表达出我们预期所要证明的模式关系，比如预期销售额可能随着折扣幅度的增长而增长，这时候可以用气泡图来展示，用于表达“与……有关”、“随……而增长”、“随……而不同”变量间的关系。
对信息中包含的5种关系可以简单归纳如下构成：占总体的百分比比较：项目的排名趋势：如何随着时间变化分布：项目的频率情况联系：变量之间的关系图表的具体使用场景下面，我们具体来看一下数据观提供的图表特点及适用场景：1.漏斗图漏斗图用来表示逐层分析的过程，从一个总值（最顶端），不断除去不关心的部分，最终得到关心的值的过程。
产品经理关键素质点标准定义(腾讯岗位能力模型图)
•举证过往2年中对行业研究的 报告 •列举已发布产品中本人提出 并主导完成的产品特性
•列举并提交过往1年中完成的 具体策划设计案的文档和研发 结果证明
•熟悉某个专业领域的产品设计方 法和技巧，能更好的理解和结合 产品整体设计思想，独立高效的 完成相关的策划设计任务，并能 形成自己的经验积累
•列举并提交过完1年中主导的 重要系统或中小型项目的策划 设计案，并提交相关系统成功 运营的结果说明
•熟悉相关产品渠道管理的一 般知识 •能够理解并掌握各项渠道政 策和流程，对客户/代理商进 行正确的政策引导，提供合格 的渠道服务
项目管理
熟悉项目管理基础知识和和核 心管理控制点。能够进行简单 项目的计划跟踪和监控
领导力 领导能力
带人的能力/知识传 递
能够指导级别较低的同事完成 工作任务
行为标准1
果证明
规划，给出合理的版本计划
成功执行的过程及结果报告
•列举自己过往工作过程中主 要使用或掌握的渠道管理流程 或规范等 •列举并提交开展渠道服务和 伙伴引导的工作成果证明
•有一定的渠道运作经验，能够掌 握并利用所辖领域渠道资源独立 开展业务，同时可以在指导下拓 展新的渠道资源
•列举过往主要的渠道工作及 成果，并举证独立开展渠道相 关业务及成果的报告 •举证参与新渠道资源拓展的 工作证明
了解Client、Server、后台、设 备/带宽的技术基础理论和在产品 中的主要表现形式
•提交自己学习过程中对相关 技术在产品中的主要表现形式 的总结，并提交相关技术负责 人的评价
•举证在过往1年工作中团队融 入、工作创新的例证或直接上 级、项目负责人的评价
愿意听取并可以积极对待不同意 见甚或反对的声音，在遇到问题 时不抱怨，能够积极主动找原因 、想办法，寻求帮助最终达成目 标
PMPPMBOK图解项目管理完整版经典PPT90页
收尾过程组
4.6 结束项目 或阶段
12.4 结束采购
项目整体管理
项目采购管理
环形线内的过程是整体管理知识领域的一部分，该知识领域协调与统一其他各知识领域的过程。
*
第四章 项目整体管理
汤辉—PMP
*
输 入
工具与技术
输 出
项目工作说明书 商业论证 合同 事业环境因素 组织过程资产
1. 专家判断
运营 Operational Work
工作性质：常规，重复 工作环境：封闭，确定 管理组织：稳定，持久 目 的： 维持经营
项目和运营
*
项目与运营
比较项
项目
运营
负责人
项目经理
职能经理
实施组织
项目组
部门
时限性
一次性
持续不断
目标
独特性
重复性
目的
实现目标结束项目
维持运营
管理追求
效果
效率
*
什么是项目管理
绩效报告 变更请求，附注对其他项目组合、项目集或项目的影响
战略与优先级 渐进明细 治理 处理请求的变更 其他项目组合、项目集或项目的变更所带来的影响
绩效报告 变更请求，附注对其他项目组合、项目集或项目的影响
*
战略、运营和项目管理的关系
战略管理
项目管理
运营管理
选择做哪些项目
支持战略目标的实现
支持
*
规划过程组
4.2 制定项目管理计划
项目整体管理
5.1 收集需求
5.2 定义范围
5.3 创建WBS
项目范围管理
6.1 定义活动
6.3 估算活动资源
6.4 估算活动历时
产品经理思维框架 | 三维思考模型
三维思考模型，是把一个完整的产品的概念，从具体到抽象、从实操性强到主攻思考，分为了三个维度。
越是刚入门的PM，越是关注实操性更强的部分，而忽略了思考的部分。
这可以算是PM成长的主要瓶颈了。
突破了思考的界限，也就等于突破了成长的瓶颈，能到达一个更高的思维高度。
三维思考模型的三个维度，分别是：业务维度、支持维度和泛化维度。
其中业务维度和支持维度，基本构成了整个用户体验闭环；而泛化维度则更关注于整个团队的未来发展。
通过这三个维度的勾勒，基本能在心中对一个产品的全局有一个完整的模型。
不管思考什么，至少不会偏离产品的发展主线。
人们总说“细节决定成败”，但不是每个细节都决定成败的。
就像“成功必须经历磨难”，但并非“经历了磨难就一定成功”。
心中对整个产品有了完整的模型之后，就不至于在那些看似重要其实无所谓的细节上，花费太多精力了。
业务维度——核心功能业务维度，指的是大家通常理解的产品，最狭义的产品概念。
这个产品可以是一个APP、一个网站，或者任何你想要做的最核心的有形产品。
这个部分应该是最核心的功能，是看得见摸得着的，直接与用户接触的产品部分。
在这个维度，最关注的是通过视觉设计、流程优化等手段，来优化用户体验。
为了做到这一点，PM要去收集和分析，用户主动反馈的和我们主动收集的各种数据。
用一款移动设备上的阅读APP来解释一下，下面我们就来看看这个“栗子”。
对于一款阅读软件，核心功能当然是阅读。
找到想读的内容，打开，翻页，设置书签等等。
只是把阅读实体书籍的过程，照搬到互联网上，凝聚到一款APP中，然后在进行适当的优化。
优化的部分，可能包括调整排版和配色，自动帮助用户记录阅读进度和阅读历史，提供简单的笔记功能，自动向用户推荐用户可能喜欢的内容等。
业务维度是一个产品与用户最直接接触的部分。
相比其他两个维度，一个团队总会在这个维度快速得到用户的大量反馈，同时也能收集到大量关于业务的数据。
如果用户量足够大的话，有任何的小差错，同样会收到大量的用户投诉。
产品经理产品设计-你对信息架构图了解多少
你对信息架构图了解多少产品经理经常交互设计师的日常工作中和接触到信息架构图，本文从产品设计的层面，梳理介绍信息架构图的定义、发挥的作用与资产价值、与产品介面功能结构图和产品结构图之间的区别，以及绘制信息架构图需要注意的事项。
信息架构的核心是探讨用户对信息的认知过程，对于产品设计而言，信息架构关注的是“呈现给用户合理且有价值的资料”。
清晰明确的信息架构图，能够在界面层面形式语言的表达产品的功能模块和整体的清楚路径，制我有利于产品设计者从宏观角度审视：不同业务模块如何贯彻执行到界面结构，以及不同功能模块之间的关联性。
这里大家需要搞清楚”信息架构图”与“产品功能结构图”、“产品结构图”间有的区别与联系：参见下图示意。
我们可以根据《用户体验要素》中对产品设计整个过程的分层，阐释三者之间的关联性。
产品功能结构图的重点是梳理产品的功能逻辑学与功能模块。
这个阶段之间各硬件平台及其子功能之间，可能没有凸显必然的关联性，这部分有待处理的任务就会交给信息架构图完成，产品经理在构思需求时经常需要绘制功能结构图。
信息架构图的重点是梳理具体页面及页面的字段信息。
具体到界面时，页面之间的关联需要清晰的呈现出来，这个阶段也是为绘制原型、信息排版布局打基础。
交互设计师在一些项目中会输出交互稿之前，需要提前绘制信息架构图。
产品结构图囊括了产品的功能与信息，同时也可以在图中示意功能之间的逻辑版本升级关系。
可以直观用一个公式表达：产品结构图=产品功能结构图+产品信息架构图。
1.产品设计人员为什么使用信息架构图2.信息架构图在产品设计中的价值《用户体验要素》这本书中将产品设计的过程进行了分层，在不同层面有不同职能某一方面人员关注不同的产品架构，参见下图：战略层解决的是两个最基本极为问题，以及他们之间的权衡关系：“产品目标是什么？用户需求是什么？”因此，战略目标层关注产品最核心的“业务架构”。
范围层是将在战略层确定的产品普通用户目标和用户需求，转变成产品应该给用户怎样的内容和功能。
产品经理学习资料8张图,看懂数据驱动业务的六个层次
导语：我们总说数据驱动业务，可平时看到的，却总是业务部门追着数据部门屁股要数据。
哪里是驱动业务了，分明是被人牵着鼻子走啊！很多同学都有类似的疑惑：到底数据分析对企业有什么用？我的数据用到什么地方去了。
最关键的：如果数据都对企业没用，我的岗位还值钱吗？数据当然会驱动业务，只是在不同的企业发挥作用的形式不一样。
今天我们一起来看一下，数据驱动业务的六个层次。
看看你们企业是哪一种。
数据驱动业务，最直接的形式就是给业务下KPI。
你，今年销售要破千万！你，今年销售要破一个亿！类似的场景我们可能早就有耳闻。
下任务带数据，在中国已经有2000年历史了，古代的军令状就是最早的KPI指标承诺书。
似乎带个数据，就显得这个命令格外有分量，就必须要完成。
完成就是英雄，完不成就杀头，也显得格外地对业务有驱动力。
然而，下个KPI就能驱动，只是想象中的事。
实际上，只是盲目地用数据下KPI，效果并不好。
因为KPI指标到底怎么来的？为什么要做到这么多？每个人分配多少？完全没有一个标准。
因此很容易让下KPI变成一个假大空的事情。
办事拍脑袋，承诺拍胸脯，出事拍大腿，结局拍屁股，也成为这种只有空洞KPI的企业的常态。
总之，没有分析过程支持的KPI，就是奴隶监控手中的鞭子。
虽然看起来甩得啪啪作响，煞有威严，打得奴隶们不得不走。
实际上却没有效率，常常沦为空谈。
这是数据驱动业务的第一阶段。
当然，很快大家就发现空下KPI效果不好使。
实际上，一个良好的KPI，是蹦一蹦可以摸得到的KPI，这样既考虑了实际能力，又有挑战性。
于是人们开始考虑拆分KPI，寻找KPI的来源。
还拿销售数据举例子：如果是按团队销售的，就开始拆分：如果是按门店销售的，就开始拆分：这种做法，极其类似地主家收租。
地主家会雇一个账房先生，账房先生会先算一个总账，看看今年是丰年还是灾年，预计下地主老爷下边的50个农户总体能产出多少。
如果遇到灾年，总收入不足，就建议地主老爷趁机多兼并一些土地，把农户总数做多，还能保住总收成。
思维导图读PMbok第6版-项目整合管理（21张全讲）
思维导图读PMbok第6版-项目整合管理（21张全讲）“ 3个月，800多页书，一大堆工作，复习时间不够呀？老师用思维导图解析PMP，思维导图解析PMP梳理PMbok第6版逻辑结构，帮你您全局掌握PMP知识，重点掌握PMbok难点、快速记忆PMP知识，思维导图解析PMP能帮您提升至少一倍学习效率，缩短一半学习时间，让您考试有底气。
”- 【01 总图】整合管理定义是：整合目标、统筹协调过程、平衡需求分配资源。
PM为整合而生，整合是PM唯一责任，不能授权给别人。
本章重点解析整合管理。
整合管理知识领域有7个过程，分别是“制定项目章程（I）、制定项目管理计划（P）、指导与管理项目工作（E）、知识管理（E）、监控项目工作（C1）、实施整体变更控制（C1）、结束项目或阶段（C2）”分属IPECC。
内容有点多，考试分数多，情景题也多，是考试重点，本章考题在25~30题之间。
别着急，且听老师慢慢说。
【02 7个过程】01.制定项目章程制定项目章程属于整合知识领域、启动过程组，定义是“编写一份正式批准项目或阶段的文件，并授权项目经理在项目活动中使用组织资源的文件的过程”。
制定项目章程有2个输出：《项目章程》&《假设日志》。
项目章程三件事“谁起草、谁签发、目的是什么？”第一个起草，两拨人起草，一发起人/PMO/高管，二授权项目经理起草；起草完了谁签发呢，外部人员签发，可以是发起人/PMO/高管；项目章程2个目的：确定项目经理人选，授权项目经理使用项目资源；《项目章程》是项目的纲领性文件，包含内容很多。
《假设日志》用于记录项目整个生命周期中的假设条件和制约因素。
值得一提的是，PMbok第6版明确指出，《假设日志》作为项目章程一部分，即何为一个文档。
由此，可以借用PMbok第5版记忆方法记忆制定项目章程的两个输出。
此时记忆方法是“四项、三高、三总、三人”有两个重要输入“商业文件、协议”。
第一个输入商业文件目的就是搞清楚“是否值得投资”，包含“商业论证、效益管理计划”。
产品经理常用的思维导图模板
产品经理常用的思维导图模板
导读：
产品经理天天和产品打交道，需要绘制各种图表。
涉及到的工作也有很多，比如：产品上线前市场调查、确定产品后产品规划、产品策划或者产品网站的策划、上线实施细节、上线后产品及网站运营、维护及推广还有团队管理等等，而且在不同的环境中用到的工具也会有所不同。
免费获取思维导图模板：/mindmaster/
思维导图的名字很多，又称脑图、心智地图、脑力激荡图、灵感触发图、概念地图、树状图、树枝图或思维地图。
这个工具相信很多人都熟悉，它能够帮助产品经理理清思路，可以帮助把大脑中所有想到的相关信息记录下来，再通过头脑风暴的形式梳理出所有的信息关键点。
想要提高工作效率，离不开一款优秀的软件，MindMaster是一款能跨平台使用的思维导图工具，内置丰富的模板主题例子，产品经理可以利用这些模板很轻松的创建出所需导图，提高作图效率。
免费获取MindMaster思维导图软件：/download/mindmaster/
产品经理常用思维导图模板例子预览
项目进展报告
培训计划思维导图模板
企业组织结构思维导图模板
产品问题分析思维导图模板
时间管理思维导图模板
会议记录思维导图模板
活动策划思维导图模板
SWOT商业分析思维导图模板。
产品经理产品设计-PM的5层能力等级放下技术,是PM迈出的第一步
PM的5层能力等级放下技术，是PM迈出的第一步上一篇，我们从房地产项目层面提出了PM的核心能力架构。
今天，我想从公司层面，分析一下PM的核心能力架构中的着力点过程能力，这也是PM当下最关心、最真切的痛点。
还记得上一篇我的同事老A吗？为什么他能在知名外企带三五百人的跨国团队，终究在一家总共只有不到100人的本土公司放声疾呼“PM不是PM”？因为着名外企体系完整、职责明晰、个人能力强、资源充分、管理规范、文化氛围好……无论你找到多少缘由，这些都可以为知名外企的成熟度高。
高成熟度的企业，自然会要求高成熟度的PM。
因此，PM的能力标准，应该随着企业不同发展壮大阶段的管理诉求，呈现出动态变化。
藉由成熟度能力模型CMMI和发展民营企业发展的生命周期模型（PowerandOrganizationDevelopment，LarryE.Greiner），可以将企业的发展分成五大阶段：于此对应的，PM的能力等级，也可以区划成五级。
PM关键步骤能力等级描述，凡奉信息版权所有企业处于“创业阶段”，甚至还不具备连贯完整企业组织的特点，开发工具处在随意而混沌的状态，几乎没有规则和制度，仅会关注直接系列产品支持产品交付的活动（比如：编码）。
这个阶段的企业最关心的内部问题，就是如何下订订单。
因此，一直处于这类企业阶段的PM，基本等同于一个非常大程序员——十分关注软件实现的技术，也因此得到晋升大好机会，但却只具备不完整的项目管理意识。
项目中发生的管理和改进活动都是无意识的，或者是设计模式式的。
处于该等级的项目经理，虽然可以凭借热忱和奉献完成项目，但却无力重新配置进度和质量，甚至品牌意识不到项目潜伏着隐患。
企业走过创业阶段，进入“聚合阶段”，扩张会使企业意识到管理的重要性，并开始实践。
这个级别的PM，必须跟随企业的管理诉求而发展壮大，形成和建立项目评估、软件工程以及改进的管理能力，并将工作关注点从软件产品的交付转移管理工作到项目管理上。
如何成为一个运营大牛,给你一张结构图!
产品经理简称PM，是指在公司中针对某一项或是某一类的产品进行规划和管理的人员，主要负责产品的研发、制造、营销、渠道等工作。
产品经理是很难定义的一个角色，如果非要一句话定义，那么产品经理是为终端用户服务，负责产品整个生命周期的人。
产品经理需要考虑目标用户特征、竞争产品、产品是否符合公司的业务模式等等诸多因素。
近年来互联网产品经理火热，一起看下为大家精选的互联网产品经理学习文章。
既然要搭运营的标准结构，又回到了我们常说的一句话：“所有的运营都是围绕着用户展开的”，所以这一次我们要用户运营开始说起。
这里要指出的是，内容运营、活动运营和用户运营并不是三块完全独立的模块。
内容运营和活动运营其实也是用户运营的实现手段。
只是用户运营的角度不一样，内容和活动是纵向的，而用户运营是横向的。
说起用户运营，一定要说起“拉新、留存、促活、转化”，这其实也是用户的四种状态。
我们做用户运营，其实就是在做用户的状态提升。
还有一种情况，就是流失用户的“召回”。
这里我们需要记住一个关于用户运营非常重要的关键点：用户的每一次状态提升，是来源于用户的决定。
用户的每一次决定，本质上都是指用户和产品之间产生了一种“契约”。
任何一个人，在做一个契约签订的时候，他一定潜意识的去考虑两样东西：成本和获取。
这几句话什么意思呢？接下来，让我们慢慢展开：一、拉新/召回1、拉新拉新会出现在两种情景下：正常运营阶段、产品冷启动阶段先说说正常运营阶段，在这个阶段最主要的就两种：渠道拉新和转介绍拉新。
至于渠道拉新分为三种：自有产品渠道、外部免费渠道、外部收费渠道（也包括一些资源互换渠道）（具体看结构篇｜如何成为一个运营大牛（二）：一张图看清内容运营）。
不管是哪种情景，一定是：一个潜在用户，在某种场景下，通过我们的某个内容和活动产生了感知，并产生了一个“加入”的决定，最后做出了一个“加入”的行为。
我们来看这么一张图：用户、内容、场景等在我们之前的几篇中都已说过，这里我们要说说用户的“感知”了，感知会直接影响用户作出是否“加入”的决定。