人人都是产品经理 2.0 思维导图

编辑导语：刷新是大家常用的操作之一，主要作用是刷新页面中的缓存，从服务器获取新的内容。

在浏览 APP 的时候，不同场景中使用的刷新样式是完全不同的。

本文作者留心了这些细节，和我们分享了5种随处可见的、每一个内容性产品都具备的“刷新”功能的不同样式。

本文的大纲&思维导图系统桌面右键刷新几乎每天都有人在使用，而这个功能的存在其实windows系统的让用户来填的一个坑。

而且时间久了，成为用户习惯了就没人在意。

windows刷新最直接的作用就是刷新能让文件重新排序、归类和恢复到最新数据状态。

在速度上其实也有一定的提升，因为用户更改设置后，注册表发生更改，系统运行速度会慢一点，刷新后可以让更改后的设置生效。

举例：在域环境的文件共享创建了一个文件夹必须更新后才能显示，很多xx管家其实就删除注册表让系统变得更快就是这个原理。

从现在技术层面理解可以解决这个问题，而因这个windows历史遗留问题把这个坑位强加成为用户的一个习惯。

刚提到刷新是windows留下的坑位，的确这个坑位让用户接受了并在网页时代让其价值无限放大。

可以理解成黄金刷新。

刷新最直接的作用就是处理缓存问题，不同的刷新方式有着不同的缓存机制。

大致可以分为：F5刷新是不允许使用本地缓存，因此Last-Modified能起作用，但Expires 无效。

而Ctrl+F5是强制刷新，缓存机制失效。

转至”或地址栏里回车是正常的访问，Last-Modified和Expires都有效。

到了web时代刷新功能已经被开发者玩出各种新高度：比如刷新加载最新缓存的数据。

在网速差或者请求不到服务器的时候会做一些体验好的交互表现，例如“哎呦喂，这个页面找不到了”，谷歌在这方面其实也做了一些事情。

最典型的是谷歌浏览器在无法加载到网页时候会自动触发一个恐龙小游戏，这是一种解决降低用户在体验的时候烦躁程度。

很多用户特别沉迷于今日头条和网易新闻这种feed App，几乎每天上班下班闲暇时间都在不断刷新闻，而最值得提的是这个刷新的次数要比看信息次数多很多。

《人人都是产品经理》读书笔记《人人都是产品经理》读书笔记1《人人都是产品经理》分为6章，从介绍什么是产品，什么是产品经理，以及如何入门产品经理，并且对产品经理所做的工作进行了一个系统的讲解，化繁为简介绍了一个项目从用户调研，需求分析，开发，上线，后期反馈等等环节产品经理从中起到的作用，以及如何做需求调研，如何做OK的需求文档，并且从产品需求升级到“项目管理”，如何协调各方关系，保证产品能够成功上线，讲解如何触及产品的灵魂，明白自己到底做的什么，用户需求和产品需求之前的区别，在有限的资源下面有的放矢的舍取功能，做正确的战略，最终告诉我们如何热爱生活，提升自我产品修养，做一名优秀的产品经理，是一本从入门到高阶产品经理养成的书籍，现在我们来逐章“庖丁解牛”的学习和剖析这本书的精华。

第一章《写给-1到3岁的产品经理》第一个章节，灌输给我们一个“产品”的概念，一种能够解决需求的东西，生活中处处是产品，产品分有形和无形，服务行业给人带来的整套解决方案或者服务，也是一种产品，因为产品繁多，于是一个优秀的产品的产品经理存在的价值就非常大，可以让世界更加美好，可以改变我们的生活。

介绍了传统产品经理和现在的互联网产品经理的区别，从行业的形态，产品的形态和成本结构，用户的诉求和心态，赢利模式生命周期等等维度的区别，说明：如今的互联网产品经理需要更的侧重产品一个从无到有，从有到优的过程，其中涉及产品规划，数据分析，用户研究，需求分析，功能设计，项目管理，敏捷方法等内容。

告诉我们如何入行“产品经理”，如何从生活工作中找到切入点去思考产品，逐步的步入这个行业，介绍作者自己在阿里巴巴的产品经理成长历程，从一个“打杂人员”，到接触到PD的概念，再到独立去负责一个产品，接触项目管理，发挥团队的力量，流程化的制定，并且提出产品经理的灵魂：爱生活，有理想，会思考，能沟通。

第二章《一个需求的奋斗史》“一个需求的奋斗史”主要介绍：(1)用户调研;(2)需求采集;(3)需求分析;(4)需求筛选;(5)需求管理;(6)需求进入开发等一个需求产品的种种环节。

第一轮，产品规划阶段。

听用户定性地说，确定产品方向，做什么？随机抽样了40个用户做访谈，据此写出需求列表。

第二轮，某个项目的早期。

听用户定量地说，确定需求优先级，先做什么？投放了20万份调查问卷，确定了需求优先级的排序。

理解用户需求和产品需求之间的关系“Y”的越上面越是解决方案，越下面越是背后的目的。

“1-用户需求”，大多表现为用户的解决方案，往往是不好的，但好的“3-产品功能”一定是从用户需求转化而来，而不是凭空想出来的。

不要误解“创造需求”，你创造的只能是满足用户需求的解决方案——产品功能，而不是用户需求。

关于KANO模型最下面一条曲线叫“基础（功能）”，没有的时候，用户对产品无法接受，有了，也不会夸奖你，用户会觉得这是理所应当的。

所以，必5. 产品市场推广6. 产品生命周期管理产品经理的核心技能1. 沟通能力2. 无授权领导能力3. 学习能力4. 商业敏感度5. 热爱产品6. 注重细节，追求完美7. 日常产品管理能力适合产品经理读的书籍概括型：《产品经理实战手册》，王欣、夏济；《产品经理的第一本书》&《产品经理的第二本书》，哥乔斯市场营销：《水平营销》，科特勒；互联网思维：《启示录：打造用户喜爱的产品》，MARTY cagan；《结网》，王坚用户研究：《一目了然：WEB软件显性设计之路》，霍克曼；《点石成金：访客至上的网页设计秘笈》，克鲁格；《胜于言传：网站内容制胜宝典》，瑞蒂希设计：《设计心理学》&《情感化设计》，D.Norman交互设计：《软件观念革命：交互设计精髓》&《交互设计之路》，库帕企业管理：《公司进化论：伟大的企业如何持续创新》，摩尔；《跨越鸿沟》，摩尔；《创新者的窘境》，克莱顿·克里斯坦森；《罗伯特议事规则》，罗伯特。

一份高级产品经理的干货分享整理：终极prd这世界走的再快，也与你无关，一步一步成长，也挺好。

受公司学院的邀请，师父出山为广大同事做了一次含金量超高的分享。

打从上周接到邀请，师父就开始紧张兮兮的准备这次分享，满脑子都是如何做分享（偷偷告诉你们，他都没心思工作了）。

因为，这事情关乎他的面子，我想这世上可能没有什么比他的面子更重要的了。

他一直说“我满脑子的东西，怎么讲！”最开始他打算把整个产品设计流程全部讲一遍，然后一个人在那里神经兮兮哔哔了一天。

我实在看不下去了，于是给他讲了一下我平时听得一些分享的情况。

我说：“大家都是已经入门的产品了，其实早在我还没做产品工作的时候就已经对流程滚瓜烂熟了，但是知道流程并没有什么卵用。

我们需要的不是大的框架和虚的概念，不如你就抓住流程里面非常细小的点来讲实际工作中的应用”。

好在师父在懵逼的情况下听取了我的意见。

于是就有了下面的分享内容，这里我将放出我师父的演讲稿，这比听分享和看分享后整理的文档更有参考意义（我在师父分享完之后是整理了一份分享文档给学院的）。

主题：如何写好一份prd（我将草稿只字不改，虽然有点乱，但是这样完全代表他思考逻辑的稿子可以看出他的思维逻辑多缜密，还有丝丝尴尬和搞笑）大家好，我是家庭网络产品线产品中心的产品经理**，在部门主要负责路由APP的产品工作，很高兴在这里和大家做这个分享会，由于我之前从事的行业比较多，根据之前一些产品经验，结合自身的特长，总结了一套自己产品设计的方法，用来跟大家分享，由于时间关系，我这里着重分享下我写需求文档的一些经验，希望能抛砖引玉，互相交流学习。

也希望大家能在今后的过程中能总结出自己的一套更好的产品需求文档的编写方法。

我认为，一款产品的上线，产品经理需要负责其四个阶段：概念阶段，设计阶段，实施阶段和运营阶段。

概念阶段里我们需要提供产品的商业模式（即BRD）的内容以及产品的市场分析（即MRD），公司立项一般会需要提供这两个文档，特别是商业模式特别重要，斐讯0元购就是一个非常好的商业模式，往往一个好的商业模式基本决定了一个互联网产品的成败。

（干货）产品经理必备的十张图一、用例图用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。

用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。

主要分为系统用例图和业务用例图。

业务用例图主要是从业务的视角出发，通过业务建模并且对业务进行描述。

整体来说就是基于角色端需要操作模块的集合。

用户端需要操作的模块，实际上就是APP展示的模块。

当然只是通过角色进行区分。

需要注意的是，业务用例图主要是针对用户在产品中需要操作的事情为主。

下图就是售票产品用户需要去做哪些事情。

系统用例图主要是根据业务用例图分析得到的。

针对于业务用例图的用户行为分析后，从系统侧去建立对应的模块。

系统用例图是从使用者的角度，描述对应用户能使用产品做什么。

这样的好处，是让我们时刻以用户为中心，思考产品和功能。

很多小伙伴在做产品的时候，经常不能站在用户角度去思考问题，而往往站在了业务角色侧去考虑产品。

而系统用例图更好帮助产品经理规避了这点。

下图就是针对于上面售票产品用户侧需要做的事情，整理了用户侧和系统侧对应做的模块清单。

再举一个电商产品的系统用例图：业务用例图主要是针对于用户侧需要做什么？（同样，如果这个版本迭代涉及到的功能比较多，可以考虑业务用例图画一下用户在这个迭代版本中需要做什么）系统用例图是根据业务用例图中用户的操作，来把功能分配给用户和系统。

尤其是结合用户画像，哎哟！香得很……实用指数：★★★（三颗星）二、结构图结构图是指以模块的调用关系为线索，用自上而下的连线表示调用关系并注明参数传递的方向和内容，从宏观上反映软件层次结构的图形，结构图分建筑图和组织结构图。

结构图是在产品经理工作流中很重要的一步。

万丈高楼平地起，平地起前画架构。

而结构图搭建一旦确定，就不能更改了。

除非只有推倒重来。

所以必须在结构图之前一定要思考清楚，否则后面一直在填坑，对技术来说，可能需要走上重构的不归路。

产品经理工作基本流程和规范一、产品、项目研发基本流程第一阶段：需求采集和分析评估整理需求输入：项目合同（立项书等文档）、项目需求文档、相关资料和第三方（联系人、联系方式、数据接口等）产品输出：业务流程图(TFD)/简要技术建议文档节点枢纽：产品/项目负责人审核第二阶段：产品内部评审产品输出：业务流程图（TFD）、功能结构图、市场需求文档（MRD）/商业需求文档（BRD）内部输出：产品审核意见（讨论会、书面文档或邮件形式）节点枢纽：产品内部评审通过后进入设计阶段，没有通过回到第一阶段进行需求再确认。

第三阶段：产品设计产品输出：产品原型/产品需求文档（PRD）研发输出：原型问题建议文档节点枢纽：通过后进入研发阶段，没有通过回到设计阶段进行再完善。

第四阶段：产品研发UI输出： UI效果图研发输出：研发阶段问题节点枢纽：效果图评估通过后，UI图交付研发，研发阶段问题解决后进入产品交付阶段。

第五阶段：产品验收研发输出：完整产品系统、测试文档和操作手册以及其他相关资料产品输出：产品验收通过说明通知（文档、邮件）、PRD归档项目经理输出：项目接收确认节点枢纽：通过后产品和研发都将相关资料归档，项目经理将产品交付甲方。

如果是内部项目则交付运营，产品进入运营阶段。

二、产品经理基本文档流程图：业务流程图、页面流程图思维导图：信息结构图、功能结构图需求文档：市场需求文档（MRD）、商业需求文档（BRD）、产品需求文档（PRD）需求原型：产品原型其他文档：临时文档三、名称解释1. 业务流程图: 就是用一些规定的符号及连线来表示某个具体业务处理过程。

业务流程图是一种描述系统内各单位、人员之间业务关系、作业顺序和管理信息流向的图表，它是物理模型。

主要是描述业务走向，描述的是完整的业务流程，以业务处理过程为中心，一般没有数据的概念。

特点：利用它可以帮助分析人员找出业务流程中的不合理流向。

2. 页面流程图：具体到产品功能设计前，不同页面之间流转关系的图表，用户通过某项操作进入相应页面以及后续操作和页面。