产品经理原型评审怎么开

Ⅰ 初级产品经理-如何高效绘制AXURE原型

      原型是产品经理或者交互设计师所设计的某一需求或者某一问题的具体的解决方案。绘制原型的工具有很多，我们公司大多的产品用的都是Axure。用这个软件，高保真或者低保真原型都能做的很好。那么，怎样的原型才适合团队交流？

      毕竟绘制出来的原型并不是只给自己看的，还要讲解给团队里的成员，UI/前端/开发。特别是进行小组内评审的时候，通过演示原型，需要向他们讲解产品内部的逻辑、具体的页面、动效等，还要向他们询问设计是否合理，能否实现等，静心倾听他们的意见。这时候，原型就是一个思维传达的工具，将你的想法，翻译并灌输给你的团队成员。同样，原型是也团队的交流工具，针对绘制出来的原型，每个人都可以谈谈自己的看法，交流思想，完善原型不足的地方。

      所以原型绘制出来，必须要有基本的交付标准。

一、原型设计的基本交付标准

1.清楚------让他人能明白产品是干什么的，包括什么功能，有哪些页面。

需要清楚地表达页面有哪些内容模块

需要清楚地表达模块内部的构成元素

2.清晰------让队友知道具体有哪些要求，指导他们如何做

【1】功能操作

  某一个功能可以进行哪些操作，点击/鼠标悬浮/拖动等操作，以及页面会有什么反应。（方便开发的工作）。

【2】操作路径

       有一些操作是要跳转页面，跳转的路径需要标清楚，跳到哪去了，涉及哪些页面，页面之间是如何联系的。防止用户迷失。

【3】点击状态

一些链接，按钮，需要标明它初始的时候是什么样，鼠标悬浮有什么效果（颜色/下划线/提示语等），点击的样式变化，以及点击后的样式。（这些可以为前端的工作提供方便）

【4】信息组合

相关的信息需要组合在一起，比如一些基本信息，姓名/性别/年龄等最好放一块，不要分开。不相关的保持距离。

【5】位置排序

页面的布局应该适应用户的习惯，浏览方式、工作任务。突出强调重点，方便用户的工作。一些数据可以思考一下它们的排列方式，按什么排序，能方便用户查找，仍旧是“以用户为中心”。

3.周全-----产品的各种细节，不能疏忽

【1】交互状态

     某些重要的操作，交互样式是怎样的，效果如何，最好单独抽出来做成高保真，演示给他人看，让他们对产品有深入的体验和感受。

【2】数据显示

原型上涉及的相关数据做好有真实的案例，将需要获取的关键数据全部展示出来，比如一篇文章，需要的数据：作者、发布时间、浏览量、喜欢数、收藏数等，方便开发准备必要的数据接口。

【3】异常考虑

需要考虑一些突发情况的应对，比如断网、加载太慢、数据已经被删除了、数据找不到了、没有访问权限等等情况。

【4】配套页面

产品里的一些功能可能和其他产品有关联，需要将可能涉及的其他页面包括到项目内。比如页面在wap上手机的浏览样式、一些发送给用户的消息/短信的内容和样式等等。

4.基本审美

【1】对齐

【2】间距

【3】颜色

【4】字体

推荐大家看看《写给大家看的设计书》这类易上手的书籍。

5.基本规范

【1】页面尺寸

       web的宽度有960px、1000px、1200px，App有安卓、iphone5、iphone6等，需要与已有的产品保持统一的尺寸。

【2】字体大小

     标题可以是18px或者16px，内容可以是14px。既要考虑用户是否看到清，又要考虑美观。

【3】颜色

     原型不要有太多的颜色，坚持黑白灰，除非要突出，可以用其他的颜色。

【4】弹窗

     弹唱的样式最好做统一，弹窗名+内容+操作按钮+关闭

【5】元件

   不在原型正文添加过多的截图、图标样式，会对UI的设计造成干扰。

二.Axure的快捷使用技巧

       工欲善其事必先利其器，工具使用的越娴熟，才能节省大量时间用于方案的思考。下面将简要分享Axure绘制原型时的一些快捷操作：

      首先在顶部菜单栏中找到<视图>，把需要的部件显示，就可以设置了。

1.组件库的建立（能提高效率，保证产品层面的统一一致）

2.母版的使用（适用于多页面通用的部分，修改后，集体自动更新）

3.设置页面样式（页面的字体、背景能一次性设置好）

4.元件的交互样式

5.元件组合

       把要组合的原件用鼠标框在一起，按住ctrl+G，成为组合后就可方便复制拖动了。许下按住ctrl+shift+G，也可以点击选中后，点击下图的两个图标来组合和取消组合。

6.对齐、居中、平均分布

选中要对其的内容，选择一种分布样式，就能快速得到整齐的原型样式，而不用一个个手动调整。

7.输入框类型的设置（预设好类型）

一些输入框，可能需要设置默认文字，可以直接选中了输入框后，在原件属性里设置提示文字和一些限制。

8.元件的提示语

        有些文字需要有鼠标悬浮显示提示语的动作，可以直接在原件的属性里设置“原件提示”，输入要显示的内容，即可。

三、制作原型的过程

1.梳理功能点-------------------将需求转化为功能清单，标出重要等级（前提是需求已经梳理清楚）

2.规划产品结构----------------用Xmind或者笔和纸等工具画出产品有几个页面，每个页面包含哪些元素

3.整理原型目录----------------用Axure添加原型的几个页面，考虑页面之间的跳转关系

4.设计页面的布局（打格子）-----用不同的色块，方框来表示这部分将要表示什么板块，设计好页面的布局

5.填充各模块的细节----------在方框里把具体的信息和数据填充完整

6.增加少量的交互动作--------------体现在一些涉及到任务的操作

7.页面注释-------------完善交互说明

8.审查自检------------------功能是否覆盖完全；页面有没有缺失；流程是否明确；状态是否完备

四、原型应用中的经验

      因为我多是负责后台系统的优化，所以是直接和开发打交道，如果涉及前台页面，就需要UI先将原型做成图片，再由前端制作含有动效的demo，开发再按照demo开发。但是不论哪种，绘制出来的原型一定需要让队友都明白你的逻辑和要表达的重点。

      第一次负责项目的时候，我用的是高保真，画完整的原型就花了一星期多，各种动作和交互，恨不得做个虚拟的产品。但是和开发讲了原型后，等来验收项目的时候，才发现，开发大部分都没有按照原型上的动作来，甚至连细节都有遗漏。一个个催着补上后，我开始思考这种方式是不是不太划算，太费事费力，结果又不太好。

       后来我看了我上级绘制的原型，都是以静态页面为主，可以说是低保真，但是每一种情况都详细地用图文描述清楚，点击之后是什么样子，将要获取什么数据，失败了会怎么样都有。而且这种方式，完成的特别快。于是我就选取低保真模式的开始画原型，结果发现，开发有时候并不能将一些动作做好。

       于是我开始“T式原型 ”。“T式原型 ”就是大部分是以低保真铺展开，将整个产品的逻辑都直接呈现出来，再在某些需要重点描述的地方用高保真描述深入。所以，我的原型大部分是以 低保真+注释说明和高保真+动作演示 的组合。 不过对于交互简单的产品来说，低保真模型足够了 。

       每个产品绘制原型的习惯和风格都有所不同，但关键还是需要进行小组会议来向队友们讲解原型和逻辑，在开发的过程中，需要多沟通。

       另外，分享大家关于AXURE学习的网站，可以在里面找到免费的软件安装包和教学课程。

https://www.axure.com.cn/

如果对文章感兴趣，欢迎评论留言，坚持喜欢的事情，加油~

Ⅱ 产品经理的完整工作流程

初中级产品经理的完整工作流程

一、用户调研

用户调研分为定性分析和定量分析。定性分析是指用户访谈，定量分析是指调查问卷。

用户访谈。当然访谈需要一定的技巧，更多的倾听为主，以了解用户的内心想法为主。访谈时对用户的初步回答反复追问“为什么”，引导用户从表面的行为开始思索，清理出行为背后的动机、需求乃至价值和文化观念。

调查问卷。问卷调查是一项有目的的研究实践活动，设计的问卷是为你的特定研究目的服务的，这是设计问卷之前必须植根于脑海中的一个观念。既然问卷调查是一项有目的的研究实践活动，那么从理论指导实践的角度出发，在设计问卷前必须要做好充足的理论准备，宏观层面上应做到以下两点：1.明确你们研究的主题是什么 2.明确你们想通过问卷调查获取的信息有那些。通过调研问卷你可以定量的验证你提出的需求。

二、需求的收集，建立自己的需求池

收集各个部门的需求，建立自己的需求池。并定期对需求池进行整理。你的需求池里面有不同人提出的需求。

定期对需求池做一定的梳理 。产品部门定期读需求池进行整理，那些需求是下一步要做的，那些需求是是可以暂缓的，那些需求是不做的，对需求池进行梳理和分类。

不同终端的需求要分开 。分为APP、PC、微官网、前台、控台这些。

三、产品迭代前写一份立项报告

通过对需求池的整理以后，你决定要做那些不做那些。需要出一份立项报告和技术部门过一下，这样技术    可以安排开发周期。技术也可以从技术的角度给一些意见说那些可以做，那些可以暂时不做，这样技术在开发之前有一个心理预期，这样在你开原型评审会的时候阻力会小很多。这里教给大家一个小技巧：做立项报告的时候可以多写一些需求，这样多一些的需求可以给技术砍。

四、竞品分析

俗话说知己知彼，百战不殆。你做的东西别人也在做，买东西都还需要货比三家呢。做竞品分析有两个目的，第一、扬长避短。吸引别人做的长处，发现别人做的不足的地方。第二、验证与测试。别人上的这个功  能市场反馈怎么样，有没有遇到啥问题，通过竞品确定市场机会点。

竞品分析有一定的流程。可以从“战略层-范围层-结构层-框架层-表现层”这几个层面进行分析。

战略层： 确定竞品的商业模式、产品定位、市场状况、盈利情况等，目的是确定方向，了解市场。

范围层： 竞品的目标人群，满足了什么需求，用户的满意度如何，目的是参考竞品的目标人群以及需求的重要度。

结构层： 竞品的主要功能架构、特色功能、发展模式，优缺点总结，目的是寻求差一点。

框架层： 竞品主要任务流程的顺畅，交互的细节，逻辑的准确，页面的框架，目的是优化流程，提高用户体验。

表现层： 竞品是视觉风格，颜色层级，文案的运用等，目的是维持用户对这类产品的传统认知的基础上打造产品独特性。

五、原型评审和PRD文档制作

竞品分析做完以后，开始根据竞品分析的结果。开始自己的功能设计，流程的绘制，在原型上加一些功能的注释，这样在敏捷开发的时候可以节省PRD文档的制作，也可以在和技术开会的时候不会遗漏自己想讲的东西。

原型评审的时候技术人员的有效意见一定要虚心接受，不要觉得自己是产品就高高在上，涉及到原则问题坚持。别人提的有益意见也要虚心接受，只有这样你才能避免死逼，项目才能尽快落地。至于PRD文档的制作。有时间的话可以写word文档，没时间的话可以直接在原型中制作文档。但文档必须包含的部分有：

1、产品版本的迭代历史。 清晰的告诉项目成员每次改变都改了那些东西。

2、需求功能清单。 有需求功能清单 的时候技术人员在开发的时候才不会遗漏，测试工程师也会根据你的需求功能单来进行测试。

3、全局结构图和重要的功能流程图不能少。 产品全局结构图相当于房子的骨架，相当于文章的目录，别人看过你的全局结构图就知道你的产品大概分成那几个部分。其次，一些重要的功能流程图需要 写，这样有助于开发人员思路的建立。

4 、异常流程要考虑清楚 。 只有异常流程考虑清楚产品经理才不会挨批，技术开发起来才不会出现问题。

5、重要名词要定义。 对于首次出现的名词需要定义，这有这样别人在看到名字的时候才不会有疑问，再跑来找你问。

五、项目管理

项目进度表。 文档交给技术开发以后，就需要制定一个项目时间表，并向领导汇报。首先要全面地收集他们在听完需求文档评审后对于产品本身的意见与建议，然后逐项予以合理的解释，以保证程序员哥哥们打心底里认同这个产品，认同这个产品的每一个需求。另外作为一个PM，也应该要对基本的开发流程有所了解在制定每个需求的开发周期时提出正确的建议，保证最终的项目开发时间表既不会拖慢整个项目的进度，也没有超出程序员哥哥们每天正常的工作量，保证他们不会感到过大的开发压力。

进度跟踪。 对于项目进度要做到心中有数，每天更新项目进度表，并帮助技术解决他们在开发过程中遇到的问题，并将自己看到的潜在问题尽量扼杀在萌芽中。当然，跟进并不是天天问工程师进度，需要给他们鼓励打气，并描述产品的未来前景，让团队中的每一个人都感受到自己的重任并愿意承担。可能有些团队里面是CTO担任项目经理，这也无可厚非，毕竟在项目成员中程序员占了大半资源，当然产品经理要尽量参与这个过程当中。不能当局外人。

六、产品上线前协助测试

大公司有明确的职位分工：工程师、测试、设计、运营都由不同的人负责，测试自然是测试工程师的事，而 在中小型创业公司，人员匮乏，很多团队只有工程师和产品经理，工程师负责开发，开发以外的事情全都由产品经理承包，这 其中自然包括测试。但无论如何产品经理都要尽量参与测试工作，保证产品是按照你的预期做出来的。

1、首先与测试组沟通协作，确定产品测试排期。

2、跟进测试进度参与产品测试。

3、将测试出来的bug记录下来，并拍好优先级，反馈给技术来发人员

功能测试是合格产品经理的必备素质，产品经理要协助测试工程师完成测试报告并敦促工程师团队改进产品。

七、产品培训和推广

给业务方培训、推广产品。 客服可能需要给用户解答问题，所以每次迭代的内容都需要给客服培训，好让客服组织话术来应对客户随之而来的一些问题。同时也需要给市场、运营等部门培训，让他们知道产品到了那些阶段，有那些改变，一是让各个部门之间知道自己正在做的事情，二也好让营销市场部门做好宣传与推广。

收集产品使用反馈，为迭代做准备。 产品上线后设计的好不好，有哪些用户满意的，有那些用户不满意的。都会有用户进行反馈，收集并分析这些用户需求，并记录在你的需求池里面，为下一次迭代做准备。

八、数据分析

产品上线后产品设计的好坏很大程度上能从数据上体现出来。例如你设计个活动分享页面，用户可以通过好友分享的界面直接注册，那么你就要统计这个页面的点击量、PV/UV、页面访问市场、访问深度、用户的跳出率、用户的转化率等来评估你设计的好坏，以及活动的效果。再比如你产品进行改版，你需要评估改版的好坏。你就需要关注30日留存率提高了还是降低了，别关注7日留存率。因为你的产品刚更新你的粉丝用户可能会很活跃，导致7日留存率变高，这个时候你说你的改版比较成功可能没有说服力，也许30日以后你的用户活跃度变低了，30日留存率也变低了。

九、总结

这就是初级产品经理的日常工作流程，每个公司可能根据自己的不同情况有些流程会有增减，但基本上是这些。

Ⅲ 原型评审要观察哪些点

在原型评审时，要对产品的用户体验、功能的完备性、设计的一致性、界面的可读性、用户的接受度进行深入的评估，以确保最终交付的产品质量。

Ⅳ 产品经理是做什么的

产品经理到底做什么?简单理解为：产品经理=策划+执行

策划=需求分析+产品方案

(1)一方面是进行需求分析

包括挖掘痛点，进行用户研究，市场分析，数据分析，需求评估等一系列工作，通过这些工作搞清楚需求到底是什么。

(2)另一方面是针对需求提出对应的产品解决方案

方案中包含产品的形态、产品的功能、实现策略、展示样式等，一般一个需求可以通过多个产品方案来解决。但是只有一个可能是最合理的，比如：和朋友沟通的需求。

执行=文档+评审会+项目管理+运营观察

接下来我们说执行的部分，在执行部分有四块重要的工作：

1. 把策划部分确定的方案形成文档，从而方便交流沟通

根据执行进度和沟通对象不同，主要包括商业需求文档(BRD)、产品功能清单、流程图、产品原型、产品需求文档(PRD)等几个文档，这些是产品执行过程中非常重要的输出物。

2. 进行执行过程中的各种沟通，主要是开评审会

在执行过程中，有大量的沟通工作，但是这些工作基本都是以评审会的方式进行，比如：需求评审会、UE评审会、UI评审会、测试用例评审会等，大家平台可能习惯私下沟通或一对一的沟通。但产品开发是个多部门协作的工作，涉及人员众多，这种方式沟通效率太低，仅仅用做补充的沟通方式。

3. 项目管理，保证项目按时高质量的交付

主要做好以下4点基本上就可以了：

(1)开发排期

(2)跟进答疑

(3)异常处理

(4)产品验收

4. 运营观察，验证假设并挖掘新的需求

产品上线是产品工作一个阶段性的结果，整体产品目标的实现，还要靠后续的运营来实现。所以在产品上线后，并不是万事大吉了，产品经理要对运营的过程进行观察，包括用户使用行为、习惯、数据等进行了解，尤其是对运营数据的收集分析，不仅可以从中去验证自己的假设，而且也可以发现问题，作为下次迭代的需求的来源。

Ⅳ 产品经理主要工作流程是怎样的

一、产品经理的需求来源

产品经理一切工作的本源是：需求。所以我们从需求来源开始讲起产品经理完整的工作流程。互联网需求来源一般有：

1、产品需求：产品经理通过数据分析、用户调研、竞品分析等方法验证通过的需求

2、运营等业务部门提交的需求：比如以京东为例，服饰业务部/生鲜业务部/家电事业部的运营、采销等人员出于提升业务指标的角度会提出各种需求

3、老板的需求：领导从外部合作的角度或者产品战略的角度也会给手下的产品经理提一些需求，比如我还接到过大Boss和老板娘的需求

4、Bug修复等：在工作中修复BUG是一件比较常见的事情，影响面大的BUG会走紧急修复流程，不太严重的BUG会走迭代排期。

二、需求池的管理

通过以上几种方法收集到的需求会统一放到需求池中。需求池大家可以理解为所有需求的集合（包含待确认、设计中、带排期、开发中、已上线等所有状态）。

一般来说，使用execl表格管理需求池即可，按照各种需求状态进行分类展示。

三、需求优先级

我们需求池的需求会非常多，但是每个迭代的时间是有限的/研发资源是有限的，所以导致我们只能从需求池中挑选出少量需求进行开发，从而诞生了需求优先级的概念。

一个迭代中肯定有限做优先级高的需求！

那如何排定需求优先级呢？

一般来说有两个场景：

1、从0到1设计一款产品

这种场景下的需求来源基本上都是产品需求。建议大家去了解一下KANO模型，这个场景下的需求优先级一般来说是：基本型需求>期望型需求>兴奋型需求

2、在原有产品基础上优化

这种场景的需求来源会非常广泛，可能之前讲到的4中来源都是涉及，那如何排定需求优先级呢？一般按照产品价值和实现成本两个维度。

产品价值可以分为两类：业务价值和用户价值。

价值定义：

• 业务价值：对应商业类产品，称为商业价值，体现在能给业务带来多少收益。

• 用户价值：对于使用者来说，能给他带来的价值，比如说能减少操作步骤。

在这种方法下，优先级的排序逻辑是：产品价值大实现成本低>产品价值大实现成本高>产品价值小实现成本低>产品价值小实现成本高。

四、需求确认

当梳理完需求优先级之后，我们就按照开发工作量挑选优先级高的功能组成新版本/新迭代周期的需求列表。

梳理完需求列表之后一般要跟直属领导当面沟通一版，这叫需求确认。在这个阶段要做好挨批、被怼的准备。领导会从各个维度“挑战”你需求的合理性。所以大家在需求评审前一定要多思考几遍，尽量多用客观数据去说服领导。

如果需求确认通过，会进入到产品设计阶段。

五、产品设计

产品设计阶段会包含如下几个小阶段：

1、使用产品脑图梳理产品/功能结构框架，特别是对一些逻辑复杂的新产品/新功能。

2、使用产品流程图梳理产品/功能核心业务逻辑。流程图的梳理尽量详细，各种异常场景的判断一定要在流程图中有所体现。对于涉及多个参与方业务，可能还要梳理泳道图。

3、使用墨刀/axure等原型工具输出产品原型。原型是产品逻辑的可视化表现，也是产品经理最最基本的基本功。

4、撰写产品说明文档（PRD）。PRD是产品详细逻辑的最终呈现，也是内部沟通的标准文档。PRD撰写完成之后就可以进入到需求评审阶段

六、需求评审

需求评审是指产品经理要向UI、交互、研发、测试等内部人员讲解产品逻辑，保证产品逻辑在内部传输过程中不失真。

需求评审的过程中，有4点需要注意：

1、评审的时候，先讲需求背景。即这一版本为什么要做这需求？做完以后预计会达到什么效果？让相关参与方从心理上认同做这件事的价值。

2、在讲具体需求的时候，按照对应的责任人进行拆解。比如在讲解功能A的实现逻辑时，我一般会说客户端需要完成的内容是1、2、3；服务端需要完成的工作是1、2、3；算法侧的工作是1、2、3等等。

3、存在争议的地方先记录下来，评审结束后再细化。

4、就是评审结束以后要追排期。即作为产品经理你要盯着研发Leader，设计Leader，测试Leader让他们出需求排期，以此保证项目按时上线。

七、项目管理

需求评审完成之后，项目经理（大部分公司由产品经理担任）会输出详细的项目排期表，然后项目所有相关人员会按照项目排期表有条不紊的协作。项目管理的详细流程如下：

八、数据分析

产品上线之后，产品经理要做好产品分析工作，以验证产品/功能是否达到预期目标。特别是产品上线7天后，产品经理需要想全体组员发送产品上线数据报告。

如果数据不达预期，就要进行深入的分析内在原因是什么，然后数据分析的结论很可能是下一迭代的需求来源，从而开始一个新的迭代周期

Ⅵ 产品经理的相关说明

用心：对自己对产品负责任
同理心：从用户角度出发
处处留心
没心没肺：脸皮要厚，不要怕人骂 同程序员不一样，产品经理主要是同人打交道，要组织处理好很多复杂的关系和工作。良好的沟通能力、组织协调能力、资源运用能力、推动和协调各部门的合作和有序进展，是一个产品经理需要具备的综合能力。所以做好产品经理并不是一件容易的事情，很多方面的素质培养是必不可少的。
产品经理要协调好各种关系，包括研发、测试、文档、市场、销售等部门的人，在保证品质的情况下如期的推出产品。任何事情都是靠人实现的，所要协调的主要是人力资源，绝不能因为要完成一个OEM的项目而占用所有测试人员的时间。不同部门的沟通并没有多大的区别，但不同部门的Leader做事方式可能不一样，因此一方面要看对方配合的程度高低，同时要学会在恰当的时候和恰当的人谈恰当的问题，只有解决好问题才能有效的将事情向前推进。尤其是在没有下属关系的情况下，人与人的互动上，要做的非常好，能够把自己的想法非常好的表达给其他人，说服这些人配合去做事。
产品经理的工作是相当琐碎的，要处理各种各样的关系和进度，不像其他的工作都有自己专注的方向，专业的领域。所以如何在一天之内高效的做事就显得尤为重要。
围绕目标市场、市场调查、市场定位、市场细分，通盘考虑产品、价格、渠道、促销、公关、服务这些因素是开展营销工作也是产品管理的一项很重要的工作。所谓市场感觉，更为重要的是如何能够通过市场现象去生成一些战略，而不是对方降价自己也降价，对方做广告自己就做广告。所谓战略，就是从产品定位、用户定位、价格和竞争对手入手，了解各自的强项和弱项，找到机会在哪里，威胁在哪里，并进行分析，制订未来的战略。这些素质不是通过看市场宣传和汇报就能够获得的，它需要很多的信息反馈分析，要靠经验和感觉。
作为一个产品的负责人，产品经理的压力是很大的。尽管在某些公司，产品的成败不一定和产品经理的收益挂钩，但如果某些方面考虑不周，做出来的母盘存在问题，造成整批产品销毁，给公司带来巨大损失，或者因为某些原因没有和一些人员沟通好或者安排好时间，结果造成问题，产品无法如期交付，产品经理还是有“罪魁祸首”的感觉，这些都是压力所在。
产品经理需要有独立解决问题的能力和动力，要把产品看做自己的孩子，怀着热情和激情去做事。这种热情决定他是主动的，而不是被动的去做事，是为了不断提升自己的价值和能力。
技术可以学习，素质却难以培养，有些素质是成功的产品经理必不可少的。
有这样一群人，他们对产品有一种本能的热爱，把自己生活中的一切事物都看成产品，怀揣对优秀的产品的热爱和尊重。这份热情是产品经理必备的素质，是他们夜以继日克服困难、完善产品的动力。这份热情能感染团队成员，激励所有人。
辨别这种特质很容易，可以让应聘者谈谈自己最喜欢的产品及喜欢的原因，聊聊不同领域的产品和他讨厌的产品，问问对方，如果有机会，他打算怎样完善自己最喜欢的产品。热情是难以伪装的，虚伪的做作容易毕露无遗。
理想的产品经理不一定来自产品的目标市场（这种情况有利也有弊），但是他必须融入目标市场。这一特质对制造大众产品的高科技企业尤为难得。我们倾向于从自己的角度去理解用户和市场。事实上，目标用户的经验、喜好、价值观、知觉能力、忍受程度、技术理解很可能与我们的大相径庭。
可以就产品的目标市场向应聘者发问，让他谈谈如何换位思考。了解应聘者对目标市场的感觉，最重要的是看对方是尊重目标市场希望融入其中，还是打算一意孤行改变用户习惯。
对国际化的产品和针对特定地域的产品来说，换位思考尤其重要。各种文化虽有共通之处，但也存在许多差异。有些差异对产品无关紧要，有些则至关重要。应该考察应聘者是否足够了解目标市场，能否区分这两种差异。
人的智力水平是无法替换的。产品管理需要洞察力和判断力，因此必须具备敏锐的头脑。勤奋当然是必需的，但从事这项工作光有勤奋还远远不够。
招聘聪明人是项知易行难的任务，结果在很大程度上取决于招聘者的能力和可靠性。常言道，“物以类聚，人以群分”，此言不虚。方法之一是测试应聘者解决问题的能力。微软令人称道的、深入而有效的面试，即是考察应聘者解决问题的能力，通常由一位或多位领域专家就一个问题对应聘者进行深入考察。面试官不关心应聘者是否知道正确答案，而看重应聘者解决问题的思路和方法（智力优于知识）。如果应聘者回答正确，面试官会将问题略作调整，询问应聘者在新情况下如何应付。重复这个过程，直到应聘者被迫处理他不知道答案的情况，说出解决方法。
每种团队角色承担的义务和付出的努力都不相同。产品经理肩负着产品的前途和命运，绝不适合贪图安逸的人担任。即便掌握了时间管理和产品管理的技巧，产品经理依然要为产品投入大量精力。成功的产品经理能拥有时间享受清闲的家庭生活吗？只要具备足够的经验，我相信可以做到。但是，如果你期望的是一周只工作四十个小时，下班后把工作抛诸脑后，那是不现实的。
成功的产品经理需要付出多少努力？在这个问题上，我对应聘者向来坦率，产品管理工作绝不能用时间来衡量，付出多少都不为过。紧急情况下临时找来的“救火队员”多半不是合适的产品经理人选。
在漫长的项目周期里，产品经理需要付出的努力和承担的义务并非一成不变。有的阶段比较轻松，有的阶段则很紧张。但是称职的产品经理对产品的关注和忧虑程度，以及愿意为之付出努力的热情是不会改变的。
在所有产品团队成员里，产品经理最能体现公司和产品的价值观。通常产品经理不直接管理团队成员，不能要求别人执行命令，所以他必须通过行动影响、说服身边的同事。这种影响基于相互的信任和尊重，要求产品经理必须是个正直的人。
产品经理是产品团队、销售团队、公司高管之间的枢纽，经常要协调处理各种问题，比如提早供货、满足大客户的特殊要求。产品经理如何处理这些难题，同事们都看在眼里。
信任和尊重需要时间培养，产品经理唯有通过工作展示自己的素质和能力，才能成为真正的团队领导。如果产品经理对待同事缺乏诚意，怀有私心，一碗水端不平，那么势必会影响整体团结的工作效率。产品经理虽然不必事事精通，但应当知道每位成员最擅长做什么，尊重大家发挥工作特长的意愿，充分信任大家。
考察一个人是否正直绝不比考察他的智力容易，考察陌生的应聘者是否正直就更难了。对那些有工作经验的应聘者，可以问问他们如何处理工作中的压力，多追问工作细节。
很多人相信经验可以让人产生自信。如果仅凭经验可以建立信心，为什么许多工作多年的产品经理却毫无自信？相反，刚刚步入社会的大学毕业生却往往充满自信（虽然这种自信通常源自对自身状况的无知）。
自信是很重要的素质。公司高管、产品团队、销售团队都需要看到产品经理的信心，确信他们投入的时间、金钱、努力不会付之东流。自信的人更有说服力，更容易成为人们愿意追随的领导者。
称职的产品经理把自己当成产品的CEO，愿意为产品的最终成败承担全部责任，绝不找借口。虽然他清楚产品按时成功上市要克服许多困难——开发难度大、开发时间长、成本过高、产品复杂等，但他明白预见和解决这些问题是他的责任。
这并不是说产品经理要事必恭亲，监督每个人的工作，而是指出现问题时他应该及时承担责任，进展顺利时他应该及时给大家以鼓励。称职的产品经理知道，虽然产品的实现离不开大家的协助，但是他应该对自己的产品创意负责。
掌握一些重要的技能是打造成功产品的关键。我相信，只要具备优秀的个人素质，所有技能都可以习得。
很多成功的产品经理是工程师出身，因为策划产品在很大程度上取决于对新技术的理解，以及如何应用技术解决相关的问题。
出色的产品经理并不需要自己发明或实现新技术，但必须有能力理解技术、发掘技术的应用潜力。
培养理解技术的能力有多种途径，可以参加培训课程，阅读相关书籍和文章，向程序员和架构师请教，参加开发团队的头脑风暴也不失为一种途径。
产品经理要优先解决重要问题。研发产品的过程中有很多干扰。能否集中注意力解决关键问题、克制不断增加功能的冲动、不受关键人物或重要客户的影响，取决于产品经理是否有足够强的自律性——不但要遵守公司制度，还要严格要求自己。
几乎所有产品都有些不那么重要的功能——这些功能对提高销量和用户满意度毫无作用。如果去掉这些功能，产品甚至会因为简单、易用获得更多用户的喜爱。
电子邮件、即时消息和手机构成的世界充满了干扰。你可能一大早就来上班，拼命工作一整天，连吃饭喝水都顾不上，深夜回到家却发现到头来没完成一件重要工作。时间都用来“救火”和处理“紧急”事件了。
熟练、迅速地区分重要任务和紧急任务，合理地规划和安排时间是产品经理必备的技能。如果产品经理无法集中精力完成真正重要的任务，那产品就难免命运多舛了。
每星期工作七十个小时、累得精疲力竭的产品经理。他们把所有的时间和精力都花在工作上，体力透支到了极限。对他们而言，最可怕的事实莫过于做的都是无用功。为此，我有意在培训课程中加入了时间管理和合理安排工作任务的内容。产品经理的时间应该用来改变现状，而不是疲于奔命参加大小会议、逐一回复邮件。有许多事情不值得做。
作为产品团队的发言人，产品经理要协调团队与财务部门、营销部门、销售团队、公司高管之间的工作——必须使用这些人听得懂的概念和术语。
我认为产品经理应该具备双语技能。这并非指中文和英文，而是指产品经理既能与程序员讨论技术，又能与管理层和营销人员讨论成本结构、边际效应、市场份额、产品定位和品牌。 教育培训
产品经理是要负责产品的整个生命周期的所有事物，因此产品经理需要有产品研发阶段相关的技术知识。在软件开发领域，产品经理一般是研发出身，接受过市场营销相关培训。
工作经验
产品开发及其管理5年以上工作经验，具备良好的资源整合能力、沟通协调能力和书面报告能力，具备独立解决问题的能力和较强的市场分析能力，对产品和数据运营敏感，思维清晰而有条理，能承受较大的工作压力。 对于大公司而言，产品经理是一个非常重要的角色。因为产品经理要负责整个产品的成败，所以从研发到生产到销售，产品经理都有权进行干涉。但是在小公司境遇就不尽相同，权力会相对小一些，但是产品经理对于提高自己的创新能力，选择创业是非常有帮助的。产品经理一般由产品专员发展而来。
在战略层面需要考虑的内容
在产品规划和执行层面
产品开发团队管理
产品实施和推广
因为不同公司对产品经理/产品设计师的职责要求不同，所做的事情也并不相同。但至少要达到所在公司的要求，这才是首先应该做的事情。 原型制作：Axure，Mockplus,fireworks，Photoshop，mockingbird（web）,Balsamiq Mockups,omnigraffle等，区别去其他的原型工具，Mockplus兼具审阅功能，更加方便了设计，提高了工作效率。
项目管理：PriciseProjectManagement（PPM），Project（微软产品），Todolist，Excel，Sheet，Gcalendar，Google task，trac，outlook
在线协作：SVN，Google Docs,Mockplus
测试反馈：TestCenter，QC,Jira,Bugzilla，Firebug、TestDirector、IETester
需求池管理：Mantis
团队交流：QQ，outlook，MSN，GTalk，画声（精准沟通）
工具推荐：多用下载
笔记软件：Evernote（印象笔记），Onenote（微软产品），麦库，有道云笔记，为知，轻笔记
代码编辑：Editplus，UltraEdit，Sublime Text 3，Textmate，Notepad

Ⅶ 产品经理日常：刚接到一个新需求，应该怎么处理

作为产品经理，接收需求简直是我们日常工作中再基本不过的事情了，只要和你有交集，都有可能产生需求，有可能是用户直接反馈的需求，也有可能是公司运营、市场等部门同事给你反馈的需求，也有可能是老板直接给你提的需求，当遇到这些需求的时候，我们应该怎么去做呢？

我们首先需要去判断下这个需求的真伪，接下来根据我们分析需求的优先级进行排序，让我们的产品围绕核心目标朝着一个健康的方向不断进行迭代。中间最关键一点就是要做好沟通反馈，不然给你反馈需求的人会认为你没有重视起来，对于需求方来说会产生很多负面情绪，所以这一点一定要重视起来。

接下来，我们再来聊聊怎么去分析需求，或者说怎么去判断需求的真伪，我们知道在设计某个功能的时候，就是为了解决用户在某个场景下所发生的需求，从而解决这些问题，这个功能才会存在价值。那么，如果用户提的需求我们理解的不正确，设计的功能很可能无法真正解决问题，甚至仅仅是解决了用户的表面需求，出现功能做了，用户也不会去用，导致我们时间和精力都浪费了，最后的结果也不太令人满意。

那么，当我们遇到需求的时候，是否应该立即去处理呢？

我建议应该这样去做：

1. 用户为什么会产生这个需求？

当需求方向你阐述完某个需求后，向他询问：提这个需求的目的是什么？即为什么会产生这个需求？这个问题可以帮你完全理解需求，并辨别需求的真伪。

2. 用户在什么场景下会使用这个需求？

即搞清楚什么人在什么情况下会用到此功能。明白了这个，才知道如何更好地设计功能来满足需求。

3. 是否有可能衍生出新的场景？

为了避免设计的功能因扩展性不足，后期推翻重来，在一开始，就应该做尽可能全面的考虑。通过需求方的场景，扩展思考，是否存在衍生的场景。思考的过程，也是帮助你抓住和理解需求本质的过程。

4. 技术层面如何看待这个需求？

接到需求，并充分理解了需求后，跟相关技术负责人花几分钟时间讨论一下，听听他从技术上对需求的考虑。通过此过程，你们基本会对需求点及实现方式达成共识，在后期正式开发时，阻碍会小得多。

5.做了这个需求对用户有什么影响，以及用户对这个需求的紧急和重要程度是怎么样的？

一定要问清楚，处理这个需求对用户的有利影响和不利影响是什么，从而判断需求的类型，以及紧急重要程度，最后一定要多询问一句，需求方对这个需求的紧急重要程度的认知，避免我们分析完需求的紧急重要程度和需求方理解的不一致，导致最后出现矛盾。

那么，当需求方对需求不明确的时候，应该怎么处理呢？

我建议这样处理：

1.最直接的方式，谁提出的需求，找谁搞清楚需求，最好让需求方把场景描述清楚，还原需求的真实使用场景，有助于帮助我们来更好的理解需求，有可能需求方调研清楚以后，该需求可能就不会存在了。

2.如果需求方也说不清楚自己想要的是啥，在你听完他不清晰的描述后，利用你的专业技能，帮他梳理，并跟他确认，你的想法是否正确，是否就是他想要的

3.向对方提问题是搞清楚一件事情最好的方式，或许可以尝试这么问需求提出者：什么人在什么情况下会做什么事？你现在实际操作中觉得哪里是最困难不方便的？你觉得最好的操作方式应该是什么样的？类似这类问题，既是帮你搞清楚问题，也是帮对方梳理思路。

当需求明确后，后续的工作流程就会清晰很多，我们做个复盘，来看下我的工作流程：

第一步 ，与需求方进行沟通，主要是复述你接收到的需求，确保需求接收正确没有存在理解偏差。

第二步 ，我把它叫做清洗需求池，把接收到的需求进行清洗，分类出那些是已有替代功能完成了的，哪些是在之后的版本中有规划的了，哪些是与公司战略及产品目标不符合的需求，哪些是可以在这个版本加入的需求，同时评估需求的可行性、优先级、难易度。

第三步 ，将上述第二步的结果形成文档，并提交需求方，最好是自己亲自讲解，获取需求方的同意。这一步至关重要。

第四步 ，需求的具体分析，梳理逻辑关系，业务流程。

第五步 ，进行原型设计，如果需要出PRD，再这个阶段也一块进行输出。

第六步 ，开原型评审会（就是我们常说的kick-off会议），与UI、研发一同沟通需求及PRD，对会上的东西进行及时的补充和改进。

第七步 ，跟进UI设计稿，确认设计稿。

第八步 ，协助研发开发，开始编辑测试用例和测试文档，并准备种子数据（如果有测试，就协助测试完成，如果没有，就自行完成）

第九步 ，测试，验收产品

第十步 ，上线，交付产品

以上流程中有的阶段可能会反复进行，最为重要的就是我们的沟通能力，下期我们继续讲解如何提高沟通协作能力，最后还是希望大家持续关注，微信公众号中搜索“小宝谈产品”，让我们一起在产品和运营的路上不断前行～

Ⅷ 我想当一名产品经理，应该如何入行

深圳某互联网公司产品经理，也是从小白做起，对着话题感触颇深。

首先，你要明白产品经理的也是分责任范围的，选品讨论，竞品报告，设计开发，沟通协作。包含很多硬实力和软实力，不了解的可以看看这篇回答。

那在这里，我就选择其中一个我觉得难一些的模块,给大家进行分析。关于怎样开发一款APP。

对于产品经理来说，app的模板肯定是由技术人员打造，我们就是与甲方协商写出合理的要求，并规划其未来发展。

第一步，就需要我们观察市场，评估市场，初步给出合理·业务方案。 关于需求调研的方法，这篇写得很细，有需要的自己去学习

第二步就是与原型评审沟通，制作产品原型图，我建议用思维导图去梳理，这样效率会更高。

第三部就是原型定版后，编写PRO文档和绘制流程图，与程序架构师沟通代码和数据库框架，与UI深度沟通产品视觉主题风格。

最后一步就是整体测试，进行线上试运营。

当然每一步针对不同的APP都有不同的办法，看起来文字很简单，但实际操作起来是有难度的。 对于成熟的产品经理来说，你也是个最基础的程序员和UI。因为你有这两项的基础，你才能跟专业人员进行合理沟通。

但很遗憾是小白入职时基本上是不懂这些的，所以如果你能学会你的筹码会更大些。我们公司在进行员工内训一般都会用PUMP家的课程，分析的很精简，一周左右就会有效果，毕竟企业不会等你成长。

暂时就说到这里了，祝大家都能找到心仪工作。

Ⅸ 产品经理是做什么的

产品经理是贯穿产品整个生命周期的重要角色，从设计、开发到后期的维护推广都离不开产品经理的串联沟通。

1. 客户沟通：产品立项阶段需要确立客户群体，与潜在客户沟通。

2. 需求分析：立项以后做竞品分析，客户需求梳理等工作，确立产品的需求范围和功能特点。

3. 产品设计：协助设计人员做产品设计工作，对产品原型进行评审与分析。如果需要，还要拿产品原型与客户沟通，修正产品的需求。设计完成需要与开发人员讨论方案可行性与成本等问题。

4. 开发进度管控：跟踪产品开发进度，保证产品开发按计划执行！

5. 产品测试

6. 产品发布与升级
   

Ⅹ 产品经理必备技能 | 如何画原型

产品经理当然要会画原型啦~

聊聊怎么画原型吧！

在画原型之前，更重要的事情，就是画 页面流程图 和 信息架构图 ！假如你没有这些东西，就开始画原型，那么等着你的就是没完没了的改改改。

页面流程图是以用户视角，看流程合理性。通常适合于跳转比较复杂的产品功能，如电商、社交产品。

为什么要画页面流程：

（1）是交互设计/原型设计的基本依据，是逻辑基础。如果你都没想好页面流转的顺序，那么你画的原型一定不是可以确定下来的版本

（2）代表了用户的操作过程，先画页面流程图能迅速发现体验问题。有了页面流程图，你可以设身处地想象用户在使用产品时的操作流程，发现其中可能出现的问题

（3）突出页面重点元素与逻辑关系，提升原型的设计效率。很多页面不是全新页面，而是在原有页面做一些修改，如果你知道页面流转顺序，那么会给你画原型减轻很多工作量

页面流程图包含：

（1）四方形：业务流程中的四方形部分，异常流程或弹层通常用菱形表示

（2）流向：主干流向和辅助流向

（3）重点元素：每个流程中，重点要体现和表达的内容是什么

画页面流程图的工具：

（1）Axure：画了页面流程图可以紧接着画原型

（2）ppt：方便讲解

需要注意的地方：

（1）回归业务流程，明确主线：页面流程一定来自于业务流程，一般为业务流程中的方形部分。异常流程一般为弹层或弹窗提示。业务流程画的好，页面流程就简单。

（2）明确页面中的重点元素：功能在页面中，有哪些是需要表现元素。增加异常流程的处理逻辑。增加辅助的帮助页面。考虑下游触发点（按钮/链接/滑动...)。

（3）沟通与优化：首先要尽可能穷举涉及的页面，然后做减法，有些页面合并或删除。通过原型草图，优化调整页面关键元素。与UI、UE、前端研发多沟通会有更好的效果。

页面流程图一般规则：

页面流程图例：

一个具体案例：

业务流程：

页面流程：

主要是分离出了普通用户的操作流程，加异常处理。

对于普通用户的关键页面和关键流向：

页面流程图：

（1）分离出5个页面，确定流程流向

（2）固定元素，例如在“1购物车”中，“提交订单”就是下游触发点，点击后流向下一个页面；在“2输入优惠码”中有关键元素“填写优惠码”，另外还有下游触发点“确认订单”...

（3）针对每个页面去画对应的原型图

信息架构图，以产品视角，看包含多少功能点。适合于层级分明的，如音乐产品、新闻客户端、阅读类产品等。

信息架构图例1：

有了页面流程图或信息架构图，现在终于可以开始画原型啦。首先，什么是产品原型设计？

产品原型 ，俗称 线框图 ，大概就是草图的意思吧。它是产品落地的关键点，是从虚拟概念到用户接触的节点。同时也是产品经理产出的关键内容，上传下达，上给老板，下给UI、UE同事。

产品从原型到上线的流程：

大公司的产品经理只需要做手绘和低保真的部分，小公司可能还要兼职交互设计...

案例：

好的原型有什么特点：

（1）整体：页面结构清晰、跳转关系明确、与业务流程一致、完整表达用户需求

（2）独立页面：功能元素明确有序、位置关系清晰、不同状态变化清晰

（3）交互设计：清晰的交互逻辑、一致交互方式、界面统一

常用工具：

（1）纸笔：自己画画，快速学习和定位

（2）白板：多人讨论

（3）软件Axure/Sketch/墨刀：产出正式文档

案例：

（1）研究流程：业务流程->页面流程

（2）确定页面框架：大概确定页面布局和大的框架

（3）画原型：画模块，确定交互细节

注意事项：

（1）尽可能用真实比例、真实文案，使元素更真实，也避免在需求评审时被之一。尽可能真实模拟极端情况，并示例清楚。
（2）紧扣需求主体，不横生枝节。如果原型需要增加新功能，一定要是来源于需求，并且要考虑后端数据来源。

（3）不要上颜色！原型就用黑白灰，不要给UI、UE挖坑

（4）目录树清晰，阅读流畅

（5）保存修改记录，关键修改重新保存文件

画/改原型的时间尽量控制在20%工作时间之内，否则就要问问自己是不是哪里出问题了哦。

产品需求想明白了没？？？

产品流程理清楚了没？？？

手绘草图画了没？？？

手绘草图和Boss确认了没？？？