初级产品经理的日常工作流程详解

作者: 刘小莹_Joanna | 来源:发表于2016-09-12 10:50 被阅读478次

    前言:可能有一些产品新人在面试的时候经常被问产品经理工作内容,在这里不谈那些高级产品经理的工作内容(产品战略、需求发掘、项目管理…)只谈谈初级产品经理的工作内容

    一、用户调研

    用户调研分为定性分析和定量分析。定性分析是指用户访谈,定量分析是指调查问卷。
    用户访谈。当然访谈需要一定的技巧,更多的倾听为主,以了解用户的内心想法为主。访谈时对用户的初步回答反复追问“为什么”,引导用户从表面的行为开始思索,清理出行为背后的动机、需求乃至价值和文化观念。
    调查问卷。问卷调查是一项有目的的研究实践活动,设计的问卷是为你的特定研究目的服务的,这是设计问卷之前必须植根于脑海中的一个观念。既然问卷调查是一项有目的的研究实践活动,那么从理论指导实践的角度出发,在设计问卷前必须要做好充足的理论准备,宏观层面上应做到以下两点:
    1.明确你们研究的主题是什么
    2.明确你们想通过问卷调查获取的信息有那些。通过调研问卷你可以定量的验证你提出的需求

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

    收集各个部门的需求,建立自己的需求池。并定期对需求池进行整理。你的需求池里面有不同人提出 的需求。
    需求来源:需求池里面有可能包含老板提出的战略性需求、客服反馈的需求、用户访谈得来的需求、调查问卷得来的需求、数据分析得来的需求。记录好每个人提出的需求,这样当你在做需求分析的时候如果不知道需求后面的本质需求, 你可以找到那个人进行了解,这样有助于你把握需求的本质。
    定期对需求池做一定的梳理。产品部门定期读需求池进行整理,那些需求是下一步要做的,那些需求是是可以暂缓的,那些需求是不做的,对需求池进行梳理和分类。
    不同终端的需求要分开。分为APP、PC、微官网、前台、控台这些。
    这里提供一份模版:


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

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

    四、竞品分析

    俗话说知己知彼,百战不殆。你做的东西别人也在做,买东西都还需要货比三家呢。做竞品分析有两个目 的,第一、扬长避短。吸引别人做的长处,发现别人做的不足的地方。第二、验证与测试。别人上的这个功 能市场反馈怎么样,有没有遇到啥问题,通过竞品确定市场机会点。
    竞品分析有一定的流程。可以从“战略层-范围层-结构层-框架层-表现层”这几个层面进行分析。
    (1).战略层:确定竞品的商业模式、产品定位、市场状况、盈利情况等,目的是确定方向,了解市场。
    (2).范围层:竞品的目标人群,满足了什么需求,用户的满意度如何,目的是参考竞品的目标人群以及需求的重要度。
    (3).结构层:竞品的主要功能架构、特色功能、发展模式,优缺点总结,目的是寻求差一点。
    (4).框架层:竞品主要任务流程的顺畅,交互的细节,逻辑的准确,页面的框架,目的是优化流程,提高用户体验。
    (5).表现层:竞品是视觉风格,颜色层级,文案的运用等,目的是维持用户对这类产品的传统认知的基础上打造产品独特性

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

    竞品分析做完以后,开始根据竞品分析的结果。开始自己的功能设计,流程的绘制,在原型上加一些功能的注释,这样在敏捷开发的时候可以节省PRD文档的制作,也可以在和技术开会的时候不会遗漏自己想讲的东西。
    原型评审的时候技术人员的有效意见一定要虚心接受,不要觉得自己是产品就高高在上,涉及到原则问题坚 持。别人提的有益意见也要虚心接受,只有这样你才能避免死逼,项目才能尽快落地。至于PRD文档的制 作。有时间的话可以写word文档,没时间的话可以直接在原型中制作文档。但文档必须包含的部分有:
    (1).产品版本的迭代历史。清晰的告诉项目成员每次改变都改了那些东西。
    (2).需求功能清单。有需求功能清单 的时候技术人员在开发的时候才不会遗漏,测试工程师也会根据你的需求功能单来进行测试。
    (3).全局结构图和重要的功能流程图不能少。全局结构图。产品全局结构图相当于房子的骨架,相当于文章的目录,别人看过你的全局结构图就知道你的产品大概分成那几个部分。其次,一些重要的功能流程图需要 写,这样有助于开发人员思路的建立。
    (4).异常流程要考虑清楚。只有异常流程考虑清楚产品经理才不会挨批,技术开发起来才不会出现问题。
    (5).重要名词要定义。对于首次出现的名词需要定义,这有这样别人在看到名字的时候才不会有疑问,再跑来找你问。

    六、项目管理

    项目进度表。文档交给技术开发以后,就需要制定一个项目时间表,并向领导汇报。首先要全面地收集他们在听完需求文档评审后对于产品本身的意见与建议,然后逐项予以合理的解释,以保证程序员哥哥们打心底里认同这个产品,认同这个产品的每一个需求。另外作为一个PM,也应该要对基本的开发流程有所了解在制定每个需求的开发周期时提出正确的建议,保证最终的项目开发时间表既不会拖慢整个项目的进度,也没有超出程序员哥哥们每天正常的工作量,保证他们不会感到过大的开发压力。
    进度跟踪。对于项目进度要做到心中有数,每天更新项目进度表,并帮助技术解决他们在开发过程中遇到的问题,并将自己看到的潜在问题尽量扼杀在萌芽中。当然,跟进并不是天天问工程师进度,需要给他们鼓励打气,并描述产品的未来前景,让团队中的每一个人都感受到自己的重任并愿意承担。可能有些团队里面是CTO担任项目经理,这也无可厚非,毕竟在项目成员中程序员占了大半资源,当然产品经理要尽量参与这个过程当中。不能当局外人。

    七、产品上线前协助测试

    大公司有明确的职位分工:工程师、测试、设计、运营都由不同的人负责,测试自然是测试工程师的事,而 在中小型创业公司,人员匮乏,很多团队只有工程师和产品经理,工程师负责开发,开发以外的事情全都由产品经理承包,这 其中自然包括测试。但无论如何产品经理都要尽量参与测试工作,保证产品是按照你的预期做出来的。
    (1).首先与测试组沟通协作,确定产品测试排期。
    (2).跟进测试进度参与产品测试。
    (3).将测试出来的bug记录下来,并拍好优先级,反馈给技术来发人员
    功能测试是合格产品经理的必备素质,产品经理要协助测试工程师完成测试报告并敦促工程师团队改进产品

    八、产品培训和推广

    给业务方培训、推广产品。客服可能需要给用户解答问题,所以每次迭代的内容都需要给客服培训,好让客服组织话术来应对客户随之而来的一些问题。同时也需要给市场、运营等部门培训,让他们知道产品到了那些阶段,有那些改变,一是让各个部门之间知道自己正在做的事情,二也好让营销市场部门做好宣传与推广。
    收集产品使用反馈,为迭代做准备。产品上线后设计的好不好,有哪些用户满意的,有那些用户不满意的。都会有用户进行反馈,收集并分析这些用户需求,并记录在你的需求池里面,为下一次迭代做准备

    九、数据分析

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

    十、总结

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

    相关文章

      网友评论

      本文标题:初级产品经理的日常工作流程详解

      本文链接:https://www.haomeiwen.com/subject/ggdpettx.html