微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

近期有不法分子打着爱盈利的旗号,制作“爱盈利”名称的App,并伪造爱盈利证件,骗取用户信任,以抖音点赞赚钱或其他方式赚钱为名义,过程中以升级会员获得高佣金为名让用户充值。
爱盈利公司郑重声明:我司没有研发或运营过任何名为“爱盈利”的APP,我司做任务赚钱类产品从没有让任何普通用户充值升级会员。我公司产品均在本网站可查询,请将网站拉至底部,点击“关于我们”可查看爱盈利相关产品与服务。
温馨提示:当遇到此类问题请拨打官方电话或添加官方微信,以免财产损失。爱盈利官网地址:www.aiyingli.com。
  • 推广与合作
X

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

来源: 295127

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

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

对于一个刚毕业的产品新人来说,一上手就哐哐被安排了两个大项目,而且还没有人带,导致我踩了无数的坑。当然我要感谢我总监心这么大,就这么放心的让我去干了……毕竟有些坑是非踩不可的,早踩早吸取经验,也算是一种成长吧。做产品呀,最重要心态要好~

那么我就以一个踩过无数坑的小白的粗浅认识,来总结一下我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年的成长,是不是可以有更多望天的体会?到时候再来总结吧!

 

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

题图来自Unsplash,基于CC0协议

爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容;是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台;

想了解更多移动互联网干货知识,请关注微信公众号运营小咖秀(ID: yunyingshow)

评论

相关文章推荐

SELECT dw_posts.ID,dw_posts.post_title,dw_posts.post_content FROM dw_posts INNER JOIN dw_term_relationships ON (dw_posts.ID = dw_term_relationships.object_id) WHERE 1=1 AND(dw_term_relationships.term_taxonomy_id = 3083 ) AND dw_posts.post_type = 'post' AND (dw_posts.post_status = 'publish') GROUP BY dw_posts.ID ORDER BY RAND() LIMIT 0, 6

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved. 京公网安备 11010102003938号