产品路上的反思:春播秋收,稻谷满仓

因为工作变动,突然有了些时间,让我去思考和复盘过去的产品工作,有一些是越来越深的体会。本想理出一条线去讲,为了践行文中的「体会」,知行合一,就先「上线」吧。

项目与产品

过去一年里,认知被刷新了好多次了。很多知名产品,从外面看上去,挺厉害的。通过朋友了解,产品使用的技术和运营策略都粗糙要命。了解得越多,越是让人惊讶「这样也行?」。有时想想,是不是自己做产品考虑太多了,要再放开一点?
所有的产品都应该以项目为开始,做项目的原则就是快速完成。能做的,不能做的,给用户说清楚,他们能理解。定好时间节点,按期交付,不要让他们失望。
不要奢望一开始就能提供稳定可靠的产品,把时间花在优化上。你不能想着一路飞奔,还要保持衣衫整齐。一边盖楼,一边灭火是常态。把握好度,不要烧到自己。给一个时间期限,拿到拿到目标。快速满足他们并验证需求。
人们喜欢立杆见影的事情,快速反应,满足他们。不论是 B 端还是 C 端产品,都是一样。如果你的产品无法满足一小撮人的需求,就不要去期望能够满足其他用户。这样只会浪费你的用户资源。

目标与妥协

有分歧就有争执,有争执就要有一方妥协。市场等着新功能,运营等着要做活动,产品上不了线,产品肯定承担大部分责任。产品要跟多方打交道,既要把持做产品的原则,也要平衡产品短期目标与资源不匹配的矛盾。不同阶段,产品的重心都会不同。工作中,协调好多方关系,持续推动产品前,按计划上线,才是首要的。
创业公司,都是跌跌撞撞前行。前几天,同事问我,产品今晚要发布了,发现个问题,怎么搞?我说,产品发布前发现有问题,并不是什么意外,就看问题大不?如果问题简单,问下相关人,来得及改,就赶紧改,来不及就不要改了。如果问题较大,就砍掉这个功能,但产品还是要上线的。
你看,除了人以外,你还要跟产品妥协。不论你和团队前面做了再多的努力,产品上不了线,就意味着你和团队的成绩为 0。考试的时候,不会因为你题没做完,给你延长半个小时。考得再差,都是要交卷的。与自己妥协,为整个团队负责。

压力与动力

自从做产品以后,一直觉得很有压力,这是做开发没有的感觉。刚开始特别大,现在好一些,但一直都在。产品需要持续地迭代,你就得持续思考产品的各个方面。产品现在的发展处于什么阶段?在市场上处于一个什么样的位置?有没有偏离既定的方向?市场的竞争状态是什么样的?产品应该要往哪个方向发展?中远期的规划是什么样的?
做产品,时刻受着各方面的挑战。当我感觉压力很小的时候,做事时明显会感到动力不足。主动性一降低,就很难去想得深,做得深,把产品给做好。当我感觉压力很大,特别是压力来自不同的方向时,会变得慌张。心态不稳,打出去的动作就容易变形。好在的是,我会给大脑设定一个在压力表,时刻监控自己的压力值。当这个值过高或过低时,我都会提醒自己,先停下来缓一缓,调节一下,然后再去做事。
想想你做产品的压力感觉,判断下自己是否走心,或是用力过度。

工作与生活

做产品,很难平衡好工作与生活的节奏。因为产品的使用是不分工作和生活,你需要付出时间去观察,体验,思考产品。所以,能快速地在生活与工作之间进行切换也成为一种要求。
对产品的思考本最终反映的都是对世界和人的理解。你理解地越深,自然越能明白人们需要什么,为他们提供什么样的产品。产品的使用场景本就源于生活,能提供为你大量的启发点,也能拓展你的思维。
生活是为你自己,工作也是。如果你想划清生活与工作的界限,就要考虑什么时候该做什么。这会增加你的时间成本,并不会让你感到轻松,还会失去很多的机会。

市场与前线

曾经,一位地推同事跟我说,我们公司的产品从来不下市场,只待在公司。你来我们公司,是第一个去跑门店跟客户做调研的。我有些惊讶,这不是产品应该做的事情吗?后面,跟一些朋友沟通,发现很多的产品都没有跑过市场,跟他们产品的用户对过话。
产品经理必须要站到最前线,听到炮声。只有这样,你才能切身感受到战场的真实情况。做物流软件时,每个季度都会出差去物流网点,每次都待一个月左右的时间。给他们帮忙,当开单员去操作电脑,真正地「Eat your own food」。因此,我对网点物流活动的每个细节都十分了解,从收货,开单,仓储到装车,发车等整个环节,都一清二楚。每一个环节活动是什么样的,有哪些人参与,用时多长时间,有哪些痛点。他们什么时候忙,什么时候不忙,忙与不忙的时候在做什么,需求有哪些变化?
坐在办公室里,就不可能了解这么多。只能听运营、销售、市场人员给你讲,用户需要什么,你要做什么。你没有足够判断力,去分辨他们需求的真假,轻重缓急。你还可能被他们牵着走,收到他们自己都没想清楚的需求,做着更糊涂的设计。但你又不能有理有据地反驳他们,因为他们看到的比你多,了解得也比你多。这种情景我见过多次了。

资源与边界

处不同位置,想做的事不一样,对资源的理解也不一样。做老板呢,有一万块钱,肯定是想着做一百万的生意。换谁做老板,可能都会这样想。做员工着,就想着有多少钱做多少事情。这个倒不是说员工拿一分钱做一分钱的事情,而是两者从不同的视角看产品。如果公司资源有限,什么事情都想法,肯定会出现资源竞争和管理的问题。
公司的资源一定是有限的,如果产品多了,资源一定会出现紧张情况,影响产品的持续发展。作为产品经理,是要认识到资源的界线的。在这个边界下,做得了什么,做不了什么。
老板和员式的需求都要兼顾。边界需要突破,事情不可能都得等到资源到位再做。开了头,上了车,大家也就有动力去做。而边界扩张的度时刻要注意的,不能影响着核心业务的发展。
产品的核心业务跑起来了后,公司也会想着尝试很多的新业务。公司的资源是有限的,分到多个业务上,平均下来可能都差不多。但要保持新业务的敏感,只要有一个业务跑出来,就可以将其它业务打包起来,辅助成功的业务,尝试的意义也就突显出来了。

现实与愿景

创业公司,没有什么比活下来更重要的了。不要上来想要打败谁,取代谁做第一。对自己没帮助,反而看不清自己的现状,做着无意义的事情。
别想着设计一个强大的服务器,支持百万人并发访问。不知道什么能到那个点,花时间做那个纯粹是浪费。先保证好百来个用户能稳定使用,就不错了。产品都是九死一生,看不到的事情,就别意淫。真是到那个阶段,不管你前期设计得如何,都被重写。因为——

盖尔定律:一个切实可行的复杂系统势必是从一个切实可行的简单系统发展而来的。从头开始设计的复杂系统根本不切实可行,无法修修补补让它切实可行。你必须由一个切实可行的简单系统重新开始。

说白点,就是写了也用不上。毕竟,这事我经历过。

互搏与审视

自己提出一个观点或方案,然后找到其漏洞,再反驳掉前面的。如此往复,最后的方案肯定是漏洞最少的。我把这个过程叫互搏。
产品设计中,我经常使用这个方法。假设一个方案,发现其中的漏洞,然后修正,再去查找漏洞。训练过程很痛苦。坚持一段时间,对比以前,会明显看到思维缜密性的提升。
除了产品设计,我会将其应用到产品其它工作中。训练次数足够多,你就能从中间总结要点,提供共性要点,列个清单。不必每次一轮轮反驳,对着清单,逐条检验,看自己是不是做到了,这也是审视的过程。

能力与认可

对产品经理来说,谈到沟通能力时,更多指的是如何说服别人做某一件事。
产品经理的基本要求是,产品设计思路清晰,有理有据,以理服人。做到这一点,已经超越了大部分同行。然而实际的工作上,每一个人的思维方式不一样。很多时候以理服人显得无力,你并不能得到别人的认可。
「你说的我都知道,我现在就是要xxxxx」。不管方法论讲得再好,说得再有理,没有做出过成绩,难以让人心服。产品经理的工作本来就很难量化,想要得到别人认可,尤其是想被市场认可,最好的方法是拿出成绩说话。
成功的产品就那么多,大部分产品没有多少人听过,这也意味着多数产品经理在职业路上很难向上突破。所以,当你要说服别人时,除了讲道理之外,还要想一想,怎么拿出成果让别人信服。不然,哪来的底气说老板需求不靠谱。论工作安排,老板的一句话,就比你的方法论管用得多了。

抽象与具象

产品经理大部分时间都花在了具体工作上,关注细节。长时间埋头工作,容易进入状态,关注局部,忘了抬头看路。说好的,要有抽象思维,跳出细节,全面看待事个产品。一画原型,早就忘了。
要了解某一领域知识时,总是习惯于自顶而下去做分析和了解。明明知道最好的方式是选取一个小角度来切入,但就是想短时间内得到大而全的报告。结果,逃不了空洞和泛化。
总是说工作上,产品经理要使用抽象和具象思维。难的不是掌握和使用,而是意识到什么时候要用。

产品与标签

产品经理对我而言,不像是一个岗位名称,太模糊,更像一个工作标签。而对这个标签,我从来没有意地界定它的范围。只要是与产品相关的工作,我都会去了解,思考它们对于产品的价值在哪里?不同工作之间的关系又是怎么样的?
作为产品经理,我的核心价值在哪里?我发挥了什么作用,对产品贡献在哪里?没有这个岗位或者没有了我,会对产品造成影响吗?5 年后,市场上还有这个岗位吗,工作内容和工作性质会有什么样的变化呢?
只要我能在市场中找到自己的定位,发挥着不可或缺的作用。不管互联网如何发展,我就会有自己的位置。
春播秋收,稻谷满仓。愿产品人都能结出自己的果实,与君共勉。
 
作者:王磊(lei),微信公众号:野兽说(ID:monster_talks),丰巢产品经理,7年互联网产品策划和研发经验。主导过智能硬件,物流行业的启动项目。

关键字:产品经理, 产品思考, 产品, 经理

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部