推荐 | 做C端产品经理一年多了,这是我的总结

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

作者从事产品岗位已经一年多了,负责的内容也都是C端的前端产品规划及产品设计的内容,有从0到1,也有从1到2,经历过一周需求到上线,也经历过效果不佳而迫停,走到现在也是一路坎坷。将这一路总结成文,希望对你有所帮助。

zongjie

回顾一下,把自己踩过的坑和经历总结出来,给自己一个成长的总结,也给一些产品新人提供一些经验。

市面上的产品多种多样,但是每个产品从概念到成型的历程一般都脱离不了用户体验要素中所提到的战略、范围、结构、框架和表现五个层次。每个层次对于产品经理的要求也不尽相同,也从一定程度上要求了产品经理必须是一个全能的职业。产品经理在工作中是贯穿整个项目过程的,从需求到上线,包括后期的迭代,大部分工作都是由产品经理来策划跟进推动的。

一.需求到功能

1.产品的需求来源

通常有几种:

  1. 团队内部
  2. 竞品(同类产品、有相同特质的产品)
  3. 运营、老板等外部因素
  4. 用户调研;

对待不同来源的需求要采取不同的方式应对,目的都是收集需求。

1

团队内部的需求通常来源于头脑风暴,少部分来源于某些团队成员的会外建议,这部分人对产品本身的认识是最深刻的,提议的出发点通常是产品本身。

来源于竞品的需求通常是说服力比较高的,但是在分析需求的过程中记得考虑下用户在什么场景下会产生这种需求,尤其是竞品产生新功能的时候,尤其注意这时候功能的复制是不是合理的。

运营和老板的需求我把他们放到一起,这类需求的来源通常让产品经理非常被动,通常他们会说我们的产品为什么没有XX功能,为什么我们的功能和别人不一样,作为产品,不要偏听他们的一面之词,要挖掘到他们提出需求的本质,并且注意他们只是需求提供者,并不是方案提供者。

用户调研也是比较有效的一种需求来源,通过用户访谈,观察用户使用同类产品或者同类功能时的行为,甚至通过问卷来分析用户的心理情况,都是可取的,但是操作过程中也要注意用户的“说谎行为”,产品完成后使用者的反馈意见也很重要,也是收集需求的一个有效渠道。

需求收集后,建立产品需求的需求池,以便于对需求进行分析管理。通常需求池的模板如下:

2

2.需求整理

需求整理是每个产品经理都要掌握的技能,而且每个产品经理采用的方式不尽相同;一个产品的服务对象永远不会是所有人,这里介绍一个比较常用的方式,5W2H的方法,分析受众(WHO)在什么时间(WHEN)什么地点(WHERE)因为什么(WHY)去做什么(WHAT),怎么做(HOW),会付出什么(HOW MUCH),以此来定位该需求是不是伪需求,如果不是伪需求,对应该需求用什么功能来解决。

3

3.需求分析

以KANO模型去分析需求中的基本型需求、期望型需求和兴奋型需求,以此配合产品的当前发展阶段来给需求进行分期完成。

(下图来源于人人都是产品经理《需求评审之前,需求挖掘和需求管理怎么做?》)

4

该文中作者还对KANO模型做了一系列的延伸,在基本型需求、期望型需求和兴奋型需求的基础上增加了无差异需求和反向需求。

基本型需求是必须具备的,用户觉得是本来就该有的,一般是产品的基本属性和基本功能;

期望型需求是用户期望有的,没有可以接受,但是有了会非常认可;

兴奋型需求是用户所没有想到的,超出用户预期的需求,提供后用户会产生惊喜;

无差异需求是有没有对用户都无所谓,用户不在意;

反向需求则是用户根本没有这种需求,提供后会影响用户的满意度。

5

基本需求通常是产品最基本的功能,不能缺少,不然不足以支持整个产品的功能及框架;期望需求也是产品第一版本所需要考虑到的内容,如果功能缺失造成用户的体验不好,会造成很大程度的用户流失;而对于兴奋型需求,往往是产品的卖点,但是在资源或时间紧缺的情况下可以考虑适当延后,但是最终还是要落实到产品上;无差异需求可以考虑下商业价值,如果在不影响用户的情况下获取利益,是最好的方式了;反向需求就像产品中的广告,用户很讨厌,但是为了商业价值还是要妥协。

6

二.功能到结构

这个内容的主要目的有两点:

  1. 产品功能的层级结构的确认;
  2. 对功能实现的成本进行预测;

用户在使用某个功能时的有关因素包括:用户自身属性,场景属性,用户行为属性;每个因素都对用户使用该功能有着不可避免的影响,在确定产品功能的重要性时需要给每个影响因素设定一个影响指数,和每个因素在产品中的比重值。

目标用户人群的基本属性指数a(性别,年龄,职业等自然属性),用户基本属性的比重值为x;用户的行为属性指数b(兴趣,习惯等),用户行为的比重值为y;场景属性指数c(时间,地点,环境,要做什么等),场景属性比重值为z;该功能在产品中的重要指数即可通过a*x+b*y+c*z进行一个粗略估计。我通常取值a+b+c=1,x+y+z=10,这样获得的数值对比性比较明确,参考性也比较强,有一定数据时获得的结果准确性更高,有一定量数据的情况下参数的取值也要根据数据而定,不能根据猜测来判断。功能的分类也通常是根据场景来划分的,而一些使用频率不高的功能就会选择弱化一些。

这个过程通常可以把产品中每项功能的重要性和层级展示出来,为后期的产品设计提供很强的依据。

7

其次,在功能确定之后,需要带上团队的设计师及开发人员进行工期预估会议,这个会议的目的有两个一是为了给项目一个大概的节点,使项目从开始到上线的过程中有一个计划,便于进行时间管理和提高团队效率;第二个目的是要在会议过程中判断某些兴奋性需求的功能实现性价比,能否在不影响整个项目进度的情况下把产品功能做的完美,还是因为时间问题把一些功能延期,产品经理也要在这个过程中慢慢的学会自己判断功能实现的时间成本,避免因为没有经验而被程序员忽悠。

三.结构到框架

产品结构到产品框架的过程可以说是产品经理到交互设计师的交接过程,然而大部分公司都是由产品经理把这部分工作做掉的,这个环节主要包括三个方面:产品的内容设计,产品的操作逻辑,页面上的框架布局,体现到成果上即产品内容及产品原型和逻辑图、时序图等。

内容设计

产品的内容设计是产品的内容核心,通常也是一个产品的立足之本,没有好的内容就不会有好的体验,即使页面效果做得再好,对用户也毫无吸引力。相反,如果产品本身的内容质量足够高,哪怕在功能和页面上有瑕疵,也可以通过快速迭代的方式来改善。简单举几个例子,爱奇艺、腾讯视频等播放器需要足够的视频资源及分类;直播平台的主播及直播内容都可以说是平台的内容;只有内容的定位精确和资源足够的情况下,产品功能的设计才有意义。

操作逻辑

操作逻辑是所有产品体验中必不可少的一个环节,无论是前端还是后台都非常重要(当然区别在于前端重体验,后端重逻辑,权重值不同)。产品的定位用户通过聚类和分类后都可以把用户分为几个固定的群体,每个群里内的用户存在几个或多个共同的特点,或者说有一些相似的用户习惯,针对主要用户群体的用户习惯形成的操作逻辑和操作方式,用户活跃程度才更容易保持。操作逻辑可以简单分解为信息传递和操作反馈两部分,信息传递是产品页面上给用户传递的信息及可操作性,操作反馈则是用户产生操作行为后会有一个假象的反馈,或者说结果,而我们的任务就是去设计应该给用户什么样的反馈及以怎么样的形式来展现。

8

原型设计

原型设计是把需求传达给设计师的媒介,也是对产品框架的设计,同时也是产品经理的入门基础。绘制原型的目的主要包括几个方面:

  1. 搭建产品框架,清晰的表达思路;
  2. 提高效率,减少和设计师、程序员的沟通成本;
  3. 为产品备案。

首先在绘制原型的过程中,产品经理对产品逻辑和业务逻辑会有更深入的理解和思考,产品逻辑出现问题时也可以及时的进行修改;

其次减少沟通成本,一是减少和项目组外成员的沟通成本,通过原型的展示使产品逻辑更直接的展示出来,使更容易理解产品;二是减少产品设计开发中的沟通成本,好的原型可以减少很多的口头沟通成本,而且复用性很高,产品设计开发过程中可以节省很多的时间。最好每个项目组或者产品团队要有自己的原型设计规范,一方面是为了原型设计的美观,另一方面根据规范撰写的产品逻辑和备注说明更容易被设计师和工程师理解,其次在原型设计时可以节省很多时间。最后根据产品规范设计的原型可以更方便的让新人学习,减少培训成本,在产品负责人缺失时后续产品可以更好的衔接上。

四.框架到设计

UI设计:UI设计主要的工作内容就是把产品设计优化然后展示给用户,然后交付到开发实现。关于设计所涉及的几个问题:布局、配色、文字、按钮、切图、适配。其中布局、配色、按钮和文字在每个不同的产品中都有不同的规范标准;而切图和适配则是UI行业内统一的规范及标准;

PCweb和APP的差别较大,手机web则可以看做两者之间的过渡。当然目前APP更热一点,以app为例,建立规范和标准,另外最好用一套规范去适配Android和iOS两个平台来降低设计成本。当然每个产品的标准和规范并不相同,在此以APP为例举个例子:

关于尺寸:

9

标准色:

10

标准字:

11

按钮:

12

13

14

这只是一个粗略的设计规范,另外如何划分模块、图文间距、公共控件等都需要有一个详细的设计规范,希望大家都配合设计师确定一下。设计稿评审通过之后,标注切图交付到开发。

五.设计到开发

设计图完成之后,按照功能或模块把产品拆分开来,进行开发评审会议,主要目的为分别确定功能完成所需时间同时确定功能开发的优先级,该会议需要前后端和产品同时参与。按照功能或模块的优先级把任务安排到前后端负责人。

前端确定开发的页面量级和难度,难点需要整理出来确定解决时间(特别困难的情况下衡量下需求是否要简化或者延期)。

后端确定需搭建或维护的数据库,需要的接口量级,难点需要整理出来确定解决时间(特别困难的情况下衡量下需求是否要简化或者延期)。

注意把控开发进度,两个点:一个时间,一个效果。时间是按照项目规划按时完成,一般每天最少一次跟进下进度,尽量把任务分配到天,每天都完成一部分。另外实现效果不能防水,以一个高标准去要求最后的产品效果,即使最后只能达到80%,也是一个可以推出的东西,如果以80%的效果去要求,最后很可能连60%都打不到。

最后一点,尽量和开发打好关系,尤其是经常给你干活的开发,处理好关系给你的帮助会远远大于你的付出。

六.产品的迭代

不论是硬件产品还是互联网产品都逃脱不了产品的生命周期论,这就无可避免的需要产品进行迭代,而互联网产品的迭代频率又远远高于硬件产品,迭代的过程贯穿在整个产品的生命周期中。

互联网产品的生命周期中,导入期通常是产品一期产品的推广和迭代,用户量会逐渐增多,需求的数量也是逐渐增多,这个过程会一直持续到产品的成熟期,在成熟期阶段,产品的新需求会越来越少,更多的是产品的维护和调整,而用户量还是会缓慢增加;当到达衰退期时,需求会严重减少,而用户也会在这个阶段去寻找更好用的产品,这时产品通常需要一个大的改版来挽留用户,如果成功,则会把产品推入到一个新的产品生命周期。通常一个成功的产品是需要持续对市场产品进行调研分析,然后对自己的产品进行调整和迭代的。

15

产品迭代和产品创建过程中的需求来源是有很大区别的。前期的需求来源比较简单,后期迭代中的需求更多的需要依靠数据统计和用户反馈来进行改版。大到一个模块、一个功能,小到一个按钮、一个色块,在迭代阶段不能是简单的拍脑袋,而是需要一定的数据支撑;日活、留存、点击量、转化量都是参考;改版上线的过程通常也是以灰色发布为主,A/B测试就是其中一种,通过两种方案的数据对比来获取最终选择方案,过程比较缓慢,但是很有效果。

产品迭代的时间规划视团队内部的合作方式而定,频繁无周期的改版和长周期改版都是不合理的方式,前者影响工作效率,后者影响产品更新进度。建议在没有大调整的情况下2-4周做一次改版,而且周期固定,形成团队的工作习惯;当有大的调整时,视资源和开发进度在时间上进行调整。

这是我工作一年的小结,希望可以互相交流。

 

作者:点点(微信号gonoway),产品经理,1年产品设计经验,新人上路,大家多多指教。(且行且珍惜,新人互勉)

本文由 @点点 原创发布于人人都是产品经理。未经许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。
1人打赏

评论( 65

登录后参与评论
  1. 你们公司有没有项目经理?就是统管技术的。以前我们也是没有,后来发现一个产品经理对接几十个开发,而且是4端,根本吃不消。后来有了项目经理,不管是产品评审、技术执行和产品质量都会有很好的把控。我是从创业公司从0到1,从什么规范都没有到今天乃至以后一点点摸索实践出来的。还有就是跟技术部搞好关系真的很重要,我没事给他们就自己掏腰包买点水果什么的,也会在上线前陪着通宵,让大家觉得大家是一起奋斗的兄弟。一点点经验,我也是汽车行业,以后希望能多交流。

    回复
    1. 回复

      也没有项目经理,同苦逼 哈哈

  2. 为啥感觉说说就越来越像B端。侧重点不是C端吗

    回复
    1. 回复

      没有啊 你觉得哪里像B端呢

  3. 大神求带啊,我20岁了,可以交流、交往一下吗

    回复
    1. 回复

      你是黑哥吗 求交流啊 不交往啊

  4. 666

    回复
    1. 回复

      谢 谢

  5. :grin: :grin: :grin: :grin: 大神 ,我是职场小白,求带求带求带

    回复
    1. 回复

      互相交流 :!:

    2. 回复

      来呀,加我呀

    3. 回复

      :?: 我咋加你啊。。我的微信在呢。。你搜一下就有了。。

    4. 回复

      不会搜。我没有微信啊。

    5. 回复

      额 那我确实没辙了。。 :shock:

    6. 回复

      哦,我17岁,你呢?

    7. 回复

      17岁。。做产品吗。。我25了。。

    8. 回复

      是啊。

    9. 回复

      666666

    10. 回复

      嘻嘻嘻 只是跟着凑热闹,,,我还学生呢

    11. 回复

      66

    12. 回复

      这段对话看得我方了

    13. 回复

      哈哈 我后来看看都觉得醉了。。

    14. 回复

      感觉很方法论啊~而且很多时候需求不是只看用户喜欢不喜欢就能决定的,有时候要考虑到行业因素在里面,甚至用户有好几类对象~另,我是来盖楼的~~

  6. 新人刚入行,谢谢

    回复
    1. 回复

      我也刚做一年多,多多交流 :mrgreen:

  7. 整理的不错,入行一年,有如此深的理解,真心不错。赞一个。

    回复
    1. 回复

      谢 谢

  8. 作为正准备入行的我来说,这篇文章无疑对我带来了莫大的帮助~赞

    回复
    1. 回复

      希望有帮助 哈哈

    2. 回复

      能看懂上面的文章 你就是一位合格的产品经理了

  9. 为什么要尽量和开发搞好关系?说得好像开发像老大一样233

    回复
    1. 回复

      :!: 你如果是技术大牛是不用考虑的 但是我是技术小白 搞好关系他们就会把架构搭的好一点 坑埋的少一点 有坑会及时跟你沟通 不会出了问题直接把锅踢给你

    2. 回复

      我觉得是不是大牛都应该跟技术搞好关系,不是说谁是老大的问题。
      首先产品经理靠综合素质吃饭的,本身EQ和协调能力就必须高于研发人员,作为润滑剂周旋于运营部,产品部,研发部之间,别人要给认可你才容易展开工作。
      第二心甘情愿合作和被从属关系压着合作完全是两种不同的状态,尽可能让人跟你心甘情愿合作。
      第三,假设研发很忙,你有一个事情对自己很紧急也很重要要找他协助,而另外一个人也有一个事情找他协助,人一般优先会帮自己关系好的人解决问题。

    3. 回复

      感觉很厉害了,我也是新人, :cry: 路还长着呢

    4. 回复

      :arrow: 不会跟技术沟通咋办,感觉说的技术都听不懂,无法交流的感觉啊

    5. 回复

      需要有个过程的 就像做产品。。从开始的不懂到熟悉。。多跟他们聊天 多混混 没坏处的

    6. 回复

      得罪开发,小心留一堆bug,还是要懂一点后台、接口、表单等知识才能用共同语言交流。

    7. 回复

      开发一个产品的工作量是非常大的,有时候产品经理一个小小的改动就意味着程序员要不眠不休的奋斗几天,所以程序员不待见产品经理很正常。而且写代码的工作产品经理基本上干不了,就算程序员偷懒给你挖坑也看不出来,到时候出问题还得产品经理吃灰。

    8. 回复

      还是要懂一些后台的东西的

  10. 厉害,同样工作一年,感觉跟你的差距好大

    回复
  11. :sad: :sad:

    回复
  12. 看的出作者所在的公司应该是比较有实力的,有较为规范的工作流程和知识沉淀;作者总结的很好,值得学习。

    回复
  13. 写的确实不错,很受用

    回复
  14. 产品0~1的过程基本涵盖了,不过设计规范觉得不太对,一个按钮要240x100px?类似的小毛病吧,不错!

    回复
  15. 第一次评论,写的真好!

    回复
  16. 好赞

    回复
    1. 回复

      谢 谢

  17. 亲,需求整理的5W2H-倒数第二个应该是who吧?

    回复
    1. 回复

      是的。。。写错了

  18. 好文章

    回复
  19. 写得很棒,非常值得学习

    回复
  20. 整理的很好,学习学习! 感觉你是女生吧

    回复
    1. 回复

      我是汉子。。

  21. 写出来这样的文字,不像新人,不错

    回复
    1. 回复

      哈哈 谢谢啦

  22. 研究很细致,值得学习~

    回复
    1. 回复

      说不上研究 只是偶尔总结总结

  23. :oops: :oops: :oops: :oops: :oops:

    回复
  24. 确实给我很多启发,还列出很多具体方法

    回复
    1. 回复

      多多交流,互相帮助

  25. 其实都是比较浅的东西,只是整理了一下,需要学习的地方还很多,欢迎大家多多交流。

    回复
  26. :razz:

    回复
  27. :grin:

    回复
  28. 的确是好文章

    回复
    1. 回复

      谢谢

加载中