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

1、 “Google工作坊”后对B端产品日常工作的思考 本文是笔者参加了“Google女性开发者大会”之后，对B端产品的日常工作的思考。文章讲述的内容包括：笔者对于B端产品需求搜集、B端产品需求提炼、B端产品工作心态等的思考。作为一个汉子，上上周（4月21日）有幸参与了“Google女性开发者大会”，参与活动当然是学习知识啦（那位童鞋憋说话，顺便看看小姐姐不行嘛_）。除了多位女性在台上的分享让我记忆犹新外，在“Designlab”工作坊（Google女性开发者大会分会场，关于B端产品设计的沙盘模拟）的活动也让我收获颇多。沙盘模拟的课题是“审批流程的重新设计”，当Yvonne老师询问是否用过“钉钉”

2、（办公类型的即时通讯APP，支持线上审批的功能）时，大家都齐刷刷的举起了手，并对接下来的课题信誓旦旦起来。这不，作为小组长的我就给起了个错误的头，以至于在工作坊的沙盘模拟中，我所在的小组表现的并不突出。活动结束后，我在地铁的车厢上复盘着活动中我们小组出现问题的同时，也思考起自己日常的工作。好久没有写产品相关的文章了，今天就借此机会写下本文，欢迎各位看客老爷随意拍砖工作坊中，我们小组大部分小伙伴使用过钉钉，日常工作中也有过人事申请的经历（如：请假），活动一开始我们就迅速在白板上整理我们的亲和图（以下来自百度百科：把大量收集到的事实、意见或构思等语言资料，按其相互亲和性（相近性）归纳整理这些资料，

3、使问题明确起来，求得统一认识和协调工作，以利于问题解决的一种方法）。当我们小组粘贴活动亲和图上的便笺时，大家都发现了写在便笺上的都是员工（申请人）相关的内容，缺少主管（审批人）相关的内容。就当我们欣慰于在时间截止前完成第一阶段任务时，大家从未思考过：审批人为什么这么烦呢？在哪些场景同时并存时会让审批人不开心呢？从毕业到现在，我一直做B端的产品，Yvonne老师总结的好：“C端产品是自驱动，B端产品是商业驱动”，通俗地说B端产品就是能不能为企业高效地解决问题，并提高收益（C端的我还没想好怎么概括）。与企业级、后台业务打交道，很大一部分时间是在梳理业务流程，以及各个角色的权限与模块功能，对底层逻辑

4、和架构也有一定的涉及。没错，渐渐地我也有了工程师的思维。工程师思维当然有益，让一个人严谨、富有逻辑，追求流程、结果（如果你觉得我对工程师思维理解片面，欢迎在底部给我留言）。但在B端产品工作中，极容易被工程师思维带偏，而忽视了用户思维，所以做出的产品，逻辑上讲得通，但用起来就会有种蹲在豪华厕所里拉不出屎的感觉。举个简单的小例子：我在做大数据可视化产品中，关于仪表板的存储，在老版本文字描述为“权限归属”，一些新用户初次用的时候会问我这个是什么意思。后来，我就在新版本把文字描述改为“存储”，给很多新用户演示后，他们都一致表明可以理解了。B端产品不像C端产品有很多第三方统计平台，且不少产品都是私有化的

5、，保持用户思维就需要对一手的需求提出方、观察。虽然数据可视化产品的用户是分析师、业务方（其他事业部的产品、运营），但是需求提出方却更多的是分析师。刚开始我还YY着分析师提出需求背后的场景去设计，慢慢的，新功能上线后还是会出现很多问题。接下来要说一下B端产品的另一个特点：想用即来，用完即走。通俗一点说，就是我遇到问题才找你，你把我问题解决了我就和你拜拜了。所以，业务方在使用数据可视化产品时，他们关注的其实是身上背的KPI，更多地会想“只要不影响我看数据，需求给不给你提，要看心情”，这就是业务方不会跟我这个产品经理过多沟通的原因。一方面，业务方的仪表盘需求是分析师去操作完成的；另一方面，仪表盘关系

6、着业务方的KPI（业务方依靠仪表盘观看功能、活动上线后效果，查看用户数据等）。很“功利”地说：在数据可视化产品上，业务方和分析师的亲密关系，远大于业务方和我这个产品经理的。如果没有业务方的需求必须经过产品经理，那只能突破这个困境了。创建用户群、只要有机会接触到业务方就不停追问（比如：申请账号、系统挂了，此时业务方才会和我交流）当然，这些改善还远远不够，就像Grace跟我说的：你需要成为一个分析师！这或许就是为什么数据产品经理的招聘JD上会说明“需要掌握SQL查询语句”的原因吧。这条我还在前行中，过程中还得面对重重困难，我相信未来会给大家带来好消息（失败的经验也未尝不可，哈哈）！最后，再啰嗦一句

7、为什么业务方的需求（含数据需求）对数据可视化产品来说至关重要呢？因为数据可视化产品要做到智能化，就需要自动推荐图表样式，Tableau（国际知名数据可视化产品）这点做得就很赞。这个问题出现在本次工作坊另一个小组身上，或许他们对钉钉审批都很了解，就直接把审批流程设计好了：员工端、主管端、人事申请、人事审批接着他们就直接把便笺贴在了对应的区域内，因为先限定了流程、方案，编写的“用户情境”就成了使方案成立的“”。没错，Yvonne老师当场就指出了这个小组的问题：需求、方案是在调研大量数据后逐渐清晰的，预先设定边界会让我们忽略潜在的其他细节。为了让需求搜集建立在充分、客观的基础上，Yvonne老师提到

8、了一个工具：录音笔。在提炼需求时，可以有效地查缺补漏，也可以验证是否加入了自己的主观色彩。这是和C端产品要求相同的一点。纵观自己近三年的产品工作，不管是之前做仓储机器人产品，需要到仓库中驻场拣货；还是现在做数据可视化产品，需要成为业务方和分析师（这次工作我有些后知后觉，前期都泡在学习后台逻辑了）。一切都是为了成为用户，让产品真正地解决用户的问题。但是，B端产品面临的问题也发生在这里，B端产品不像C端产品有意思，更多都是结合业务，甚至还会涉及到技术。这个答案大家可以在下方给我留言（hi，这位程序员哥哥你先放下手，知道你要选择打代码，O(_)O）。在最初做数据可视化产品时，我曾想过转岗，甚至离职。

9、因为这不是我擅长的业务（要涉及技术），也不是我做过的产品。面对不可掌控的局面，我开始起来，听起来这像极了“巨婴”（特点之一，全能自恋，一旦掌控不了局面就会崩溃）。属蛇的属相婚配表最后，我用了2个月的时间调整自己心态，最终朝着良性的道发生了很大的变化（这段经历，我会在以后分享给大家）。从零慢慢学习，成为用户，现在我依旧在上在工作坊中，我们组在提炼需求时，遇到了另一个问题，甚至出现了分歧。因为大家在展开用户场景的同时，范围也慢慢扩大。有人说“做病假审批，并结合财务计算规则设计”，可是财务计算规则是什么样的，组内的小伙伴又无人知晓了，且“员工-主管-财务”的审批本来也是个复杂的模型。我又想起2016

10、年老高跟我说的“第一范式”，他说做需求和建数据表一样，要拆分到最小的颗粒度。当然工作中的时间还是比活动中的时间要充足的，我并不认为“病假申请”就是人事申请中优先级、ROI最高的需求。所以在真实的产品设计中决定做哪个需求时，就要考虑需求频率、商业价值、开发成本、可拓展性、高层授权最后一个问题就是时间，这次工作坊中虽然每个组都有个人专门计时，但有一个环节我们组的这个专人也忘记计时了，这听起来有些糟糕的。在我工作中也遇到过，特别是做一些对内、不打算做商业化的产品时，可能公司项目管理团队也不会关心这个项目了。加上B端产品面向企业级用户，快速迭代式的敏捷开发，在某些B端产品项目中就行不通了。因为一些B端

11、产品每次升级会消耗很大的资源，所以一次版本迭代就会堆上很多功能，项目周期也就拉长了。战线一拉长，人的疲劳值也会升高，各方面就不，开发也会懈怠下来（偷懒），这样就会进入一个恶性循环“周期长-偷懒-周期长”。这时候“人人都是产品经理”就要改成“人人都是项目经理”，每个人都对截止时间有的意识，才能够按期交付产品。当然，这毕竟是个理想模型。每周的周会汇报，每天定时催问开发进度这些就必须在B端产品项目中执行起来。所以貌似开发小哥对B端产品的抱怨超过了C端产品，毕竟少了一个项目经理来吐槽_这个问题我在之前的文章中也略有讨论过，特别是一些既有C端业务又有B端业务的公司里，那B端产品产品可能就会脱离产品大部队

12、，孤独地面对各种问题。好在，身边有一群可爱的开发哥哥，共同面对用户的问题，一起讨论需求（好开森）。我经常和身边的朋友这样调侃“C端产品经理和B端产品经理”的区别：做C端产品像演偶像剧，做B端产品像演话剧，话剧的关注人数当然没有偶像剧多，但我们都需要好好演戏，认真对待剧本，认真对待观众这一点也和Yvonne老师在工作坊中说的不谋而合，B端产品和C端产品都需要用户与产品调研、定位核心问题、产品规划和开发、推广上线与运维最后，按照惯例我得发鸡汤了，送给B端、后台业务从业者（包括我自己，嘻嘻）一段陈道明在传承者节目中的讲话：我在天津人艺，我有七年的时间，在台上一句台词没有。这一场演匪军，下一场演伪军，再演，再下一场演八。我在想，就是人在各种职业当中，要有一种甘于寂寞的准备你们要努力，但是不要着急，凡事都应该有过程PS：关于产品设计的思考在以往以及未来的产品文章中都会有体现，欢迎大家关注我不定期更新的产品相关文章兮兮，微信号：孤身旅人（ID：gushenlvren），人人都是产品经理专栏作家。关注人工智能、toB产品、大文娱等领域。