微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

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

“Google工作坊”后,对B端产品日常工作的思考

来源:网络 300621

本文是笔者参加了“Google女性开发者大会”之后,对B端产品的日常工作的思考。文章讲述的内容包括:笔者对于B端产品需求搜集、B端产品需求提炼、B端产品工作心态等的思考。

 

介绍一下Google工作坊

 

作为一个汉子,上上周(4月21日)有幸参与了“Google女性开发者大会”,参与活动当然是学习知识啦(那位童鞋憋说话,顺便看看小姐姐不行嘛→_→)。

除了多位女性在台上的分享让我记忆犹新外,在“Designlab”工作坊(Google女性开发者大会分会场,关于B端产品设计的沙盘模拟)的活动也让我收获颇多。

沙盘模拟的课题是“审批流程的重新设计”,当Yvonne老师询问与会者是否用过“钉钉”(办公类型的即时通讯APP,支持线上审批的功能)时,大家都齐刷刷的举起了手,并对接下来的课题信誓旦旦起来。

可是,那些看似了解的东西我们并不了解,那些认定的解决方案不过是给竞品换了一个马甲罢了

这不,作为小组长的我就给起了个错误的头,以至于在工作坊的沙盘模拟中,我所在的小组表现的并不突出。活动结束后,我在地铁的车厢上复盘着活动中我们小组出现问题的同时,也思考起自己日常的工作。好久没有写产品相关的文章了,今天就借此机会写下本文,欢迎各位看客老爷随意拍砖~

 

关于B端产品需求搜集的思考

 

不YY用户场景,不是满足自己的需求

工作坊中,我们小组大部分小伙伴使用过钉钉,日常工作中也有过人事申请的经历(如:请假),活动一开始我们就迅速在白板上整理我们的亲和图(以下来自百度百科:把大量收集到的事实、意见或构思等语言资料,按其相互亲和性(相近性)归纳整理这些资料,使问题明确起来,求得统一认识和协调工作,以利于问题解决的一种方法)。

当我们小组粘贴活动亲和图上的便笺时,大家都发现了写在便笺上的都是员工(申请人)相关的内容,缺少主管(审批人)相关的内容。

于是,我们开始拍脑袋想象审批人会遇到的情境:“审批消息这么多,好烦呀”……

就当我们欣慰于在时间截止前完成第一阶段任务时,大家从未思考过:审批人为什么这么烦呢?在哪些场景同时并存时会让审批人不开心呢?

从毕业到现在,我一直做B端的产品,Yvonne老师总结的好:“C端产品是自驱动,B端产品是商业驱动”,通俗地说B端产品就是能不能为企业高效地解决问题,并提高收益(C端的我还没想好怎么概括)。与企业级、后台业务打交道,很大一部分时间是在梳理业务流程,以及各个角色的权限与模块功能,对底层逻辑和架构也有一定的涉及。

你读完上述文章是不是觉得我平时的工作有点和开发小哥类似呢?

没错,渐渐地我也有了工程师的思维。工程师思维当然有益,让一个人严谨、富有逻辑,追求流程、结果(如果你觉得我对工程师思维理解片面,欢迎在底部给我留言)。但在B端产品工作中,极容易被工程师思维带偏,而忽视了用户思维,所以做出的产品,逻辑上讲得通,但用起来就会有种蹲在豪华厕所里拉不出屎的感觉

举个简单的小例子:我在做大数据可视化产品中,关于仪表板的存储,在老版本文字描述为“权限归属”,一些新用户初次用的时候会问我这个是什么意思。

后来,我就在新版本把文字描述改为“存储”,给很多新用户演示后,他们都一致表明可以理解了。B端产品不像C端产品有很多第三方统计平台,且不少产品都是私有化的,保持用户思维就需要对一手的需求提出方访谈、观察。

虽然数据可视化产品的用户是分析师、业务方(其他事业部的产品、运营),但是需求提出方却更多的是分析师。刚开始我还YY着分析师提出需求背后的场景去设计,慢慢的,新功能上线后还是会出现很多问题。

突破困境,做一些“不该”自己做的事

读完上一节的文字,你也许会疑惑为什么需求是分析师提的,而不是业务方呢?

哈哈,恭喜你!你也开始思考情境了。

接下来要说一下B端产品的另一个特点:想用即来,用完即走。通俗一点说,就是我遇到问题才找你,你把我问题解决了我就和你拜拜了。所以,业务方在使用数据可视化产品时,他们关注的其实是身上背的KPI,更多地会想“只要不影响我看数据,需求给不给你提,要看心情”,这就是业务方不会跟我这个产品经理过多沟通的原因。

一方面,业务方的仪表盘需求是分析师去操作完成的;另一方面,仪表盘关系着业务方的KPI(业务方依靠仪表盘观看功能、活动上线后效果,查看用户数据等)。

很“功利”地说:在数据可视化产品上,业务方和分析师的亲密关系,远大于业务方和我这个产品经理的。如果没有明文规定业务方的需求必须经过产品经理,那只能突破这个困境了。创建用户群、只要有机会接触到业务方就不停追问(比如:申请账号、系统挂了,此时业务方才会和我交流)……

这些看似耗时且与本职工作无关的事情,恰恰可以拉近和一些业务方的距离。

当然,这些改善还远远不够,就像Grace跟我说的:你需要成为一个分析师!这或许就是为什么数据产品经理的招聘JD上会说明“需要掌握SQL查询语句”的原因吧。

这条路我还在前行中,过程中还得面对重重困难,我相信未来会给大家带来好消息(失败的经验也未尝不可,哈哈~)!

最后,再啰嗦一句为什么业务方的需求(含数据需求)对数据可视化产品来说至关重要呢?因为数据可视化产品要做到智能化,就需要自动推荐图表样式,Tableau(国际知名数据可视化产品)这点做得就很赞。

 

关于B端产品需求提炼的思考

 

提炼需求,方案后定

这个问题出现在本次工作坊另一个小组身上,或许他们对钉钉审批都很了解,就直接把审批流程设计好了:员工端、主管端、人事申请、人事审批……

接着他们就直接把便笺贴在了对应的区域内,因为先限定了流程、方案,编写的“用户情境”就成了使方案成立的“证据”。

没错,Yvonne老师当场就指出了这个小组的问题:需求、方案是在调研大量数据后逐渐清晰的,预先设定边界会让我们忽略潜在的其他细节。

为了让需求搜集建立在充分、客观的基础上,Yvonne老师提到了一个工具:录音笔。在提炼需求时,可以有效地查缺补漏,也可以验证是否加入了自己的主观色彩。

成为用户

这是和C端产品要求相同的一点。纵观自己近三年的产品工作,不管是之前做仓储机器人产品,需要到仓库中驻场拣货;还是现在做数据可视化产品,需要成为业务方和分析师(这次工作我有些后知后觉,前期都泡在学习后台逻辑了)。一切都是为了成为用户,让产品真正地解决用户的问题。

但是,B端产品面临的问题也发生在这里,B端产品不像C端产品有意思,更多都是结合业务,甚至还会涉及到技术。

提问个极端的问题:玩游戏和打代码你会选择哪个呢?

这个答案大家可以在下方给我留言(hi,这位程序员哥哥你先放下手,知道你要选择打代码,O(∩_∩)O~)。

在最初做数据可视化产品时,我曾想过转岗,甚至离职。因为这不是我擅长的业务(要涉及技术),也不是我做过的产品。面对不可掌控的局面,我开始退缩起来,听起来这像极了“巨婴”(特点之一,全能自恋,一旦掌控不了局面就会崩溃)。

最后,我用了2个月的时间调整自己心态,最终朝着良性的道路发生了很大的变化(这段经历,我会在以后分享给大家)。从零慢慢学习,成为用户,现在我依旧在路上……

 

关于B端产品项目管理的思考

 

需求定义

在工作坊中,我们组在提炼需求时,遇到了另一个问题,甚至出现了分歧。因为大家在展开用户场景的同时,范围也慢慢扩大。

有人说“做病假审批,并结合财务计算规则设计”,可是财务计算规则是什么样的,组内的小伙伴又无人知晓了,且“员工-主管-财务”的审批本来也是个复杂的模型。

当这一环节的时间将至时,Yvonne老师提示我们:时间有限,需求越简单越好。

最后,作为小组长的我终于拍板——做“病假申请”。

我又想起2016年老高跟我说的“第一范式”,他说做需求和建数据表一样,要拆分到最小的颗粒度。当然工作中的时间还是比活动中的时间要充足的,我并不认为“病假申请”就是人事申请中优先级、ROI最高的需求。所以在真实的产品设计中决定做哪个需求时,就要考虑需求频率、商业价值、开发成本、可拓展性、高层授权……

这一环节我还在继续学习阶段,后续再详细分享。

Deadline(截止时间)意识

最后一个问题就是时间,这次工作坊中虽然每个组都有个人专门计时,但有一个环节我们组的这个专人也忘记计时了,这听起来有些糟糕的。

在我工作中也遇到过,特别是做一些对内、不打算做商业化的产品时,可能公司项目管理团队也不会关心这个项目了。加上B端产品面向企业级用户,快速迭代式的敏捷开发,在某些B端产品项目中就行不通了。

因为一些B端产品每次升级会消耗很大的资源,所以一次版本迭代就会堆上很多功能,项目周期也就拉长了。战线一拉长,人的疲劳值也会升高,各方面就不敏感,开发也会懈怠下来(偷懒),这样就会进入一个恶性循环“周期长-偷懒-周期长”。

这时候“人人都是产品经理”就要改成“人人都是项目经理”,每个人都对截止时间有敏感的意识,才能够按期交付产品。

当然,这毕竟是个理想模型。每周的周会汇报,每天定时催问开发进度……这些就必须在B端产品项目中执行起来。所以貌似开发小哥对B端产品的抱怨超过了C端产品,毕竟少了一个项目经理来吐槽→_→

 

关于B端产品工作心态的思考

 

这个问题我在之前的文章中也略有讨论过,特别是一些既有C端业务又有B端业务的公司里,那B端产品产品可能就会脱离产品大部队,孤独地面对各种问题。好在,身边有一群可爱的开发哥哥,共同面对用户的问题,一起讨论需求(好开森~)。

我经常和身边的朋友这样调侃“C端产品经理和B端产品经理”的区别:做C端产品像演偶像剧,做B端产品像演话剧,话剧的关注人数当然没有偶像剧多,但我们都需要好好演戏,认真对待剧本,认真对待观众……

这一点也和Yvonne老师在工作坊中说的不谋而合,B端产品和C端产品都需要用户与产品调研、定位核心问题、产品规划和开发、推广上线与运维……

最后,按照惯例我得发鸡汤了,送给B端、后台业务从业者(包括我自己,嘻嘻~)一段陈道明在《传承者》节目中的讲话:

我在天津人艺,我有七年的时间,在台上一句台词没有。这一场演匪军,下一场演伪军,再下场演特务,再下一场演八路。我在想,就是人在各种职业当中,要有一种甘于寂寞的精神准备……你们要努力,但是不要着急,凡事都应该有过程……

PS:关于产品设计的思考在以往以及未来的产品文章中都会有体现,欢迎大家关注我不定期更新的产品相关文章~

 

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

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

【转载说明】   若上述素材出现侵权,请及时联系我们删除及进行处理:8088013@qq.com

评论

相关文章推荐

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 = 3733 ) 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号