入坑初级产品后,我学到的三个“怎么做”

怎么挖掘市场需求?需求有了,怎么表达出来呢?需求写出来了,接下来怎么和其他部门的人沟通呢?

对于一个刚毕业的产品新人来说,一上手就哐哐被安排了两个大项目,而且还没有人带,导致我踩了无数的坑。
当然我要感谢我总监心这么大,就这么放心的让我去干了……毕竟有些坑是非踩不可的,早踩早吸取经验,也算是一种成长吧!
做产品呀,最重要心态要好 ~
那么我就以一个踩过无数坑的小白的粗浅认识,来总结一下我 2018 年做产品的心得吧。希望日后再回顾这篇文章时,可以欣慰不曾再犯同样的错误。(为区分“产品经理”这个职务和“互联网产品”这个东西,以下简称产品经理为 PM,互联网产品为 APP)
PM 是一个什么样的角色?个人觉得,PM,就是千万用户的发声者。PM 肯定是最了解用户的人,并且可以站在用户的角度来审视自己做的 APP 到底是好是坏,然后自信的提出“这里不行,要改”。
当别人提出质疑时,可以很自信地反驳“我看了 10 万条用户反馈;拉了 500 人的用户群,每天以普通用户的身份和他们聊天;我发了 100 个社区动态,每一篇都可以获得用户 100 赞以上。没有人比我更懂用户!”这就是我总监在做管理者之前的日常,这样的自信,谁还能反驳呢。如果要让别人心服口服,就必须做到别人无法超越。
PM 一定是高要求的人,不能放弃对高品质结果的追求,不能太好说话,不能这也行那也行。因为 PM 后面还有设计、开发,如果第一道关就不严格,后面就会一点点打折,最后出来的效果可能只能达到预期的 60% 了。

怎么挖掘需求?

  1. 多用自家的 APP。
    把自己当成是普通用户,按照自己的需要去用 APP,然后在使用过程中感受自己的心理变化:用到什么功能的时候会觉得下次还想用;用到什么功能的时候感觉眉头一紧,搞不懂怎么用,或者和自己预想的操作结果发生了偏差。
    心理变化是很微妙且一瞬即逝的,所以要刻意练习,练习放大自己的心理感受,这一点我还没做得很好,下次试试用笔或手机记录下来吧!
  2. 多用别人家的 APP。
    同样类型的 APP,使用下来,一定会有一个最为喜爱的,至于为什么宠儿是这一个,就非常值得研究了。比如你拍了一张好看的照片想要分享给大家看,微信朋友圈、QQ 空间、ins、微博……
    你第一反应是上传到哪里?如果是我,我会首先上传朋友圈,为什么——因为朋友圈有很多我的朋友,他们会给我点赞,受到赞我会很开心。
    这么一想,微信就很值得研究了呀,它是如何做到现在的用户规模的?它的使用体验是怎么做的?它的每一次版本更新为什么要这么做?……
    作为 PM 新人,可能很多时候都是接到一个需求就着手开始做了,这个时候,个人觉得,比起临时抱佛脚的竞品分析,平时使用 APP 的积累更加重要。
    当你对一个功能束手无策的时候,如果脑海里立马就可以蹦出“我记得某某 APP 有这样的逻辑,我学一下”那就是很高效的一种办法了。
    能做到这样,就必须要多用各种各样的 APP,大致理解它们的逻辑。
    不要报以鄙视的心态去看任何一个能安装到你手机上的 APP,也许它界面真的很丑,也许它体验真的很渣,但是它一定有它存在的合理性。
    不能轻易去否定一个 team 的成果,几个人几十个人的头脑,加起来总不会蠢到哪里去吧。
    至于他们会什么这么做,也许是资源限制,也许是市场需要,这就需要深入研究了。
  3. 多接触用户。
    了解自己的用户,才能更好地了解他们需要什么样的产品,他们的需求到底是啥。
    多看用户反馈,能够来反馈的人,一定是真的喜欢这个 APP,希望它做得更好,所以他们的意见很有参考价值。
    多看用户评论,社区类的、短视频类的产品,有很多用户之间的互动,比如我没事的时候就喜欢刷抖音,而且每条必看评论,评论里会发现很多有意思的人,有的时候看一些评论,你会觉得“卧槽,居然有人会这么想?”没办法,这就是用户呀,有着各种奇妙的想法和心里感受。
    了解别人家是怎么做的,为什么这样做;了解自家的用户需要什么样的功能,这样,才能挖掘出真正的好的需求。

怎么写需求?

  1. 确定需求列表。
    拿到一个项目课题的时候,先挖掘需求,然后整合这些需求,按照 APP 的框架用脑图把需求列表先画出来,然后做取舍,哪些要做,哪些不做,哪些下一个版本做。需求列表中只需要写明“做什么”,不需要写“怎么做”。
    比如:天猫精灵 APP 项目→设置→音量设置 - 手机调节天猫精灵音量。列出自己的需求列表之后,一定要及时和老大沟通,反复讨论,反复确认。
    首先要确保在“项目大体逻辑”这个大方向上自己的想法和老大的想法保持在统一战线。否则如果按照自己的想法往下做,错了就是完全自己背锅,如果是老大的决定,那至少大家都不会怪一个新人。
  2. 画高保真原型图。
    确定做什么之后,就是怎么做了,我学到的习惯,是先画出原型图,再写相关的逻辑,原型图画出来,界面上需要什么元素有了,写逻辑的时候就基本不会漏掉某些功能。如果没有头绪,不知道怎么画图,最基本的办法,看看市面上类似的产品,把图 copy 下来。
    年少轻狂的时候,我对于 copy 这件事也是嗤之以鼻,总觉得那是一种很 low 的手段。但是认清现实之后就发现,“抄”也是一门艺术。
    创新固然是牛逼的,但是如果我自己做的创新就是不如市面上有的,那我为什么不吸取他们好的地方呢?
    “抄”来的界面只是最表层的东西,具体的逻辑、这句文案怎么写、这条分割线怎么放、这个按钮什么样式,这些全都是我自己研究出来的东西呀。
    做 PM 不能没有 UI 的感觉,如果只会写逻辑,那跟 UI 设计师沟通的时候就会非常吃力,你看到一个 UI 界面,你感觉不对,但就是说不出哪里不对,是不是很难受?如果你可以一眼看出这个字号不对,这个配色不是我们 APP 有的配色,这个行高有问题,那么就会在 UI 设计时占有主动权,也可以 push 设计做得更好。
    怎么训练自己对 UI 的感觉呢?copy+ 思考,这里指的是平时有空的时候,临摹各家做得好的 APP 界面,像素级 copy,边画边思考,为什么这么布局,图片尺寸为什么是这样,字间距、行高为什么是这样,字号、配色为什么是这样的。
    这样做的效果也许不会在平时工作中立竿见影,但是潜移默化的会让自己有一点 UI 的分寸吧。拒绝做设计师口中的傻逼 PM。
  3. 画交互逻辑图。
    简单来说,就是页面之间的跳转,页面元素的点击之类的,需要整体列出来,一个一个界面排好,用箭头指示这一步跳转到下面那一步,之类的。这一个步骤,在大项目中非常重要,如果不梳理整体的逻辑,而是直接开始写每个界面的逻辑,就会纠结在细枝末节上,而对整体失去把握。
    画出一份这样的逻辑图之后,跟老大、业务方、开发沟通的时候,就会轻松很多,可以让他们先在脑海里对这个项目形成一个大致的概念,这样他们也不至于看着你的需求懵逼,不知道这是个什么鬼东西。
  4. 地毯式写需求。
    如上述,已经画出了原型图,那么就可以开心的写逻辑了。对照页面上的元素,从头到尾,一个一个来。
    五字秘诀“增删改跳空”——交互(点击、跳转……)、显示(最大字数、图片尺寸、配色及蒙层……)、规则(出现、消失、位置、变更……)、特殊情况(网络问题、为空情况、错误问题……)。

怎么沟通?

  1. 换位思考。
    PM 最常沟通的人应该算是程序员吧,程序员每天都跟代码打交道,他们对于一个需求的理解方式一定和 PM 是不同的,但是恰好 PM 写的需求是给他们看的,所以必须要让他们看得懂。这就需要换位思考,既然我的思考方式他们不理解,那么就试试他们的方式来思考。
  2. 确保理解。
    因为大家对需求理解不一致的缘故,最后做出来的东西根本不是我最初想要的,然后要不就是我妥协,要不就是改代码,反正搞得大家都不会很愉快。这是我曾经踩过的坑,如果我可以确认大家都对需求有统一的认知,那就可以避免这个问题。
    上面有提到,画整体的逻辑图,就是帮助其他同事理解我的需求的方式之一,首先让他们对项目有一个整体的概念,要让他们先知道我要做的是一个什么东西,我为什么要做这个东西,他们理解需求来源和整体之后,就不会跑太偏了。
    我遇到过很坑的,可能也是比较常见的沟通失误,就是讲完需求,跟开发确认是不是都理解了,然后开发大大们很愉快的说理解了呀。
    但是做的过程中再确认,就发现,嗯?怎么和我说的不一样啊,理解偏差了啊……
    避免这个问题,大概就只能反复和开发沟通吧,就是多讲几遍,给他们灌输,讲一遍,问一遍“我表达清楚了么?”然后最好让他们复述一遍看是否有偏差,这样反复确认。麻烦也没办法,总比代码写完了再来改要好,一定要先确保需求没问题再开始写代码。
  3. 不要放弃对结果的高要求。
    如果你想做一个 100 分的好结果,你把项目交给设计、开发之后,他们出来的结果打个折,可能就只剩下 80 分、60 分了……
    PM 是一个把控全局的角色,首先要坚定自己对结果的高要求,不能自己这里就先给了一个 80 分,那后面分数就只会越来越低。
    举个例子,如果一个设计稿出来,不去挑毛病、不去优化,直接就去开发了,开发过程中还有样式的偏差,那最后做出来的页面根本就不能看了。但如果在设计阶段可以有更高的要求,逼一把设计师,出多几稿,对比得出最好的,那后面就会稳妥很多。
    任何时候,都要想着“我要做到 100 分,做到最好”,那如果客观原因做不到 100 分,最后出来的结果也不会差太多。
  4. 需求变更咋整呢?就可能心态要好吧,拥抱变化,以不变应万变吧。
    需求变更是不可能避免的,因为业务方总会有新想法,老大总觉得做得不够好。
    变更一定要及时,第一时间先通知开发暂停相关需求开发,将大致逻辑告诉他们。然后再尽快整理文档同步。这样做可以节省下开发不必要功能的时间,时间就是金钱,能省一点是一点。
    因为过多的需求变更,引起开发小情绪的时候,等他们冷静一下后再把需求要这么做的理由跟他们讲清楚,理由一定得有理有据且逻辑清楚,加上业务方面和公司利益方面的考虑效果更佳。开发们也是讲道理的,而且相当敬业,所以不会打死 PM 的。
    以上,大概就是 2018 年我做 PM 踩过了一堆坑之后的个人经验。都说 PM 要望天,但是我个人觉得自己现在基础技能掌握的还不够,所以总结的都比较浅显易懂,比较适合日常工作。
    期待一下我 2019 年的成长,是不是可以有更多望天的体会?到时候再来总结吧!
     
    作者 @小仙女仙女儿 。