技术转型产品经理:这是我对项目的一些思考

产品是对综合能力要求很高的一个职位,只有不断的思考、不断的更新知识体系,对这个行业充满着未知的探索,才能保持一颗初心,打磨出一款出色的产品。

毕业后比较幸运地进入一家较大互联网公司做了两年研发,在两年之内也接触了不少的运营和产品;做过大大小小的项目,由于想尝试自身更多的可能性,或者说得更直接一点,想成为一个决策者。

由个人追求的转变,于是决定转行产品经理。

有了这个想法之后,在工作时间之外开始学习产品的知识,从最基础的产品工具,到产品书籍,最后和几个朋友做了一些小的产品需求。

跳槽后,开始准备产品面试。

一、面试

没有产品的经验是很难面试上产品的。在面试产品之前,需要做好充足的准备。

个人是花了一个月的时间梳理自己的产品知识体系的,作品集是最好的体现。可以尝试着自己分析一款产品,写产品分析,从各个角度提出优化建议。也可把自己经历过的项目,从前期的市场调研、用户需求、交互体验、商业变现的过程整理成作品集。

除此之外,还需要看一些入门的书培养自己的产品感觉,从用户体验和商业价值去思考一个产品。

从工程师转岗产品,有技术能力固然是好的,但是千万不要让技术去限制你的思维—— 产品首先需要的是全局观,需要以结果为导向;不要拘泥于技术上的性能,加载等细节问题。 产品需要像小白一样去体验产品,如何把产品设计得高效、简单、让用户不需思考、如何实现商业变现才是需要考虑的事情。

二、项目前期

1. 尽快熟悉业务

公司业务是做产品的根本。

你需要清楚的知道你所负责的版块与哪些内容相互联系,他们之间的关系是什么?如果要改动其中的一块需要哪些资源,同时会不会对其他的有影响。

2. 做需求之前弄清来龙去脉

需求可能来源于运营,来源于销售,更多的是来源于老板,他们提出的方式可能是直接告诉你解决方案。

这时,产品需要做的应该是:问清楚他们的目的是要什么?这个需求是否合理?是否已经存在这样的解决方案只是他们并不知道?在确定之后自己再去想解决方案——因为别人提出的方案可能并非最优,并且可能不具有可行性。

举个例子(也是自己曾经踩过的坑):

我刚来公司的第一周,老板让我把某页面的某功能去掉,我就直接去掉了,结果造成了一大堆用户吐槽:怎么这功能突然消失了?最后又马不停蹄地把这功能加回去。

老板可能只需要把功能换个地方或者是换种方式展现——关于目的,一定要问清楚再去做。

3. 做场景分析

在写产品文档和写产品文档之前,需要尽可能多的根据业务做场景分析。

什么是核心场景?然后它附带的其他的场景是什么?再画一个核心流程图,当任务不在核心流程图上时要想好怎么处理。

举个例子:可能都是一个客服系统,但是基于需求不同,所以根本不可能照抄别人的设计模式。

市场上常见的客服系统都是比较完善的,有用户排队功能、客服评分功能、多线程处理功能、留言功能、统计功能等;但是这时你需要做一个即时会话的IM、并且你的客服只有2个,是用来专门处理某些用户的特定需求,并且这些用户提问的频率并不高——这时,你还需要上述这么多功能吗?你需要的仅仅的只是在线时的即时会话功能,离线时的留言功能,以及最简单的客户分配规则,其余的需求都可以后续根据情况再加上去。

4. 需求评审

在进行需求评审之前,产品文档要尽量写清楚,写清各种临界条件。

在开发对某些需求提出质疑时,首先要弄清楚是需求不合理还是需求无法实现。若是需求不合理,千万不要拿这是老板的需求说话,因为这会减少开发对你的信任。需要以自己的理由说服开发,做这个需求的目的是什么,能带来什么样的效果。若是需求无法实现,可以问无法实现的原因,或者告知自己想要的结果,让他们提供可以实现的解决方案。

有时候开发为了能够实现需求而采用一些降级方案,但是由于产品欠缺技术的原因,开发提出的方案并不能很好的理解并且造成一些问题,所以在做之前,需要确认:

  • 这种方案做出来是怎么样的,有什么优缺点?有什么弊端。
  • 如果无法知道做出来的效果。要说出自己的需求,这种方案要能满足需求。

避免最后发现做的东西不满意,但是能用,是一个残次品的情况。

在和开发确认完需求后,把修改后的需求文档发给开发确认,同时把产品原型给设计师。

5. 项目排期

在确定需求后,需要规定一个项目交付日,如果自己做的项目涉及到其他产品经理所负责的模块,也需要提前沟通协调。否则自己这部分做好了其他部分没做,浪费了开发时间,做的需求不能及时上线。同时为了避免中途被插需求和开发人员请假的情况,需要留一定的时间应对这种突发状况。

三、项目中期

这个阶段主要做的就是项目跟进,如果几天不问项目进度,开发干其他事去了,导致项目延迟上线。产品一定不能偷懒、不能偷懒。同时在过程中还能及时跟进开发所遇到的问题,有必要的时候需要修改最初的方案。

有些开发会经常忘记一些临时提出的一些优化小需求。首先产品经理要养成良好的习惯,尽量不要中途修改需求。如果实在需要修改,需要在原来的文档上批注说明,并且需要及时提醒开发。 如果公司有公用的wiki,那么可以更新在wiki上,如果没有,可以根据项目类型选择适合自己的项目管理工具。

根据个人的经验来看:

如果是琐碎型需求,没有明确的上下线时间,可以用wounderlist。一个人完成,直接勾掉,适合产品和前端之间的样式上的修改。如果是一个流程比较复杂的项目并且周期长,需要多人协作,可以使用tembition管理项目进度,把团队成员都拉入进去。

当遇到对设计师做的设计稿不满意怎么办?有时候设计师为了追求美观而忽略实用性,最好不要发生争吵,但是作为产品经理,先满足需求,再优化体验是必须要坚持的。这时候可以提供给设计师自己的想法和方案,同时自己也要多看竞品,精品,扩展自己的视野。

四、项目验收

1. 新功能的验收

新增功能,一定要注意验收。有时候不知道哪些功能会受影响,至少把相关的内容,同一个页面的东西之前做好的功能再检查一遍。

新功能上线,做好数据埋点。知道这个功能是否有人用,然后不足在哪里,收集反馈。再对反馈进行筛选,优化迭代。

2. 产品迭代记录

对于小公司,没有规范,发版也是想发就发,没有一个明确的时间。迭代的东西也没有记录,也没有发送给用户。首先,如果没有规范,需要自己去建立规范,规定在一个时间才能发版,这样有利于把控做事的节奏,同时也不会影响线上的功能。

产品迭代日志是很有必要的。一方面是告诉用户我们做了哪些迭代,一方面是日后总结工作起来也比较方便。同时如果新上线的有问题,也能快速地比较清楚的知道切回哪一版比较好。

五、其他

1. 定期汇报

定期向老板汇报比较重要,让他能知道你都做了哪些事情,进展怎么样,成果怎么样。

每次会议之后,主动发会议总结。

只有充分赢得老板的信任,他才会把重要的事逐步交给你。

2. 肯定别人

当与设计师、开发、老板意见不合时,不能只是与他们发生争吵,他们跟你是一个team,不是对手。应当认真听完他们的意见,毕竟每个人的想法都有自己的原因。所以尊重是第一步。如果确实发现自己的不合理,那么需要仔细思考别人的意见、虚心接受,提出更好的解决方案。

3. 多看、多思考、扩展视野

产品需要保持对新鲜事物的探索,每天阅读相关的产品文章、了解互联网圈正在发生的事情,保持敏锐的嗅觉。花一点时间去体验一款产品的优劣,学会总结和输出。只有不断输出,才能形成自己的知识体系。同时,产品经理除了要涉猎产品知识,对UI设计体验、市场营销,用户研究甚至技术都应该有基本的学习和了解,保证能跟他人沟通顺畅。

产品是对综合能力要求很高的一个职位,只有不断的思考、不断的更新知识体系,对这个行业充满着未知的探索,才能保持一颗初心,打磨出一款出色的产品。

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

题图来自unsplash,基于CC0协议

人人都是产品经理责编内容来自:人人都是产品经理 (源链) | 更多关于

阅读提示:酷辣虫无法对本内容的真实性提供任何保证,请自行验证并承担相关的风险与后果!
本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 产品设计 » 技术转型产品经理:这是我对项目的一些思考

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录