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

释放双眼，带上耳机，听听看~！

00:00

00:00

本文是笔者参加了“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：关于产品设计的思考在以往以及未来的产品文章中都会有体现，欢迎大家关注我不定期更新的产品相关文章~

#专栏作家#

兮兮，微信公众号：孤身旅人（ID：gushenlvren），人人都是产品经理专栏作家。关注人工智能、toB产品、大文娱等领域。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议