即刻App年轻人的同好社区
下载
App内打开
火山会爆发的
7关注25被关注0夸夸
主业4年产品经验
副业探索可能性中
增加输入,尝试输出
会爆发的
火山会爆发的
6月前
人生建议:不要过度准备,减低预期。
我们总在给自己不行动找的借口,我们总是一边跟自己说在准备了,又在害怕准备了这么多最后失败了该怎么办?然后就一直停止在当下,犹豫不前。 今天偶然间听到一句话,大意是“过度准备是用心良苦的败笔。它使你一生都无法做成想做的事。”我们以往受到的教育都在告诉我们,要做好准备,有备无患,但是实际上,未来的路是什么样的,沿途是鲜花还是风雪,没有人知道。 然而,过度准备,设有太高预期的人,往往会失败或者压根就没有开始,因为他们太害怕不确定性,预设出各种前路上的困难,然后希望在正式开始做事前排除这些障碍,为自己铺下通坦大陆。然而实际上,一直停留在过度准备上,一下就给自己很高预期,只会阻碍行动,导致这件事情一直不能开始。
总有一天,我们都会意识到我们的路是一直在向前的,不管是一直在准备,还是已经迈出第一步,抑或已经阶段性失败或间歇性成功,这只是这条路上的一个山峰或谷底,路还是会继续下去。

当我算是看清这点后,我也开启了我的账号(没错,我已经过度准备了半年),分享些我的想法: 1、别预设太多的困难 “腿”在我们自己身上,要不要迈出去做决定的人永远是我们自己,可以预设一些困难,准备好相应的解决方案,但是,更多未知的障碍没人能知道,带着60%的准备出发,带着100%的精力去克服沿路的障碍就好,一直不去行动,我们只会在内耗的漩涡中挣扎。幻想里都是问题,动起来才知道什么是答案。

2、降低预期这跟我的实际工作很像,以往定工作目标的时候,总是幻想我的业务能做的十分“强壮”,然而期望越高,失望越大,有很多客观因素是我们不能把控的,我们最好结合过往的经验,定一个合理的目标,有几个方法吧:(1)有能参考的历史经验,就比它多一点点;(2)阶梯型目标方法,我们可以给自己设立一个远大的目标,比如10w粉丝,但是我会在1k粉、2k粉、5k粉的时候,给自己一定奖励,并且适当停下来看看自己的原先定的目标是不是合理;(3)不要一下挑战一个完全未知的领域,走岔路也要在自己的主干道附近扩展,不然很快会觉得力不从心;
3、坚持
好的习惯是需要培养的,不要迈出去没多远就又开始原地踏步,借口会有很多,比如今天加班太累了,今天想不到话题,但是那都不重要,不是每一步都能看到花开,但是你要坚持往前走呀!
火山终有一天会爆发的,在爆发之前,我们看不到的下面,它在蓄力,在积累。学会用成长的思维看问题,不确定的是未来,遇到的问题是现在,解决的方法才是你的经验。停止对这条路的好奇,坚定地迈出每一步吧。
#记录美好生活 #记录生活 #日常分享 #随手拍 #日常
00
火山会爆发的
6月前
做为产品的思考:
任何一个产品存在的意义都是去满足用户在某个场景下的某个(某些)需求。
然而反过来想一想,在当下这个时间节点,找到一个还没有被挖掘被满足的需求,然后去实现去完善它的情况已经少之又少,满足同一个需求的产品,市场上多如牛毛,那为什么产品之前总有好坏?用户喜欢A而不是B?抛开资本的力量不谈,我觉得核心还是对标同类竞品,胜出的产品总是能【“更好”得满足用户的需求】
这段时间做小红书的辅导账号,给了我一些想法,我从输出我自己的对产品、对运营的思考慢慢开始转变,开始去考虑真正在小红书里搜索面试的同学们她(他)们真正关心的是什么。我不再去讲所谓的方法论,而是尝试用更简单更易懂的文字,让这些没经验的同学通过我的文章能直接看懂,并且能够快速的运用。而给到我的反馈也就是这类的文章可能往往更能获得这些读者的青睐。
同理,做别的类型的账号,做各类视频,甚至在公司职场里,都是一样,我们要想明白我们到底在跟什么样的人对话,ta们真正需要我们输出什么样的内容,做出什么样的产出,才能满足各类人对我们的需求(诉求),既然是想做个输出者,尝试告诉自己,停止或者减少停留在“我”想要做什么,“我”想说什么的阶段;多想想“别人”需要的是什么,怎么去满足,可能这样,我们才能做得更顺畅。
00
火山会爆发的
7月前
重启人生需要克服的第一个困难,戒断反应
想着每天要去输出,那就要增加输入,昨天晚上尝试在睡觉前半个小时前开始读书,丰富下自己的精神世界,然后就体验到了什么叫万事开头难
第一个问题是选书:
虽然之前也有看书的习惯,但是大多有目的性,比如最近业务的重心在增长,我就会找相应增长的书籍,比如发现自己基础知识薄弱,就会找些基础方法论书籍,没有目标时,因为自己是做商业化方向,所以也会找些商业+互联网的书籍;
然而当我只带着我要看书的想法尝试看书时,我失去了目标性,得到的书架里存了很多书,但是每本看了两眼之后,心里有个声音告诉我“看这个对你现在没什么帮助”,随之就失去了继续读下去的兴趣,想着再换一本,再换一本...最后是因为发现这么反复过了10分钟也没有开始读书,才强迫自己选一本书开始阅读;
第二个问题是最痛苦的戒断反应
阅读不了几分钟,就感觉文字变得模糊,大脑开始各种乱想:群里发了什么好玩的消息了,今天的需求逻辑好像有哪里没完善,关注的几个博主发了什么内容没有...往常每天睡前的刷视频,刷群聊的习惯让我产生了惰性,大脑暂停思考

习惯是需要培养的,最痛苦的都是起步阶段,你需要摒弃过往的一种模式,重新培养新的模式。给大家个建议,阅读些经典故事书籍,有剧情的那种,经典的书籍的文笔和思想深度足够我们去吸收,同时通过剧情的吸引,让大脑停止发散性的思考,沉浸在跟随故事脉络发展的节奏中;
00
火山会爆发的
7月前
早在6月中旬,认识了一位大佬—创建行动有术的豪哥,想请教所谓的自媒体能力,得到了很简单的一句话“我也是写了800多篇了,才能有今天的手感”。
而我自己,在知乎、小红书、即刻各种平台都尝试过去发布帖子,然后发完就开始数据焦虑,总觉得自己能有同理心,写篇文章就能获得数据上的“肯定”,也就是所谓的功利心在作祟吧。随着发了几篇文章石沉大海之后,就失去了继续写的热情,随即不了了之。
同时,应该是产品经理的工作方式影响,总是觉得所有事情都是有技巧,有方法可循的,只要掌握了运转方式,跟着教学步骤的引导去执行就会有收获。但是最近在小红书的实践告诉我,当我们探索一个新的领域,没有所谓的按部就班时,我很容易就陷入迷失的状态,就好像应试教育下的我们不知道公式就无法动手解题,然后就希望有人能带一带,有人能教一教,不然就不敢/不愿意再去尝试,害怕犯错。

十一去法国旅游的时候,导游跟我们分享了她妹妹的成长趣事,“她跟中国教育的孩子不一样,总是天马行空,5月告诉我要做一个滑板运动员,6月告诉我滑板不适合她,改主意想做医生,学习医生知识一段时间后,发现自己没有那么细心,但是对各种解剖图有了兴趣,8月告诉我说她想学绘画...”同行有一个家长跟自己的孩子说,别学她,要坚持。但是我却很羡慕,很佩服。羡慕的是这个女生还小,有那么多的可能性。佩服的是她有了想法就会去尝试,而不是停留在嘴上说说而已。

想一想自己,其实我的人生也还没走多久,我也还是可以有很多可能性的,不要只停留在想的阶段了,放手去做吧。然后就这样又搁置了4天,没有任何动静,直到今天,看到一位关注的博主分享的一段话
“前天有一个很早关注我的朋友问我怎样写作,要不要报班什么的。我说你把每天的所思所想所见记录下来,保证输出两千字,坚持一年你就可以开班授课了。”
周围有很多人对自媒体充满兴致,不停的刷,也会说“就这?我都能写的比ta好”,然后我看到了我的前同事靠自己的公众号接到了第一笔广告,看到了豪哥拥有了自己的社群,建立了自己的流量池,而我还是停留在想一想的阶段;
行动吧,路是靠自己走出来的,道路上的野草是要自己动手拔掉的,空想的进度条不会有任何的增长。
00
火山会爆发的
2年前
#我的工作感悟
为了不影响大家的阅读体验,第二个感悟还是分开写吧(虽然没有几个人能看到,但是我还是愿意分享)
2.明确角色,知道你自己的位置,想清楚到底要干什么
A表拿过来之后,领导又开始安排了:你看看这个表里面都有哪些字段,现在是怎么取数的,你觉得合理不合理,你觉得应该是什么样的,然后等你确认的没问题了,拿着新表去跟研发要数据,再跟A表比对一下,哪里有出入
我做了以下事情:
对着A表表头的名字,翻找宇各个系统和印象之间,并写下注释:xx字段取数逻辑为…,数据来源于X系统-某个页面-某个字段
把写完了80来个字段的备注发给业务方,让他确认我写的是不是对的
业务方一开始还是挺好心的,逐个按照我写的注视确认了一下
然后跟领导汇报,领导看着我很业务方第一次确认的注释,指着某些字段说:真的吗?真的是这么取数的吗?我觉得不一定吧,你去再跟业务方确认一下吧
随后,我又把每个字段仔细过了一遍,腆着脸又去找业务方,业务方回了句,你去找研发吧,他那里有存每个数据的取数逻辑,因为需求是逐步提的,我也不确认所有详细的了,没错开始踢皮球了,我又去找对应的研发,研发说:注释都在代码里,我翻译过来之后,你可能都听不懂,你不如去找业务方
我是一个极度厌恶踢皮球的人,可能是性格原因,自此之后,我再也没有找过任意一方,而是按照我认为的取数逻辑去写注释
待注释写完后,我明确跟领导表达我的每个想法,领导过完之后说:你说的想法很理想,我也不确认按你的想法做出来的数据就是能算对的,你来但是我们既然选择A表以及A表的业务方作为初始表,那么我们应该要保证第一版出来的数据能尽可能的跟A表匹配上
为什么当初不直接告诉我打算用A表并在A表上做扩展呢?
接下来是领导直接出面,拉着让业务方和研发给出具体注释
这件事给我的思考挺深的,我自认为的面子、脾气…在工作里什么都不是,效率和结果才是最重要的
想明白你在一件工作里到底是什么角色:
我要是业务方,实际在用表的人,那我就索性在第一次问清楚对方到底想要什么,能提供清楚的就提供清楚,提供不清楚的就让发起者把研发(因为是研发写的代码,他是最清楚的)拉过来一起确认
我是项目发起方,我的目标是为了整体的数据更合理,我是个串联者:那既然已经明确了用A表作为底表选择了背靠这个业务方,那我就应该拉上业务方和研发三方坐在一起,说清楚我要什么,让业务方表达好后续诉求,我来先评估并讨论诉求的合理性,合理的我整理成需求,继续推动
我是研发:我只需要坐在那里,甚至都不用坐在那里,只需要把已经发给过我的这个项目的需求都找出来,发给其他两方,心地善良点的,在业务方不清楚先行逻辑的时候查一下代码,说明一下就可以了
以上是我的“教训”?我的愿景?我认为的工作流程。还是那句话,在工作上,效率和产出结果是目标,没有人会关心你为一件事情费多大力,被当成皮球被踢来踢去多少回
以上,是我这个项目到目前的感悟,后面可能还会有更多的坑我不知道,但是吃一堑长一智,也许看到的人早已经历过,也许将要经历,我只希望做一个分享者,让能看到的人不要再像我一样走这些弯路
11
火山会爆发的
2年前
#我的工作感悟
这段时间在接手个项目,简单来说就是把现有所有业务方的报表汇总,收集,然后全部推翻,做一个“以我为准”的唯一报表
目前经历了两个坑,在这里跟大家分享
1.充分用你能用到的所有资源,这不是“作弊”而是提效。
规划阶段:
领导说:你要了解系统流程,然后告诉我你想怎么设计这个报表~
Ps:虽然沟通过程中曾多次提到某个业务方的名字,但是依旧在跟我说,告诉我,你想怎么做这个报表!
这个时候,我陷在一个莫名其妙的状态里,我要重新梳理业务流程,确认关键路径,想关键节点,然后跟领导汇报,我打算如何如何做,领导只是说了句,你再想想,我以为这句话的意思是用委婉的语气表达你做的是个锤子。然后又开始了重新梳理整理以及出表,没想到在第二次出表的时候。领导直接发给了我一张表(对,就是前文提到的业务方的一张底表,后续我们就简称A表吧),并说道,你看看这个表有什么,在这个基础上改改吧
中间还有个插曲,在领导第一次“评价”之后,我已经要到了业务方具体负责报表人的微信,我只差点一下申请那个按钮,但是已经记不清是什么原因了,我愣是没加
这个阶段我跟好几个朋友聊这个事情,获得了不一样的评价
有的说:这就是你领导其实也不知道该做成什么样呢,不然早就给你具体方向了
有的说:这是领导在考验你,知道这个项目其实没那么紧,正好借此机会让你熟悉现有逻辑
有的说:你为什么不直接管业务方要现成的呢?
对啊,我为什么不管业务方要现成的呢?因为我现在了领导说的那个“你认为”三个字里了?还是有什么其他原因?我已经记不起来了,但是教训,也是我想分享的就是:
现有的东西一定有他存在的价值,作为一个项目的新人,从0-1的想法是对的,但是还是要用尽身边能用到的一切资源,去要一个现状,这不是作弊,也没有偷懒,是提高效率的最优解
00
火山会爆发的
2年前
#每天一个产品知识
全局最优算法 VS 局部最优算法

今天同事又又又迟到了,11点半坐下之后怒喊,破滴滴,眼看着地图上有空车,就是不让我打上!咱也不知道他是编的借口还是啥,反正滴滴打不到车的情况确实客观存在

以打车这个事情为例:
局部最优算法就是:你站在这里,滴滴就是为你开的,只要你点一下按钮,最近的车马上开到您的面前
全局最优算法就是:让一定的范围内的所有用户打车等候时间加起来最短
让两个用户都等5min,总等候时长10min,而不是让一个用户等1min另一个等10min

为啥要有全局最优算法?因为“不患寡而患不均”呀!
反正人家滴滴官方给回话了,利用全局最优算法,他们平均每天可以为司机和乘客节省时间30万小时(用户量确实也大),就这样我们每个人又一次被平均了~

这个算法还有啥应用呢?VIP!对就是滴滴里面那个至高无上的黑卡,只要你在滴滴花的钱足够多,系统就会在你这个账号上增加局部最优算法的权重,这样,滴滴又是为你开的了!

这算法还能用到另外一个目前最普遍的场景就是外卖了,咱也不多说了,理儿就是这么个理儿

Ps.之前总觉得自己的知识储备不够,不好意思张嘴,后来想想,咱脸皮还是够厚的,以后每天至少发一篇,碰到啥发啥,反正我也不是专业的,浅尝辄止即可,如有不对,而且你也愿意的话,及时指正好不好🥺
00
火山会爆发的
2年前
#我的工作感悟
今天被leader叫去小聊了一下,可能是我前几家公司的leader不太有作为leader的培养型认识,所以今天才真切的有了一些对于产品经理职业路径(职业规划?)的感悟,写在这里,跟大家分享

初级产品经理的要做好:听懂+执行+技能锻炼
初级产品经理日常最多的需求是来源于上级(mentor、leader、什么什么er的各种高级词汇),你要做的是先听懂了他们需要你做什么,最好的是在对方说完,你理解后,当即重复已做确认,以免做无用功。
同时,在反复的执行中,锻炼实操技能,学会需求评审,如何把自己想做的事需求给研发、测试、数据同学讲清楚,并学会推进项目上线

中级产品经理要做好:对于数据的理解
这个其实是我今天所学到最有用的内容,确实,我觉得我只是个中级产品经理,而且做的还不够好
中级产品经理的底线是,上级说他想要什么之后,你能自己把他拆成需求,一个个完成并跟进上线
而中级向高级的进阶之路,就在于对数据的理解
初级产品经理做到看到数据效果是正是负就是达标了,如果你能知道AB实验的用法、能把一个数据结果以数据链路的形式一步步拆清楚,说明你在从初级向中级进发,一个简单的方法:一直问是什么?
例如:转化率是3%
转化率是什么?转化率=当前实际下单人数/当前页面访问人数
当前页面访问人数是什么?当前页面访问人数=Σ活动曝光uv*各个曝光处点击率
以此从结果一步步反推至源头,再逐个解决...

而中级要学会看懂数据背后代表的意义,一个简单的方法,在是什么的基础上再问为什么
为什么当前实际下单人数少?文案不好吗?价格过高吗?用户点了没反应吗?
为什么当前访问页面人数少?活动总曝光量不够吗?
为什么活动1曝光会多于活动2?
接下来还需要看懂数据结果的“背面”
我这个活动只是在推这个sku,为什么推的不是别的sku呢?如果推了别的数据会不会更好呢?
中级产品经理可以通过高效完成初级产品部分的工作而给自己流出一定的时间,这个时候,你要开始多思考,少划水,把你思考出来的问题一个个解决,如果有资源的话,可以再去一个个印证,印证自己的想法带来的收益是比别人给你需求让你完成多很多的

至于高级产品经理,听说是:商业理解+战略
是不是这俩词就很互联网黑话,因为我还没达到这个高度,只是听说,我拆不出来,我只能把我听到的这个词摆上去,因为你们的理解都不同,我也没理解清楚,随便乱说甚至可能误导别人
当然,如果有幸有高级产品经理看到了,希望给我指点指点,少走弯路,大恩不言谢~
01
火山会爆发的
2年前
#我的工作感悟
因为阴差阳错的从C端转到了B端,最近又翻了各种什么B、C端的产品工作介绍,那我也胡乱扯一点~

1.买单的人和使用者是否对立
C端产品的买单人和使用者:他们可能就是同一个人(视频VIP会员),也可能不是同一个人(学习类产品,家长买单,孩子使用),说到底不是对立的,要关注的是体验(功能使用是不是流畅、提供的内容能不能满意)
B端产品的买单人和使用者:大多是对立的(飞书、钉钉...老板员工使用),要关注的是能不能快速、有效、准确的解决一个个流程性问题,产品体验的提升可能对于某一项功能的使用数据有增长,但还是要把更多的精力放在逻辑梳理上,而非小功能的体验优化上

2. 使用角色整体性
C端产品的用户是个体,决策感性,每个人都会为自己的体验发声,那么当发声的信息量爆炸的时候,要学会“合并高优的同类项”
B端产品的用户是团体,决策相对理性,倾向于判断投入和产出,效能优先,当团体统一发声效能问题时,作为产品经理就要注意是不是系统问题了

3. 需求和迭代
C端产品需求较为灵活,MVP(最小可行性)版本多为C端产品,小步快跑,线上验证,快速迭代是产品“发展”的较为合理路径
B端产品往往需求明确,对系统稳定性有较高的要求,你不能把一个B端产品的MVP版本卖个客户说你们先用着,哪里有问题,我们看数据解决

4. 产品价值
C端产品:用户价值,解决生活中一个“问题”就好,找得到音乐能下载;找到的视频,线上能看;能写下自己的想法,发布出去,供别人阅读,讨论;体验做好就可以有生存空间。
B端产品:付费决策者是会“计较”投入产出比的,也就是性价比,所以B端产品一需要针对某个企业或者行业共性,提供完整的解决方案,才能找到生存空间。

5.增长、传播速度
C端产品增长速度快,种子用户-裂变-病毒传播,当用户生活中有各种各样的需求,当你的产品能够解决他们其中一个需求时,产品就可以实现一定规模的快速增长。
B端产品增长速度慢,简单一句话,B端产品解决的是限定场景下完整的工作流程,所以需要先了解,再抽象,再输出可行方案,但是一旦涉及到增长,服务多家同类型客户时,你就得再一次抽象共性问题提供解决方案后,在针对各家的个性问题,提供方案。这只是你的产品迭代,你产品做好了,试问又有几家公司会自主进行新系统尝试?再说人家真的愿意尝试,你能免费提供服务吗~

6.成本
C端产品的边际成本很低(你可以理解为在内容成本一定的前提条件下,我服务10万个人~50万个人可能都不要再多付一台服务器的钱)也就是经济学家们说的边际成本可以趋近为0,所以C端产品才会在产品初期疯狂补贴,为的是用户规模,当用户全都跑到他那里之后,他有广阔的利润空间,他有各种法子变现,而付不起补贴的玩家们,只能活生生的看着自己被耗死,用户都没了,产品放在那里干嘛呢?
B端产品:因为他是个系统,前期开发成本就高,所以产品客单价高,所以他门槛高,门槛高带来的是需要有人给客户解释我们的产品好在哪,人是谁?人是自己团队的销售,外界渠道(地头蛇们),所以呢成本水涨船高

7.变现方式
C端产品的商业模式玩法更多样,即友们鱼龙混杂,不是,百花齐放,所以大家随便就能说上来不下10中变现方式
B端产品往往商业模式明确,卖服务

8.利润
利润=收入-成本
收入=Σ用户付费
所以可以理解为:C端产品单个用户收入很少,微乎其微,那么单个用户的利润也就微乎其微,但是量变引起质变,当我的碗足够大,碗里盛满了米的时候,我这锅饭就一辈子吃不完
而B端产品,我没卖出去一单,我都需要靠这一单养活公司上下老小,这一单卖出去了,下一单还不知道在哪呢,所以在没有外部输血的情况下,老板会考提高单价来覆盖成本,保证单个“用户”的利润够高

写的有些零散,大家看个乐,欢迎多来批斗我~
01
火山会爆发的
2年前
#我的工作感悟
阴差阳错的从C端转到了B端有一段时间了,最近对思维导图、流程图、原型图有了一点想法,大家指教指教

思维导图:用于表达整体架构,清晰的展示有哪些需求,本期做哪些需求、未来做哪些需求、未来再规划哪些需求。凭借思维导图作为方案评审的第一步,你可以很快地传递需求的价值,可以直观的表达整体业务框架,告诉别人我的需求是有规划的,不是拍脑袋想出来的

流程图:这几天的工作让我觉得流程图太重要了
流程图是系统功能或营销活动的最直观的逻辑表达,它可以清晰地表达系统的各个模块要做的是什么,怎么接受上一级的数据,再如何传递给下一级
所以无论C端还是B端,能理清整体流程,能告诉别人每一步的作用,才是你个人逻辑的对外输出
它作为整体业务的逻辑展示,因为一开始很可能只有你自己了解业务以及整个逻辑,一上来就对着原型讲,只会把你自己拖入被动,光看原型别人很难对整体流程有一个概况。所以需要有一个对整体逻辑的阐述。

至于原型图,并不是不重要,它是所有产品经理的基础!但是随着工作时间的增长你会发现你的原型越来越简单
不能多,不要少,不要形式化,简单阐述功能逻辑;细节处先发制人,但不要纠结于细节,始终记住原型是给人看的,人是永远不会被满足的。
00