产品经理工作流程？
2024-05-20 03:37
1. 产品经理工作流程？
产品经理是企业中专门负责产品管理的职位，产品经理负责市场调查并根据使用者的需求，确定开发何种产品，选择何种技术、商业模式等。我给大家整理了关于，希望你们喜欢! 一、使用者调研 使用者调研分为定性分析和定量分析。定性分析是指使用者访谈，定量分析是指调查问卷。 使用者访谈。当然访谈需要一定的技巧，更多的倾听为主，以了解使用者的内心想法为主。访谈时对使用者的初步回答反复追问“为什么”，引导使用者从表面的行为开始思索，清理出行为背后的动机、需求乃至价值和文化观念。 调查问卷。问卷调查是一项有目的的研究实践活动，设计的问卷是为你的特定研究目的服务的，这是设计问卷之前必须植根于脑海中的一个观念。既然问卷调查是一项有目的的研究实践活动，那么从理论指导实践的角度出发，在设计问卷前必须要做好充足的理论准备，巨集观层面上应做到以下两点：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日留存率也变低了。 九、总结 这就是初级产品经理的日常工作流程，每个公司可能根据自己的不同情况有些流程会有增减，但基本上是这些。 产品经理在团队角色 在产品管理中，产品经理是领头人，是协调员，是鼓动者，但他并不是老板。作为产品经理，虽然针对产品开发本身有很大的权力，可以对产品生命周期中的各阶段工作进行干预，但从行政上讲，并不像一般的经理那样有自己的下属，但他又要调动很多资源来做事，因此如何做好这个角色是需要相当技巧的。 如果把产品开发当做赛艇运动，在最前面擂鼓喊号的是产品经理，他不但要每个参与者都使足力气，而且要协调所有的参与者，将他们的力气往一处使，他还要保证所有人的方向都是一致的，都知道朝哪个方向走，不能出现有人用力不对的情况。 在很多企业里面，会跨越行政管理的部门，以跨部门的虚拟产品团队方式来运作，产品经理是这个虚拟团队的Leader，虚拟团队的其他人大部分都不是全职只负责这部分工作，但是有约定比例的时间投入。根据公司的情况，也可以约定产品经理对每个虚拟团队成员在这部分的工作表现进行考核。 在快消领域产品经理的角色更侧重于产品***生命周期***管理和品牌推广。而在研发生产型企业里，产品经理的角色通常要关注生产的周转率、产品的故障率、版本更新情况、推广计划、财务资料等方方面面的事情，对产品经理的个人能力要求也更强。 而在网际网路领域，产品经理通常最关注使用者价值，使用者体验，以及与使用者体验相关的所有事情，都需要产品经理发起或者参与。在一些网际网路公司里，商业模型和财务部分的核算有单独的商业产品经理负责。
2. 产品经理的完整工作流程
初中级产品经理的完整工作流程
一、用户调研
用户调研分为定性分析和定量分析。定性分析是指用户访谈，定量分析是指调查问卷。
用户访谈。当然访谈需要一定的技巧，更多的倾听为主，以了解用户的内心想法为主。访谈时对用户的初步回答反复追问“为什么”，引导用户从表面的行为开始思索，清理出行为背后的动机、需求乃至价值和文化观念。
调查问卷。问卷调查是一项有目的的研究实践活动，设计的问卷是为你的特定研究目的服务的，这是设计问卷之前必须植根于脑海中的一个观念。既然问卷调查是一项有目的的研究实践活动，那么从理论指导实践的角度出发，在设计问卷前必须要做好充足的理论准备，宏观层面上应做到以下两点：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日留存率也变低了。
九、总结
这就是初级产品经理的日常工作流程，每个公司可能根据自己的不同情况有些流程会有增减，但基本上是这些。
3. 产品经理的工作流程
产品经理是企业中专门负责产品管理的职位，产品经理负责市场调查并根据用户的需求，确定开发何种产品，选择何种技术、商业模式等。我给大家整理了关于产品经理的工作流程，希望你们喜欢!
产品经理的必备技能 1、一个成功的产品经理的能力中应该有35%的项目管理能力。
在项目管理方面，而且这35%的能力包括团队合作的能力。好的产品经理首先是成功的项目经理，项目管理的经验对于产品经理十分重要，可以帮助产品经理更好的进行产品的管理，团队合作的经验和能力可以让产品经理在产品的团队比较好的处理团队内部的人员关系和团队的其他情况。
2、个人的能力占15%。
成功的产品经理应该是成功的领导人，他的个人能力包括他的领导能力，个人的情况和能力以及他的个人的亲和力。个人的能力可以帮助产品经理更好进行产品过程的管理。
3、产品经理的业务能力占全部的20%。
产品经理的业务能力包括专业的业务管理技能。
4、产品经理的技术能力占全部的15%。
技术能力对于产品经理是必备的技能，技术能力让产品经理更好的理解产品的性能和特点，更好的进行产品的团队管理。
5、产品经理的沟通和处理冲突的能力占全部的15%。
产品经理应该领导项目组，指导产品从概念设计到市场接受，保证实现设计、收益、市场份额和利润目标，解决项目组的冲突;同时产品经理还应该管理项目，制定项目的计划和预算，确定和管理参与项目的人员和资源，同职能部门之间相协调，跟踪相对于项目基线的进展;产品经理还要负责和管理层进行沟通，提供项目进展状况的报告，准备并且确定状态评审点，作为产品的领导同管理层沟通，提供对项目组 成员的工作绩效评审的输入材料。
一个成功的产品经理通常在一个或多个职能部门从事过管理和操作方面的工作经验，并有管理项目开发的经历。产品经理可以来自财务、R&D、市场等任何部门。产品经理富有项目管理经验很重要，产品经理最好具备项目经理的任职资格证书。
产品经理的团队角色 在产品管理中，产品经理是领头人，是协调员，是鼓动者，但他并不是老板。作为产品经理，虽然针对产品开发本身有很大的权力，可以对产品生命周期中的各阶段工作进行干预，但从行政上讲，并不像一般的经理那样有自己的下属，但他又要调动很多资源来做事，因此如何做好这个角色是需要相当技巧的。
如果把产品开发当做赛艇运动，在最前面擂鼓喊号的是产品经理，他不但要每个参与者都使足力气，而且要协调所有的参与者，将他们的力气往一处使，他还要保证所有人的方向都是一致的，都知道朝哪个方向走，不能出现有人用力不对的情况。
在很多企业里面，会跨越行政管理的部门，以跨部门的虚拟产品团队方式来运作，产品经理是这个虚拟团队的Leader，虚拟团队的其他人大部分都不是全职只负责这部分工作，但是有约定比例的时间投入。根据公司的情况，也可以约定产品经理对每个虚拟团队成员在这部分的工作表现进行考核。
在快消领域产品经理的角色更侧重于产品(生命周期)管理和品牌推广。而在研发生产型企业里，产品经理的角色通常要关注生产的周转率、产品的故障率、版本更新情况、推广计划、财务数据等方方面面的事情，对产品经理的个人能力要求也更强。
4. 产品经理的详细工作流程
互联网的产品汪们，你们是不是经常被人问起：“产品经理主要是干什么的？”，甚至一些不明情况的亲朋好友会认为产品经理应该是部门经理之类的。那我们知道其实产品经理主要是负责一个产品的0~1、1~∞，这么一个流程，也就是产品的整个生命周期，产品经理是都要参与进去的。
下面的这个脑图，可以让大家对产品经理的工作内容，有个整体的认识。也方便大家对接下来的文章内容有个初步的心里预期。
接下来我会按照产品开发流程的顺序，来介绍产品经理需要参与的工作流程有哪些？不同公司、不同业务实际开发中某些流程会有所区别（会出现多个流程同时进行的情况，根据项目实际情况协调）
一、市场分析
市场分析的目的是为了验证我们的想法是否合理，市场分析的原则一定是客观公正的。由此我们才能更好的了解市场需求、用户需求、对需求去伪存真！
PS：其实有很多公司在开发产品时没有做市场分析这一流程，原因是要想真正的做好市场分析在短期内是不可能的，需要做大量的数据分析、调研等工作，要有资金、人力、物力的投入，况且市场变化多端，时机不等人，公司往往会选择用这部分资金去试错，在试错过程中调试、完善自己的产品，使产品更加符合市场及用户要求。如果您负责的产品不涉及这一流程可直接从第二个流程，需求分析开始阅读。
（1）市场调研
主要是从宏观上分析该行业未来的发展趋势与空间大小， 我们可以采集一些行业数据进行分析验证，例如：观察近五年用户增长率、媒体曝光指数、发展趋势图等等，可以去不同的平台查看数据，保证数据具有客观性。其中艾瑞网、百度指数、易观网、千观易凡、七麦数据、等都是常用的数据分享平台，当然如果想查看近两年的数据，一般都需要收费，主要看公司是否愿意在这个环节上投资了，如果找不到近期的数据，分析以往数据即可，我们主要看的也是一个大的趋势。
（2）竞品分析
竞品选择不要过多，要做深度分析。产品不同时期，竞品选择标准也有所区别，例如：可以选择对标竞品（一般是行业标杆）、核心功能相似的竞品、小众竞品（对于一部分用户，粘度较高的产品）、间接竞品等等。通过竞品分析了解用户的共性需求、差异化需求，为PM做需求分析时提供参考依据。
（3）用户研究
通过市场分析、竞品分析，更加了解我们的用户群体。初步形成用户画像、以及用户在不同场景下使用产品时的初想。用户研究中我们常用的方法：用户调查问卷、代表性用户访谈、随机性抽查等等，通过这些操作了解用户的喜好、年龄、性别、地区、职业、消费能力等特点。充分了解目标用户群体特性，有利于PM设计出的产品，更加贴合用户心里模型。
二、需求分析
开发一款新产品时往往是领导有一些好的想法、有一些可以对接的资源、想去开发一款什么样的产品。这个环节PM会参与和领导一起讨论，发表自己的看法，帮助领导梳理需求，最终给出落地的方案。这个不是一次会议就能够完成的。
三、需求评审
PM需要组织UI、前端、开发、运营等人员参与评审会议。这个会议由PM主持，首先介绍背景（开发产品的目地、现有资源、核心功能），把需求清单与产品原型向大家介绍清楚。会议的主要目标是团队对产品达成一致认知。对于开发周期先有个估算，为立项做准备。 如果评审后需要修改方案，且修改内容较多，那么修改后，需要再进行一次评审。
PS：评审中PM要做到把控全局，理性客观的向大家解说，哪些功能为什么一定要做，哪些功能第一期我们可以不做。要有据可依，最好别用，我觉得就应该…… 我认为…… 等等表达方式。
四、立项
明确参与项目的人员、工期、绩效（奖惩），如果现有开发人员不足的情况，PM还要去各部门去协调人员。立项审批通过后，建议要和全体人员有个立项的会议（仪式感），告知团队从今天起我们要一起做好一件事情。PM可以说一些积极向上的，鼓励团队的话语。甚至可以拍一张参与这个项目的全体人员的合影，总之要有一个好的气氛、好的开始。
五、产品设计
PM需要输出产品需求文档、原型图、流程图、框架图，产品设计过程中PM需要有一定的决策力，开发过程中一些细节、功能点都需要PM自己决定，领导看的是产品大的框架，核心功能等，需求评审时也不可能把每个细节和交互都过一边。在开发过程中PM还要做好需求变更记录，及时更新文档记录。
六、UI设计
PM需要和UI设计师沟通页面效果图的定稿、把握页面整体风格（可以开一个定稿的评审会），这个环节其实应该UE+UI,很多公司是没有UE交互师的，一般都UI直接做了。
七、前端
UI设计完后，前端就开始套页面了，这一个环节PM要和前端沟通页面细节的展示效果，交互要求，做好监督工作,需要修改的地方及时和前端沟通。
八、开发
虽然有产品需求文档，但开发过程中PM还是要及时和开发人员沟通功能要求，因为有些人员并没有仔细的去阅读文档。要保持和开发人员密切高效的沟通，保证在开发周期内完成工作。
九、测试
产品完工后要进行测试，测试通过后才能上线。测试完毕后，测试人员要编写测试用例。测试环节中PM也要和测试人员沟通讲解产品逻辑、功能，并一起完成测试工作。如果公司没有测试人员的，需要PM组织人员完成测试工作。
十、上线
产品上线后，也要进行一次测试，因为正式环境下可能还会出现一些问题，发现问题要及时组织人员进行修正。
十一、运营
和运营人员一起完成数据收集、在产品运营过程中、PM会收集来自不用角色的人员提出的需求，有用户、运营人员、客服、各职位领导、等等。对收集的产品数据和需求，PM要进行分析、梳理，准备第二个版本的开发工作。您看产品的开发流程，分不同的阶段，但每个阶段都需要产品经理去参与，所以做为产品经理就要有主人公的心态，每个流程都要认真负责，要有驱动力。你认真做事的态度也会影响你团队的每一个人！
如果想零基础入行产品，又不知道怎么学，建议报培训班系统的学。自学的话容易学杂，掌握不了核心的知识。
我以前也是在培训班学的，有老师教就是不一样。我就不打广告了，想了解的可以私聊我。可以先免费试听。
5. 关于产品经理工作的5个具体流程
1.分析产品行业 首先对于产品经理工作的第一步，就是必须要对产品市场有一定的了解，只有充分掌握产品市场的动向，才知道产品设计和研发的方向。 2.了解用户群体定位 在准备研发或者设计一款产品，如果用户群体都不知道是什么，那怎么更好地设计一款适合市场发展的产品呢？因此，了解用户群体，并充分地定位用户群体也是很关键的。 3.制定产品宣传方案 一个产品的上线之前，必然需要准备一些产品的宣传材料，通过材料来进一步了解产品，加深对产品印象，也能够带动产品的市场宣传。 4.进行产品测试阶段 在产品设计成型之后，在投放市场之前还应做好相关功能的多次测试及优化，只有不断测试优化，才能够保证产品上线后得到用户认可。 5.拓展多元化推广渠道 在产品上线的过程中，只有不断地拓展产品的推广渠道，这样才能够真正帮助产品打下名气，提高市场的占有率。
6. 产品完整工作流程：产品经理必做的25件事
笔者把产品从0到1的一次完整过程梳理出来，排除了后期优化和产品运营的范畴，得到了三大阶段：产品梳理、产品设计、产品落地。
一、「永恒的问题」你是做什么的？
在产品界N多的永恒问题中，永远都有一个： 你是做什么的？
每当逢年过节，你的亲朋好友问起来的时候，你可能都为止虎躯一震。
对于非互联网行业的人来说，我们往往拿捏不好这个回答的度。讲太多技术又怕人不懂，讲太少的话又怕人家认为自己是行政，讲不好还会被人认为是银行柜台里那个产品经理。所以异常心累。
为此笔者总结了产品经理的完整工作流程，梳理清楚了至少有25件事，是产品经理独特的工作流程。
希望以下内容能给大家灵感，先上脑图：
二、「25件事」完整工作流程
笔者把产品从0到1的一次完整过程梳理出来，排除了后期优化和产品运营的范畴，得到了三大阶段： 产品梳理、产品设计、产品落地
三个阶段中，我们最少有25件事是产品经理必须要做的，否则会对我们的产品效果产生很大的影响，下面我们具体拆解来看。
1.点子
产品经理要找出点子，不管来源是哪里。做好点子这件事，需要我们掌握脑图技巧和风暴会技巧，产出灵活多变的点子并记录下来。
2.需求
在需求这件事上，我们要借用到心理学等方面的知识，去把点子归纳总结成为一条条明晰的需求，放进需求池待分析。
3.方案
方案这件事来说，我们要把需求池里的需求规划出雏形，看看在现有的资源环境情况下，是否适合去做，并给出粗略的方案和工作量排期。
4.目标
我们需要给出产品要达到的目标和效果，不能因为仅仅因为这个功能很酷而去做，而要看酷在哪里。
5.策略
有了目标之后，我们还要看看策略，是克制还是粗放，是谨慎还是开放。都需要我们去思索。
6.定义
清楚了目标和策略之后，我们应给出产品定义。产品定义是后期我们评估需求的核心要义。一切需求和优先级都不能违背产品定义，这也是我们的初心。
7.不足
在这几件事走完之后，我们一定会遗留一些问题短期之内难以解决，或需要试错。所以我们需要把不足记录下来，重点在后期产品迭代过程中考量。
8.场景
给出目标用户和场景，一一对应地去提出解决方案，进行推演。
9.业务流程
有了场景之后，融会贯通梳理出来一个用户的业务流程，再整体看一下每个环节的情况。
10.功能结构图
场景和流程理清楚之后，请做出功能结构图。这里同样需要进行一次风暴会，这次的侧重点在方案上。
11.页面关系图
有了整体的功能站点地图后，我们需要增加页面之间的跳转关系，以及每个页面具体内容的设想规划。
12.UE交互图
在敲定了页面大致内容和关系后，我们需要将内容细化，这时候可能要对接需求方和用户，调研得出每个页面的真实数据情况，方便设计师给出交互稿。
13.UI效果图
交互稿给出后要找各方确认，无误后给设计师出效果图和切图，准备进入开发。
14.项目启动会
在拿到了需求、方案和需求文档以及前端所需的效果图等素材后，请叫上全体人员进行一次项目启动会，标志着需求上的互通有无和进度知悉，对于避免开发误工等情况至关重要。
15.用户验证
开发初期，尤其是创业公司，请做用户验证。这是我们进行试错和避免方向偏差的最简单办法，以免我们误入歧途造成较大的沉没成本。
16.资源确定
验证无误后终于要敲定资源投入的情况了，请务必跟高层确认，以免定位不清，难以做到量级。
17.行事历
一切都确定后，请给出行事历。这对于项目进度追踪较为重要，也是给领导和用户的一颗定心丸。在后期复盘时也会大有裨益。
18.汇报
汇报是贯穿在以上始终的，但是这阶段尤其需要一个汇报。这个阶段的汇报标志着需求的付出水面，是高层比较看重的期盼的一个点，一定要充分汇报以征求尚方宝剑，方便后续行事。
19.项目管理
进入开发阶段后，要做好项目进度的追踪和工作量的安排，这是为了我们后期验收优化争取时间。
20.走查验收
请在前端开发完毕第一时间安排测试工程师准备好走查环境，要及时给设计师优化的时间。走查后发出问题汇总邮件等待前端修改。走查后要跟前端当面把问题一一确认，确保他清楚且知道如何修改，修改后第一时间验收并进行多轮走查。
21.资料更新
请及时更新需求变更和需求文档，并制作好操作手册和FAQ给推广人员使用。
22.测试
除了前端的走查验收，还要做好整体环境和数据逻辑等情况的测试以及DEBUG，及时发现及时解决。
23.用户验证
开发初期，尤其是创业公司，请做用户验证。这是我们进行试错和避免方向偏差的最简单办法，以免我们误入歧途造成较大的沉没成本。
24.UAT
这是我们最重要的一环，确保每个整体功能结束后可以进行小范围的UAT和把玩，否则将被搁置直到上线。若不做好UAT，有交互上的严重漏洞，就只能等下个版本修改了。这对产品的口碑影响很大。
25.发布
发布时请想好时间和策略，大到冷启动方案小到提示语，事无巨细一定要考虑到。否则很容易出现崩溃和打包有误的情况，在发布阶段一定要测试周全。
三、「总结」你都做了什么
梳理清楚这25件事之后，我们给出了每件事专业简短的名词和解释
我想我们已经可以回答上面的问题：
作为产品经理，我们是需求分析到落地上线全流程的负责人，工作内容包括20多项，比如…
对于面试场景，我们也可以给出相应回答：
在上一家公司，我主要做了2个项目，除了主笔维护全局的需求文档外，还负责了项目启动阶段的用户验证和风暴会议推进…
是不是看起来专业了许多？
很多时候，你不清楚自己做了什么，是没有具象化梳理和表达。很多沟通和展示就在迷迷糊糊的过程中被隐去了。所以产品经理不但要做的好，更要说得好，总结汇报的好。 才能跟所有人分享你心中的灿烂星空。
7. 产品经理的项目流程和工作流程
产品从0到1的一次完整过程梳理出来，排除了后期优化和产品运营的范畴，得到了三大阶段：产品梳理、产品设计、产品落地
三个阶段中，我们最少有25件事是产品经理必须要做的，否则会对我们的产品效果产生很大的影响，下面我们具体拆解来看。
1.点子
产品经理要找出点子，不管来源是哪里。做好点子这件事，需要我们掌握脑图技巧和风暴会技巧，产出灵活多变的点子并记录下来。
2.需求
在需求这件事上，我们要借用到心理学等方面的知识，去把点子归纳总结成为一条条明晰的需求，放进需求池待分析。
3.方案
方案这件事来说，我们要把需求池里的需求规划出雏形，看看在现有的资源环境情况下，是否适合去做，并给出粗略的方案和工作量排期。
我认为其实这里就是确定MVP阶段。
4.目标
我们需要给出产品要达到的目标和效果，不能因为仅仅因为这个功能很酷而去做，而要看酷在哪里。
5.策略
有了目标之后，我们还要看看策略，是克制还是粗放，是谨慎还是开放。都需要我们去思索。
6.定义
清楚了目标和策略之后，我们应给出产品定义。产品定义是后期我们评估需求的核心要义。一切需求和优先级都不能违背产品定义，这也是我们的初心。
产品定义包括：使用人群、主要功能、产品特色，这三个维度；
7.不足
在这几件事走完之后，我们一定会遗留一些问题短期之内难以解决，或需要试错。所以我们需要把不足记录下来，重点在后期产品迭代过程中考量。
8.场景
给出目标用户和场景，一一对应地去提出解决方案，进行推演。
9.业务流程
有了场景之后，融会贯通梳理出来一个用户的业务流程，再整体看一下每个环节的情况。
10.功能结构图
场景和流程理清楚之后，请做出功能结构图。这里同样需要进行一次风暴会，这次的侧重点在方案上。
11.页面关系图
有了整体的功能站点地图后，我们需要增加页面之间的跳转关系，以及每个页面具体内容的设想规划。
12.UE交互图
在敲定了页面大致内容和关系后，我们需要将内容细化，这时候可能要对接需求方和用户，调研得出每个页面的真实数据情况，方便设计师给出交互稿。
13.UI效果图
交互稿给出后要找各方确认，无误后给设计师出效果图和切图，准备进入开发。
14.项目启动会
在拿到了需求、方案和需求文档以及前端所需的效果图等素材后，请叫上全体人员进行一次项目启动会，标志着需求上的互通有无和进度知悉，对于避免开发误工等情况至关重要。
15.用户验证
开发初期，尤其是创业公司，请做用户验证。这是我们进行试错和避免方向偏差的最简单办法，以免我们误入歧途造成较大的沉没成本。
16.资源确定
验证无误后终于要敲定资源投入的情况了，请务必跟高层确认，以免定位不清，难以做到量级。
17.行事历
一切都确定后，请给出行事历。这对于项目进度追踪较为重要，也是给领导和用户的一颗定心丸。在后期复盘时也会大有裨益。
18.汇报
汇报是贯穿在以上始终的，但是这阶段尤其需要一个汇报。这个阶段的汇报标志着需求的付出水面，是高层比较看重的期盼的一个点，一定要充分汇报以征求尚方宝剑，方便后续行事。
19.项目管理
进入开发阶段后，要做好项目进度的追踪和工作量的安排，这是为了我们后期验收优化争取时间。
20.走查验收
请在前端开发完毕第一时间安排测试工程师准备好走查环境，要及时给设计师优化的时间。走查后发出问题汇总邮件等待前端修改。走查后要跟前端当面把问题一一确认，确保他清楚且知道如何修改，修改后第一时间验收并进行多轮走查。
21.资料更新
请及时更新需求变更和需求文档，并制作好操作手册和FAQ给推广人员使用。
22.测试
除了前端的走查验收，还要做好整体环境和数据逻辑等情况的测试以及DEBUG，及时发现及时解决。
23.UAT
这是我们最重要的一环，确保每个整体功能结束后可以进行小范围的UAT和把玩，否则将被搁置直到上线。若不做好UAT，有交互上的严重漏洞，就只能等下个版本修改了。这对产品的口碑影响很大。
24.生产验版
是正式发布前的一个预发布动作，使用生产环境进行内部小范围的升级测试，测试无误后再大范围推送。
25.发布
发布时请想好时间和策略，大到冷启动方案小到提示语，事无巨细一定要考虑到。否则很容易出现崩溃和打包有误的情况，在发布阶段一定要测试周全。
8. 产品经理工作内容？
前段时间试图给公司HR做培训，试图将产品经理这个岗位的工作内容，水平档次和招聘的评判标准做个详细的分析说明。正好在这里整理成文章，给专栏不知什么原因还有持续新增关注的用户们一个交代:) 最近有考虑为3年工作经验以上的产品经理的职业辅导做些新业务，也欢迎各位产品经理们，看完文章后，关于产品岗位人才的技能成长，职业发展来和我探讨。 （不过老实讲，写完之后觉得文章讲道理做分析比较多，例子举得不太够，也许不太方便理解。各位先凑着看，也欢迎多提提意见，也许有空了我会再多修改，在陈述中多添加一些小例子） 基础概念——产品经理到底干嘛？ 求职新人，又或者是招聘产品经理的HR／猎头，最早想弄清楚的就是，产品经理这个岗位的人到底是要干嘛。 在产品经理的诞生地——快消行业，产品经理是协调资源设定产品生产、供应计划，制定品牌定位，协调与之相符的营销、渠道、销售工作，好像和研发关系都不大（可以参见“产品经理的第一本书”）。 当年我只说说互联网公司的产品经理干啥。在互联网公司，产品经理，可以基本理解为，搞清楚到底要做什么产品，并且协调公司同事把它做出来的人。 只是这个定位，似乎很像创业公司CEO，或者公司新业务老大（至少是个产品总监）的定位。实际上的确如此。如果能清楚到底要做什么产品，基本上确定了公司很大程度上的商业定位、市场定位，这多半是老板要定的事情——也无怪乎当年红衣教主，力捧产品经理为准CEO式的人。 所以回归到现实，大部分产品经理头衔的人，他们的具体工作内容，就是辅助老大们搞定清楚到底要做什么产品（产品给谁用，解决什么问题，产品里要做什么功能来实现），作出完整的产品设计方案（可能还要弄清楚对应的线下服务怎么配合），协调技术研发，把产品做出来（然后可能还要对接运营提供对应的服务）。 非要把工作内容做个归类，可以这么看： 需求分析 产品设计 研发辅助 运营配合 然而，不同层次的产品人员，在这些工作内容上的分工侧重，又很不一样。在互联网公司里，可以基本分为这么几个层次： 初级－产品专员／助理 中级－产品经理／高级经理 高级－产品总监／副总裁／CEO 在初中级产品岗位，算是我们常说的产品经理，但其工作大部分还在产品设计、产品研发的执行阶段。虽然有需求分析的工作，但大部分只是在功能需求分析这个范畴内。对于高级产品岗位人员来说，或许才是真正的“产品经理”。因为到了这个层次，以及所在的公司地位，才有了能够参与产品决策，真正来决定要做什么的权力。 我画了一个图，细致切分了一下产品岗位工作，对照在不同层次产品人员的工作内容差异。同时也便于分析，为什么会对产品经理的能力，提出这样或那样的要求。对于招聘的HR／猎头来说，或许你今后能更清晰的理解产品岗位的JD要求。 （数字标号1、2、3，对应代表了初中高阶产品经理工作中主要承担的任务） 请点击输入图片描述 接下来，我们就着这个图，来介绍一下，产品经理的工作内容和层次差异。 不过限于篇幅，第一篇文章我可能只讲需求分析和产品定义这一部分。 产品经理的初始工作——产品定义，定义做什么产品 在我做这个产品经理岗位分析培训的时候， @刘飞 寄来了他新出版的产品经理入门的新书“从点子到产品”。书名其实也很好预示了产品工作的起始——“点子”。 需求分析，其实就是“点子”的来源过程。从需求分析道产品构思，这是决定产品做什么以及怎么做最早、甚至是最重要的决策过程。 对于大部分产品，我们都要回答这么些问题： 仅仅凭借直观感受的用户和所谓的市场机会，就想象出产品去做是远远不够的。对于绝对部分新产品而言，弄清楚这么几个问题是至关重要的： 我瞄准的用户是谁？解决他们的什么需要？——分析需求信息，找到痛点 我的产品解决方案能够真的解决用户问题——解决方案的验证 市面上是否已经有类似的产品了——产品独特的价值定位 我的产品有哪些特点，能更好解决用户问题，在用户面前更有吸引力——产品的竞争力 我们能不能把这个产品做出来？要花多大的代价——实现能力评估 做好这个产品后，能带来多大的商业价值，怎么赚钱——商业价值分析 相对而言，你可以把解答以上的问题的工作，当成需求分析最重要爹部分。接下来，我们可以大致分为这四项工作内容： 搜集信息和需求分析 构思解决方案－可行性分析 产品定位分析 商业价值分析 这些工作完成之后，也就几本完成了产品定义，要做事情的范围和边界，直至执行阶段。接下来我来挨个说明。 一. 搜集信息和需求分析 需求分析，其实就是将各类点子，分析判断，筛选打磨为成型“产品概念／想法”，或者说“靠谱点子”的过程。 然而，点子从来不会凭空而来，所以产品经理，需要有良好的素质能力，从外部获取信息，获得充分的点子来源。 从产品的角度，是要确认，有哪些来自用户的问题或者行业当中的问题需要我们去解决，或者针对我们已有的产品或者服务，还存在哪些问题需要我们去改进。 对于从事产品研发执行层面的产品来说，需求分析，更多的是将抽象的业务需要，转化成技术人员可以切实理解的非常具体的功能需求点，乃至程序逻辑。 初阶产品岗位：多半是在已有的产品的基础上，进行改进。这个时候，产品经理最基础的工作，就是从找产品用户聊天，或者等公司的运营人员吐槽，从用户那里取得反馈，将他们的期望和要求，搜集整理成可以改进产品或研发新功能的“点子”，就是最基本的需求分析。把自己当初一个普通用户，从使用者的角度反复试用，像“红衣教主”说的一秒钟变小白，也是一个发现问题，发现需求的方法。有些简单的问题，可以将功能需求直接添加到技术工程师的任务队列。同时，尽可能的搜集发现其他同行的竞品，或者其他近似的产品，也能够启发产品人员获得“灵感”，找到可以添加的新功能和改进的设计方案。所以很多同行吐槽，（拙劣的）产品经理的工作就是盯着同行抄。 中阶产品岗位：更进一步的话，产品经理要能够将用户提出的期望，快速的对应到基本的功能研发需求——如果是跟进竞品的新功能，也得搞明白别人的新功能是为了解决什么问题。如果用户提出的需求和反馈，以及想要解决的问题相对比较复杂，则需要做更多的分析和验证。产品经理要通过合适的调研手段和信息渠道，确认少数人所反馈的需求信息的真实性，以及可以拆分成更多明确的、具体的问题和用户期望，再去逐步寻找解决办法。当然在大部分情况下，产品经理并没有时间去做仔细的调研和验证，只能凭借自己对于用户的理解或者类似产品的运营经验做判断。除此之外，对于搜集到的反馈信息，整理的研发需求，也要能够分析判断出对于用户、对于业务流程的重要程度，以此确定解决需求任务的优先级。相对初阶产品经理，大部分的工作还是依赖于已上线的产品进行改进改良，对于需求的分析，基于某些产品功能也有一个明确的研究方向，属于命题作文。中高阶的产品经理们通常会有更大的自由，去寻找相关业务的从业人员交流，挖掘需求明确业务发展方向。 高阶产品岗位：需求信息，除了简单的直接或间接的来自用户或者从业者，会有更多的机会去洞察宏观的行业机会、市场变化，发现其中也许不是用户身上那么显而易见的需求或者商业机会。这阶段的产品经理，应该有更敏锐的商业嗅觉，以及人脉资源来获取有价值的商业信息。 在大公司体系下，其实最常见的业务或需求，或者就是从老板层面，一层又一层将公司业务的需求，或者上级已经明确的需求，从上到底下传递执行。这个时候产品经理，学会理清楚老板的期望，安排好优先级就行了。如果觉得老板提的要求不合理，进行合理的说服抗争，则是产品经理们另一个方面的特殊能力了。。。 工作内容常见的误解——用户研究 用户研究，这个曾被广泛提及的概念，其实就是在搜集需求信息这个阶段的工作。然而这个词被强调的过多，在实际工作中，产品经理们实际上很少有机会去系统性，或者难有完整时间、单独的去做这项工作。绝大部分时间，用户研究，被零散的安排在了和用户交流、和运营的同事沟通，阅读他们提供的用户反馈信息，从同行交换情报信息，阅读行业里的用户统计报告等各种信息搜集的活动过程中。 只有在极少数的大互联网，才会有专门做这项工作的时间阶段、甚至是岗位，和在极少数的时间里，产品经理才会有时间精力去做专门针对用户研究的用户访谈、问卷调查等。 很多时候，对于需求的研究，可能不会真对单个的用户或群体。从宏观的市场统计数据、行业统计报告当中，也能够有不少发现。正如前百度的产品大牛俞军所说，“用户不是人，是需求的集合”。因此很多时候的用户研究，并不是在研究用户、研究人，而是在研究业务、研究市场。 不少其他行业的，如消费品、汽车制造，也都会有专门做用户市场研究的部门和岗位，来做市场调研和数据分析的人。从职业发展和招聘的角度来看，这些岗位和初级产品岗位，存在一定的人员适配性。 二. 构思解决方案－可行性评估 和其他行业的用户研究、市场研究工作相比，产品经理在这项工作内容上开始体现出差异。其他行业的市场研究，通常在搜集完信息，统计分析，整理出新的见解，或者总结细分人群的独特诉求之后，工作便交给研发部门，广告营销部门或者其他执行部门去讨论了。 而在互联网公司，产品经理岗位的人，则要将自己获取的信息需求，进一步消化酝酿，构思成新的解决方案，考量用户能不能接受，或者产品研发、对接线下业务环节能不能支持好。 一个方案是否可行，通常包含： 产品技术的可行性 运营或者服务的可行性 商业的可行性。 产品技术的可行性，主要是指期望的技术研发，能不能实现期望功能。 现在人工智能很火，深度学习的基础工具完善，似乎变得无所能，那么开发出一个能教人说英语的随身人工智能老师，肯定很不错。可这样看似简单的想法，能否真的达成？这样的产品研发究竟几个月或者几年才能完成？还需要哪些数据资料或者资源？是不是现在的技术水平，几年内依然无法实现理想的效果——这些都是产品经理在立项之初，需要考虑清楚的。 当然，这个主要是相对功能实现的预期来说的。比如，搜索引擎非常复杂，现在要重新做个类似百度的全网搜索，而且搜索结果能符合大部分人，很难。但如果只是做个小电商网站内的几万个产品的分类查找，就容易很多。 要讨论运营或者服务的可行性，是因为现在很多产品，不只是技术功能，需要业务需求下，对接合适的服务。靠谱的解决方案，需要从用户需求的完整应用场景，或者放在与之相关的业务流程当中，找到能够解决用户问题，能被用户所接受，符合他们行为习惯的解决办法，同时确保，公司线上产品以及对应的线下服务，能做得到——即所谓的，“业务逻辑能不能跑的通”。 像现在类似火热的二手车交易平台，产品人员必须要对用户买卖二手车的业务流程有仔细的研究分析，才能构思出与之匹配网络交易平台，其中还少不了要接入和传统线下业务相关的汽车检验评估等环节。如果不对业务进行深入的分析研究，是很难想清楚具体的产品解决方案。 所以解决方案是否靠谱，自然需要更多的业务经验的产品经理来判断。 商业的可行性，我们更多会放到商业定位当中去讨论。 初阶产品经理，需要评估可行的工作相对比较简单，就是用户反馈，或者是内部运营抱怨的问题，产品上所需要做的改动，技术是否可行性，又或者有多复杂。这些多半是对业务流程／导航结构／排序策略／页面的信息展示重点在产品设计上的调整，成本消耗不高也不必花太多时间去评估，在需求分析时评判好优先级就好了（有问题也可以交给上级顶多）。有些的新的产品功能设计，能够在已有解决方案／竞品的设计方案上进行优化改良也就差不多了。如果要解决的问题牵扯更大范围的，或者更加负责，要构思一个完整的功能体系或者全新的产品设计／解决方案，则要到下一个进阶的工作阶段了。 中阶产品经理，需要能够构思产品中的完整功能体系，或者全新的产品解决方案。从经验的角度，他们应该已经掌握了解竞品或者是传统方式的解决方案，能够快速的结合业务需要，构思出新的能被用户接受的解决方案，来进行讨论分析。他们也必须能够判断产品业务实现逻辑上可能存在的重点、难点，并从功能技术的角度，评估可能性，以及对于预期效果作出判断。有些产品的解决方案，并非单纯取决于技术研发，更需要公司运营资源的配合。那么对于产品解决方案的可行性评估，则要求产品经理对产品运营的可行性也要有经验来做判断，甚至涉及到更高层次，商业可行性的地步。 高阶产品经理，则需要更丰富的业务经验、市场知识，乃至商业逻辑，来评估整套产品方案的可行性。或者对于一个复杂解决方案，能找到不确定因素或者关键障碍，进行深入的调查研究，来确认或者解决。高级层次的产品经理，会对实际的服务对接、产品运营的可能性有更全面的了解，而不仅局限于功能研发的角度，能够实际评估出解决方案从线上到线下实现完整产品服务流程的可行性。 所以能够快速构思方案，并评估可行性的可能，是作为创业型产品经理，或者说能够参与公司业务决策，最重要的能力差异。 在发展速度如此之快的互联网行业，产品人员远远没有充分的时间进行用户市场的研究，或者慢慢研究论证业务方案的可行性。是否拥有足够多的产品经验去推导业务的可行性，是否有足够多的业务经验作为依据，则是在产品决策中“拍脑袋”的时候，能否拍出正确决策概率问题。 在这项工作业务的能力要求上，除了产品经理的逻辑推导能力之外，大概就是在相关业务领域的经验积累了。 三. 市场定位分析 如果只是因为有了用户需求，能想出个产品点子，产品研发上大致可行，就兴冲冲去做，也只能是年轻的创业者－初级产品经理最容易犯的错误。事实上，我进入互联网行业这么多年来，也见到过太多类似的项目前仆后继的掉到同一个坑里，有太多的“创业者”在重复造轮子，大概访谈了几个用户，连市场调研都没做就去兴冲冲开干了。 所以在自己有了点子之后，应当看看市场上是否存在类似的产品存在，是否还值得自己／公司去做，即产品经理应该具备常识要做的竞品分析。 不管产品经理们或者创业者觉得自己的点子如何独一无二，但现实世界是，市场肯定以某些方式存在过，服务与类似用户需求和市场需求的业务。哪怕不是互联网产品，也有以很传统的形式提供的服务。相亲网站、招聘网站出现前，真实世界早就有婚姻中介所和职业介绍所了。 做竞品研究和分析，一方面是为了确立产品的市场定位，找到有力的产品价值和差异化的竞争力，另一方面，也是为了进一步分析业务的可行性。因为市场曾经存在过的类似产品和服务，因为某些环节的因素而未能持续经营下去出现的障碍，也是你所构思的新产品／服务，在可行性分析中可能忽略的问题。 在成熟的商业公司，市场定位分析的工作，是在产品立项之前就应该做好的。所以往往也不是初阶的产品岗位的人员，能够参与的决策工作。 产品的市场定位分析。可以分为： 核心价值定位 市场定位规划 一般而言，产品的核心价值定位，常常对应一开始我们在搜集到的需求信息，或者构思产品解决方案当中，所针对的用户群体要解决的“痛点”。所有的功能改进和产品设计，都要围绕这个点来确立。 产品的市场定位分析，是确保产品与类似的产品竞争比较之后，具备足够强的功能特色或者高人一等的性能，在市场上推出后，能够有效赢得用户。反过来说，为了打动某一类确定的用户群体，必须先明确他们在意产品的哪些功能特色，才能进行产品的有效规划，利用有限的资源更早的将符合条件的产品做出来。 对于初中阶的产品经理们，哪怕并没有机会参与到产品的定位决策中，但也要理解决策者对产品所做的定位分析，才能做好符合产品定位的设计。 而所有产品的定位选择，能够实现期望的差异化功能特色，也不得不依赖于公司所有的资源，产品经理们并没有天马行空任意发挥的机会。 这里所描述的“定位”，和营销方法论当中，利用用户心智进行差异化的宣传推广，有着相当的一致性。只有产品／服务的设计规划初期，设定了有目标性的用户人群，赋予它能打动这些人，有别于其它产品的特色产品属性，才能应用到广告营销宣传当中，具备争夺用户的市场竞争力。 基于商业市场的选择——产品的“定位”，才是营销“定位”的根基。 然而确立核心价值是根本，为了市场定位寻找的差异化，是营销手段。见过很多产品为了寻求所谓的差异化，而背离所要解决问题的核心，这得要求产品经理们，有很强的逻辑性和价值判断能力。 不得不说，产品的价值定位和市场定位，是一项不太容易完成的复杂工作。只有那些对市场业务有非常丰富经验，或者已经有很强知识方法和实践经验的产品经理，才能够做好。甚至说，这项任务在创业公司，就应当是CEO的重要责任，小公司里，核心产品就决定了公司战略定位。 产品的定位规划，大多在进行新产品规划的阶段，才会有这么系统性的分析工作。然而对于在公司打工的初级产品经理来说，大部分情况下难有机会去参与产品的定位分析工作。公司里能够参与决策的，多数是具备丰富经验的中高级产品经理们。多数情况下，初级产品经理只是在已经成型的产品定位和功能范围里，去解决那些相对明确的研发需求。 这项工作内容当中，在营销广告行业，从事策略工作，或者咨询公司、战略部门做过战略咨询、市场分析的人，或者会有匹配的能力经验。 四. 商业分析 能够确定产品的定位和价值，便可以开始认真计算产品的那本商业帐。 产品价值有大多，需要花多大的代价，能够产生多大的收益？ 要让用户选择一款新的产品／服务，一定是 使用新产品的价值－新产品的使用成本－切换到新产品所要付出的代价（学习成本，更新的物质成本）>老产品的价值－老产品的使用成本。 对于公司和团队，一定也要试 产品的商业价值收益>产品的研发＋运营成本。 对大部分产品经理而言，最开始或许不必考虑产品赚钱的问题。而到了产品成熟期，也会有专门的商业产品经理，专门负责公司产品当中赚钱的那部分工作——广告平台，又或是收入运营部分。 那么当公司需要考虑赚钱的时候，计算分析清楚产品的运营成本，怎么产生收入，收入的规模和预期（甚至要拆分成很多具体的运营数据预估、商业数据分析），以及在优化运营成本，以及努力提高收入之间，怎么优化产品结构或者运营模式，也是可以有产品经理来参与的工作。 对于大部分初级产品而言，除非是专门负责商业变现的，否则很难参与到这一类的工作。在大的互联网公司，或者传统公司，这一类工作都是由公司的战略部门来做的工作。如果换做小公司，那么在创业之初，这部分工作则是创始人、合伙人们在做商业计划时，就要完成的工作——哪怕是在商业模式中做最粗略的预估。 通常，有较好的商科背景，或者财务背景的人，能够更好懂得商业分析该怎么做。否则，对于习惯了研究用户，研究需求，如何将微观、具象的产品服务，估算出宏观的用户规模、付费市场预期，需要更多来自已有产品运营数据的经验对比。所以，拥有较成熟产品运营经验的从业者／高管，反而可能会在商业分析这项技能上更具优势。 产品定义大部分都是老板做的事 理论上，对产品经理所要承担的需求分析和产品定义分析解释了这么多，可是大部分产品经理可能却会觉得，自己很少做这部分的工作，因为在一个产品立项之前，许多公司里的产品岗位的同事开始工作的时候，产品定义所包含的需求分析、市场定位、商业分析工作，应该是老板们已经拍脑袋做完了（在我画的产品经理工作分阶图当中，这一块内容，大部分也标记为中高阶产品经理所能承担的工作）。 产品经理开始进入到研发的时候，多数是按照老板们脑子里已经定义好的产品，研究用户的使用场景、行为习惯，再拿来反映到具体的产品设计方案上；又或者是产品上线后，再根据用户的反馈，对产品进行调整。所以这个时候，产品能否取得大的成功，很大部分取决于老板们的产品定义和市场定位，是否做对了。很多互联网公司投入了大量的研发资源乃至运营资金，产品最终还是流产或者被关停，导致产品经理和技术研发人员的心血白流，多数就是如此。产品经理们的诸多努力，也就成为了老板们失败决策的牺牲，不得不诸多哀怨。 不过，如果能够在每一个产品项目中，锻炼出扎实的产品设计、研发管理能力，再慢慢锻炼积累这篇文章中所提到的关于产品定义的需求分析、市场定位、商业分析能力，争取更多机会参与到和老板的决策讨论之中，也是个人成长中必要经历和经验财富。 到下一篇文章中（虽然不知道什么时候能写出来），再讨论大部分产品经理们，实实在在肩负的产品设计、项目管理的工作内容。
最新文章
热门文章
推荐阅读