作为产品经理,你可能会忽视哪些实际上很重要的小事? - 91运营网
91运营VIP会员全新升级,尊享多项权益, 点击查看 >
X

作为产品经理,你可能会忽视哪些实际上很重要的小事?

发布者: 91运营  3788

系统学习运营课程,加入《91运营网VIP会员》,开启365天运营成长计划>>

作为产品经理,你可能会忽视哪些实际上很重要的小事?

本文会帮你产品工作中的2个问题:

1.日常工作中,产品经理经常会忽视哪些看起来很重要的小事?

2.产品经理如何与运营更好的配合?

今天在知乎里看到一个问题:

作为产品经理或产品负责人可能会忽视哪些实际上很重要的小事?

觉得这个问题很有意思,所以,这篇文章就根据我的角度来尝试回答一下这个问题。

题目既然说的是小事,那么我就不说产品经理最重要的一些事情,例如:

  • 我个人认为的最重要的四个素质:沟通能力、业务能力、理性思维、逻辑思维;
  • 产品经理基本工作内容的落地执行;

我们就尝试按照不同方面来列列看,到底有哪些事情是我认为同样很重要,但是可能其他人不这么认为的”小事儿”。

134 作为产品经理,你可能会忽视哪些实际上很重要的小事?

合作过程中多积累

产品经理经常需要和不同的人进行沟通和对接需求,例如公司领导层、运营、投放、商务、业务、设计、开发、测试等。

不同的人,都会站在不同的立场、出于不同的目的,向你提需求或者反馈意见。

在大前提他们的需求合理的情况下,你是直接根据他们的做了呢?还是多多向他们请教一下呢?

  • 运营投放们需要你配合的时候,不要以为自己不相干,要多看看他们的活动类型、多思考他们的投放渠道、多问问为什么这么选择;
  • 开发们围在一起沟通技术细节的时候,不要以为不关自己事儿,要多听听、多了解下他们是如何实现需求的;
  • 设计们出设计稿给你的时候,不要一味着收到稿子完事了,多和设计们讨论和请教一下,为什么这么做的原因;
  • 老板觉得要提前做某个需求,不要只把自己放在执行的位置,要多想想为什么这么做,对公司有什么好处,公司最近有什么变动,如果想不明白,可以尝试问问看;

这些都是宝贵的各个角度的实践知识啊,都是需要看专业书才有可能看到的东西或者有可能连书里都没有。现在,你通过一个个需求,就慢慢都了解了,这么一个大好的补充各方面知识的机会摆在你面前,怎么能浪费呢?

不说好处的都是耍流氓,这么做的好处如下:

  1. 对其他和你合作的人以及他所在的岗位有更深入的了解;
  2. 慢慢积累自己对各方的大概知识框架;
  3. 基于前2点好处,相互之间的沟通会越来越顺利;
  4. 在之后的需求时间预估和项目排期上会更加有把握一些;

摆正和各方关系的心态

产品人要端正几个态度,那就是:

  • 不要把设计师们、开发们、测试们当做实现需求的机器;
  • 不要把运营、投放、商务、老板等人当做只会提需求的臭傻逼;

经常在各种地方看到产品人在各种吐槽,例如:

  • 就是简单的移动一下位置、放大一下,想不明白为什么美工做不出来;
  • 一个简单的功能,代码狗们都搞不清逻辑,实在是太弱了;
  • 老板只会哔哔哔的提需求,太坑了;

你用这种对立的心态去看待你的伙伴、你的组员,那么你和大家的关系怎么会好呢?

人家跟你关系不好,更是不可能愉快的共事啦。

想让别人尊重你的前提是,你得尊重别人。

这么做的好处:

  1. 伙伴们能够在愉快、相互尊重的气氛中工作;
  2. 对于个人,是一种素质的提升;

320 作为产品经理,你可能会忽视哪些实际上很重要的小事?

多从整个产品的角度考虑问题,而不是仅从产品岗位角度考虑问题

举个例子:

  • 这个版本的需求都已经确定,版本上线时间也已经确定了。但是,运营和投放因为某种原因,要在下个版本做一波大活动和投放,需要产品这边配合开发一些东西,这个时候怎么办?

如果仅从产品岗位考虑问题的话,会觉得这个太临时了,如果应承下来做的话,不但要临时给自己增加工作量,还需要和设计师们、开发们重新沟通时间、调整计划,他们也可能因为临时的工作量而导致一些负面情绪的出现,你还得理性/感性的进行安抚。

但是从整个产品考虑的话,这又是一件需要并且最好做掉的事情。毕竟,在整个团队有数据压力的情况下,需要用一些外在方法来带来新增和日活,这样对整个团队都好。

再举个例子:

  • 一些小白产品们总是会纠结在一个公司里,到底产品更重要还是运营更重要的问题。总觉得公司重视运营,不重视自己,从而很难过。

其实,这种想法并没有什么意义,如果站在整体考虑的话:需要强运营的产品,自然偏重运营;需要强功能的产品,自然偏重产品。

偏重问题,只是量的问题,并不是质的程度。考虑怎么对产品好,这才是最需要纠结的问题。

这么做的好处:

  1. 对整体产品比较好,不会因为产品的私人考虑而有所偏差或者停滞;
  2. 对个人发展比较好,不断的锻炼自己的全局观思维;

多和团队伙伴沟通业务

有时候,能看到产品人抱怨他们的团队成员,比如:我们组里的人都不关心需求、他们只知道做,做了又做错,真是无语。

这个时候其实你要反思一下,是不是你从来不和他们沟通为什么需求要这么做,才慢慢导致这种情况的呢?

当然,我也清楚,不是所有的开发们、设计们都对为什么要做这个需求有兴趣,但是如果连懂都不懂,你怎么指望大家设计、开发出你想要的东西呢?

不妨在每个版本沟通需求的时候,顺便把每个需求这么做的原因也和他们沟通一下,不管是从数据分析结果、用户反馈,还是公司高层出于战略考虑,都可以说一说。

毕竟,我还是坚信,基于理解基础上的需求实现,从长远上看比较“安全”。

这么做的好处:

  1. 基于理解的设计和开发,可能能够在照顾到现有需求的前提下,考虑到一些可能的坑和未来的改动;
  2. 长久,大家会更有团队的感觉;

看数据结果前,辩证数据的真伪

很多产品经理会经常说,“从数据结果可以看出balabalaba…”,这都快成为一种口头禅了。

但是我要告诉你,如果数据本身就是错的,那么你所谓的数据结果就是个无稽之谈。

可能你会很疑惑,数据怎么会错呢?当然会啦:

  • 可能因为不同平台的不同算法,导致数据和你真正想要的算法不同,从而出错;
  • 可能因为开发埋点的时候不小心弄错了,从而出错;
  • 可能因为开发实现某个相关功能的时候,实现方式的不同,导致连带影响到数据偏高或者偏低,从而出错;

数据出错的可能性很多,因此,在说出“从数据结果可以看出”这句开场白之前,先去了解清楚数据本身是否出错。

这么做的好处:

  • 不会把时间浪费在错误的数据上;
  • 对数据分析会有更深入的理解;
  • 更容易得出真实的数据结果;

产品材料一定要文字留档

这是个非常非常非常重要的事情,请一定要记住。

刚进公司的时候,我发现公司里居然么有产品文档可以共享。了解产品基本靠多使用;要修改某个功能,基本靠经手人的记忆力。

这样是非常传统并且不科学的方法。一旦出现经手人离职的情况,接手人分分钟懵逼,说不定得让开发们找对应的代码才能仅仅解决了解概况这个问题。

而其中最重要的是,产品的增删演变历史以及对应的需求文档。

这么做的好处:

  1. 出现问题或者需要相关需优化的时候,可以根据文档找到具体参考;
  2. 从历史中了解变迁,有助于需求的管理;
  3. 有助于项目的交接;

需求要对接完整

工作中,会经常出现要和第三方沟通对接需求的情况,这个第三方有可能是公司外部的,也有可能是公司内部其他小组的。

有些产品觉得既然是技术对接,那么所有的事情就都可以等技术对接的时候再去做咯,然后就把所有的东西都丢给技术了。但实际上真是这样吗?

  • 也许流程可以先梳理起来;
  • 也许对接文档可以让对接方先准备起来;
  • 也许测试环境可以让对方先搭起来;
  • 也许要配置的接口可以让对方先设置起来;

和第三方对接,本来就存在很多坑(文档不齐、接口不ok、对接时间超长等等),产品最好要能够在对接前期先准备起来,这样开发们在对接的时候也会比较方便和省时间。

尽量把对接控制在可控制的范围内,而不是任由发展。

这么做的好处:

  1. 和你合作的开发们会比较舒服一些;
  2. 对接完成的时间相对可控一些,从而计划好的上线时间也相对可控一些;

要做好准备再拉人开会/讨论

越是工作到后面,越是讨厌开会,有时候甚至讨厌小撮人的讨论。为什么呢?

  • 往往没有一个讨论重点
  • 有重点,但是都是头脑风暴

没错,头脑风暴是好的,但是同一件事,如果每次开会都是头脑风暴形式的,那么是非常让人心烦的。

因此,无论是开会还是讨论,都应该在之前就列出讨论的主题、围绕主题的一些点。这样大家就可以根据列的内容进行有条理性的讨论了,从结果上,也更容易有效果,搞定事情。

 作为产品经理,你可能会忽视哪些实际上很重要的小事?415 作为产品经理,你可能会忽视哪些实际上很重要的小事?

不要害怕变化

举个例子:

  • 产品比较小的时候,需求可以有很多,面临的方向也可以有很多,大家都在进行不断的调整。
  • 这个时候,有可能会因为某些因素(公司要求产品盈利等等),而出现你原本安排好的下一版需求没办法做了或者需要推迟做,要优先做其他的。可能这个时候你已经做完了所有的需求分析,一旦改变,那么就要赶时间做新的东西了。

这个时候,你该怎么办呢?

我其实理解很多人会因为个人原因去拒绝这种变化,大家都是人,怎么会不明白呢?

但是,做产品人不可以这样,因为有可能会因为你的执意,导致团队在做错的事情。

这个时候,需要考虑的不是个人增加工作量的问题,而是对整体产品好不好的问题。如果确定对整体产品比较好,那么就该摒弃个人的负面情绪,顺势好好的执行下去。

这样做的好处:

  1. 对整体产品好、对团队成员好;
  2. 顺便锻炼自己的应变能力和心脏承受能力;

要把锅背起来

产品经理是需求的开始,也是需求的结束。只要上线了,那么就说明你是允许这个上线行为的。

如果上线后程序有大bug了、某个功能被用户骂死了等等,产品经理都要学会去负起责任,如果负不了责任,那么至少要先把锅背起来。

要端正自己的态度,不要出问题就赖开发码太多bug了、测试不给力什么的,毕竟,你才是最终决定上不上线的人。

这么做的好处:

  1. 团队对你有信任感;
  2. 个人学会承担也是一种极大的成长;

灵活看待制度

举个例子:

  • 一般公司都会规定版本上线的时间。但是如果App临上线前发现了一个大bug或者比较影响体验的bug。那该怎么办呢?
  • 是推迟上线,等修复后再上线呢?还是不管三七二十一,制度说要上,那就上呢?

不同人有不同的选择,但是出于对产品的考虑,是不是选择前者更为好呢?

一上线就bug反馈papapa,崩溃率papapa,用户差评papapa,这真是你要看到的结果吗?

你这个时候再去因为这些papapa去修复、去重新再上一个新版本,这又是多曲折。

当然,我并不是鼓励不遵守制度,而是说要灵活的遵守制度。毕竟,情况是复杂滴,人是活滴。

执行想法成功落地本身比想法更重要

很多人会说,“我想法多”、“我思维活跃”,但是想法多真的有你想象中那么重要吗?

想出来了,那之后呢?总要执行的吧。如果执行不了,那么你的想法就等于什么也不是。(当然,这里排除光靠想法去融资的,毕竟你的执行就是找到了人替你的想法买单)

不要不看重想法,但也不要把想法看的太重。真正创意意义上的想法,我认为注定是少数。而绝大部分的产品经理,你要清楚,你也许是暂时没有这个能力的。

你觉得我看死了你的能力?并没有。所有的创新其实哪里是凭空想出来的,都是基于对大势或是对环境或是对行业或是对用户的深刻理解,没有一定的经验是出不来的。我个人是不相信偶然事件的。

既然,暂时无法做创新,那么就该把当下的事情做好,在执行的过程中积累,为未来做准备,同时,从结果论上来说,也对结果负责了。

节操不要太高,但底线一定要有

很多产品经理很唾弃产品之间相互借鉴这件事,不管三七二十一,看你产品长的差不多就说你像素级抄袭,这其实是很呆逼的行为。(电商都长一样,你能说他们抄袭吗?)

我不是为了反对这些人的想法而反对,而是说:

  • 借鉴什么功能、适合用什么形态来展现,这些都是需要根据不同产品的特色去选择的、去体会的。即使是借鉴,也是做了大量的思考和改良的。而这个差别,就是有些产品能够借鉴成功,有些不行。
  • 跨界的借鉴从行业上来说更具有意义;

如果正向的解释你看不懂,那就从反向想一想:目前这个互联网上,有什么产品功能或者产品形态是真正意义上没人做的吗?如果真的没有,那么你赶紧拉帮人去创业吧。

既然是已经存在的事物,那么人家坑都帮你踩平了,你何不借鉴一下现成的东西,再根据自己产品的情况去改良一下呢?还非得自己去全部踩一遍坑才满意吗?

大家都是成年人了,就不要相信什么抄袭可耻了,应该认为借鉴有益才对;

大家都是成年人了,也不要太执着于自己的爱豆是乔布斯了,并不是人人都可以是乔布斯;

以上,对于“产品借鉴”的看法,是为了说明在很多事情的思考上,并不需要一板一眼。

能够解决问题的方法就是好方法,而不需要给自己设定一条无形的线,这个不可以做,那么不可以做。那样,你会把自己给作的累死。

虽然不需要那么有节操,但是底线还是要有的。违法乱纪相关的事情还是不能做滴,这个就不多加赘述了。

文 / 瑶子

来源 / 微信公众号  killlifer


勾搭小编微信号yujielin912,加入91运营官方社群,会运营的人都在这里了

加入vip会员
分享到:


扫码加入91运营社群