本文写于2016年12月
三周前的那天,川普被选为下一任美国总统,将在至少未来四年成为全世界最有权威的人,带领美国走向光辉或地狱。相信大家已经看过各种分析的文章,每个人也都会有自己的看法,而我想从产品的角度分析一下:如果我们把总统候选人当作一个产品来看的话,川普和他的团队做得如何? 了解和尊重用户的痛点 川普出身精英阶层,但他深知美国选民都是什么样的组成,他们各自又有什么诉求。几个事实:红州人口和蓝州人口的预期寿命相差五年之多;农村中老年白人家庭的家庭收入在近些年持续下降;白人劳工阶层教育程度不高,在全球化和科技化的冲击下,他们丢了工作还很难再去寻找一份技术含量高的工作,也不像少数族裔受到各种政策照顾;曾经低于他们的少数族裔,现在过得比他们好,不光是经济上,他们传统的价值观和文化也受到了冲击。 如果我们放下各种诚见,借口,和抱怨,仅仅从这些事实出发,你会觉得什么样的产品可以解决这些用户痛点呢?是无视或者否定他们的现状?还是告诉他们:嘿伙计,我知道你很不爽,我要帮你改变这一切? 川普知道,要想赢得大选,就要赢得这些和他远远不是一个阶层的选民的支持,而要想赢得这些选民的支持,就要直指他们最需要的,说出他们所想,替他们做他们想做。白人劳工阶层最想要的就是回到没有移民抢饭碗,没有偏向少数族裔,没有恐怖主义的时代,所以川普才会打国家主义的牌,以“让美国再强大”作为竞选口号。对比来看,希拉里的竞选口号是“一起更强”。这听上去更加美好的宣言在白人劳工阶层看来却是不可能实现的,或者至少是以有损他们的利益来实现的。希拉里团队有意或无意忽略的是最有可能决定选举结果的选民最深切的诉求,即用户的痛点,而川普的团队不仅深知还知行合一。 对于产品经理而言,切中用户痛点是一切的根本,但其实执行起来处处是关卡。首先就是我们自己的认知,尤其是对于并非经常使用所开发的产品的产品经理,我们太容易活在自己构筑的乌托邦里,而无法真切地体会目标用户的急切需求,生活琐事,和心理活动。在这里分享一个听起来很平常但真的做到的人不多的增加同理心的方法,对做产品,与人交往,甚至表演艺术都适用:“我们可以在头脑中根据目标用户的特征勾勒出一个具体的画像,比如说一个从小在中国长大的刚刚毕业于美国大学的毕业生。在有了这个画像之后,想象我们就是这个人,这时候需要我们放下心中的一些情绪和看法,更需要我们暂时放下自我(可以在开始前做些冥想,推荐app: Headspace)。当我们可以在脑海里变成这个人之后,开始想象我们作为这个人在普通的一天会做的所有事情,然后我们设定一个和痛点有关的场景,再想象我们作为这个人在这个场景中会经历的事情。有些场景可以演出来--说出一些对话,做出一些动作,哪怕对面没有人。” 第一次做肯定觉得很别扭,熟练了以后可以很快进入角色,并且真的可以感受到对方的喜怒哀乐爱恨情仇。当然,我们能感受到的毕竟有限,而这个限度和我们的世界观和人生观都有关系。因此,个人的成长和修炼对于产品经理来讲也是必不可少的。 其次就是用户的认知,很多时候用户以为自己需要某个产品或功能,但其实他们并不真的需要。和用户沟通的时候,很多问题是引导性的,在提问的时候就已经有了偏差,比如:你觉得你需要某个东西吗?你想解决某个问题吗?你喜欢做某件事吗?解决这个认知陷阱可以通过用下面的问题来替代:你觉得在完成某件事上最大的困难在哪里?对于你提到的这个问题,你有没有尝试通过什么方法来解决?在过去的一个月之内,对于你喜欢的那件事,你做过几次?总结一下就是:1. 开放性的问题好过答案是Yes or No的问题 2. 真的痛点会促使用户努力寻找解决方案,会让他们克服惰性,只不过你的产品可以给他们提供更好的方法 3. 真的兴趣会促使用户养成一定的习惯和付出行动,而不是嘴上说说(推荐书: The Mom Test)。有的时候,用户提出来的需求是伪需求,但结论并不是这不是痛点,我们可以走开了,而是要继续深入发现伪需求下面的真需求。比如:如果用户告诉我们他的需求是一把梯子,而通过沟通我们发现他并不需要梯子,那我们可以继续讯问他到底是要解决什么问题,问到最后我们可能发现他的需求是上房顶。 第三个执行难点就是用户自己没有意识到痛点。这点是不是个伪命题?我不是刚刚说了真正的痛点和兴趣会促使用户展开行动?其实,用户会意识到自己需要某个产品或功能,说明他们已经处于知道自己不知道的情况下。但还有一种情况是用户不知道自己不知道。对于这一点,乔布斯坚信用户不知道自己要什么,他说过“锁定特定族群来设计产品是很困难的。因为大部分的时候,人们都不知道自己想要的是什么,直到你展示给他们看。” 基于对iPhone的成功,很多公司以此为产品设计的理念,甚至因此而不再重视市场的信号和用户的反馈。这里有个三个明显的逻辑错误:第一,iPhone的成功和“用户不知道自己要什么”的理念不构成因果关系;第二,就算构成因果,这里还忽略了其他的因果因素;第三,就算是我们考虑了所有可能的因果因素,我们也不能将iPhone的成功因素简单地generalize。可以不客气地说,大部分这样的公司,只不过是在给自己思维的懒惰找借口。对于用户不知道自己不知道的情况,产品经理需要做的是通过对于市场的分析和用户的理解以及自己的直觉来判断:这个其实是伪需求,还是真的是用户不知道自己不知道?如果结论是用户不知道自己不知道,那么教育用户就是开发和推行产品的过程中必须要面对的。根据教育用户所产生的信息,我们可以进一步反思和判断,更可以改进和用户沟通的方法,慢慢得让用户产生正确的意识。对于如何教育用户,这是个大话题,我们可以单开一篇进行讨论。 我们可以看到,在了解用户痛点这一点,川普和他的团队做得十分到位:选民的需求十分真切,而川普在竞选中的很多方案和言论也都是围绕他们的需求展开。 洞悉和利用人性的弱点 川普的路数:宣泄大众愤怒情绪,煽动民族主义找替罪羊,重建伟大国家为口号,建立外部假想敌,等等,都是在妥妥地在利用人性的弱点。在竞选过程中,川普的过激言论不绝于耳,从要在墨西哥边境修墙,把流失到海外的工作岗位带回美国,反对堕胎,到以前侮辱女性的言论,每一次都让人大跌眼镜。在三次辩论中,希拉里也对于川普的言论进行了有逻辑的反击。但是在这场较量中,恰恰是逻辑输给了情感--川普就是凭借诉诸选民焦虑情绪的能力,凭借对名人效应和让人难忘的羞辱言辞的精明利用,来赢得白人蓝领阶层的心。当然,我相信希拉里是非常深刻理解人性的弱点的,但是在竞选中他们没有重视关键选民的弱点,更没有有效利用它们。 《歌罗西书》第2章第18–23节的经文讲述了人类的七宗罪: 傲慢,嫉妒,愤怒,怠惰,贪婪,暴食,色欲。七宗罪的本意是指对爱的违背。这里的爱不是指爱情,而是大爱。可以说即使是出于马斯洛需求层级最底层的人类生存根本--生存的需要和安全的需要,如果取之过度,都是罪。有些人严于律己讲求精进,但大部分人都不是圣贤,在漫长的一生中,我们都在和这七宗罪纠缠。其实有罪的最大受害者不是别人而是自己,因为一旦有所图,所图之物便成了我们的弱点,我们就容易被控制。除了从宗教角度定义的七宗罪,人性还有很多其他弱点。从商业的角度来讲,许多行业赚钱都是在某种程度上利用这些弱点,比如:游戏行业利用的是怠惰和贪婪,社交媒体利用的是傲慢和嫉妒。PayPal mafia中的LinkedIn创始人Reid Hoffman在谈及自己的投资理念的时候就说过,只有公司的产品涉及至少七宗罪之一他才会投。在利用人性弱点上,考验的是对道德底线的把握。 关于利用人性的弱点做产品是否道德这一点,我觉得这和大部分事情一样,要看你的动机,产生的影响,和对度的把握。川普的短期动机很显然是要当选总统。如果说他当选美国总统的长期动机真的是想为这个国家的人民做事情,想把美国变得更好,那么他的动机还算是好的。当然,除此之外,为自己的生意争取最有利的政策,提高自己的知名度和影响力,等等,应该也是他的动机。不过,我们每个人做事情的动机都很少是纯粹的。这个时候我们再来看看产生的影响。川普的过激言论加剧分裂了美国。白人蓝领阶层和精英阶层,少数族裔,移民之间的冲突虽然早就存在,川普却让人与人以心底最黑暗的部分相对,煽动强化了早已孕育在人们心中的怨气和愤怒,把这些矛盾激化了出来。这不仅让我想到了一战后的德国--国人心中的屈辱感,当时萧条的经济,和有着特殊演讲才能的希特勒。川普利用人性的弱点来达到自己目的这点,我个人十分不认同。我也相信,动机不纯地利用人性弱点产生恶劣影响,即使短期来看成功了,也不会长久,更不会产生真正好的影响。 举个具体的关于人性的产品例子:大家对微信朋友圈提醒功能的小红点应该都不陌生。潜意识里,我们总是想把这个小红点消除,它就驱使我们不停去点击朋友圈。我们想把小红点消除的冲动主要是源于我们害怕错过一些重要信息,当然也有些人是由于强迫心理。而无论是出于什么,消除小红点已经成了一个瘾。微信通过这个方式来加强用户使用朋友圈的频率,用户频繁使用朋友圈更有助于用户发现有用信息从而加强分享和互动,更多的分享和互动再次促进小红点更加频繁的出现。如此循环往复形成良性循环(virtuous loop)使产品有了自我延伸(self-perpetuating)功能,而自我延伸功能决定了一个产品是否可以产生真正的用户粘性。小红点是微信的小邪恶,但这个小邪恶很轻,而且用户使用微信的好处确实是十分明显的,所以对公司和用户来讲,算是双赢。在利用人性弱点上,微信打了很漂亮的一仗。 另外一个相反的例子是近期很火的支付宝的校园日记和白领日记。女生才可以发帖,芝麻信用750分以上才能评论,等等设定,都是在利用女性来刺激女性的炫耀心理和男性的猎奇心理。很明显,阿里在各种社交尝试失败之后,有些着急了。今年应该是微信支付全面发力的一年,目前微信支付用户已经达到了4亿。如果支付宝不能从支付转型到社交,它很快会被从社交延伸到支付的微信所击败。支付宝的社交产品用户资源是十分丰富的,但它的社交属性和社交基因都偏弱。所以支付宝增加了具体场景,希望以此提高产品使用频次增加用户活跃度,而校园日记和白领日记都是具体的场景。支付宝通过打擦边球来繁荣景象的做法会使运营数据在短期内十分好看,但在用户的新鲜感过去之后,产品的纰漏开始显现,而这个时候再依靠利用人性弱点去做,会适得其反。 支付宝这次做得不好,最多就是成为了陌陌。而川普的行为则是影响了最有影响力的国家和它的人民,还有和美国有关的国家和人。更重要的是,它产生的影响是极有破坏性的和不可逆的。 制定最佳产品推广计划 说到产品策略和推广计划,在这次大选中,我们不得不提到Jared Kushner,川普的女婿。Jared在川普的竞选中扮演了十分重要的角色,除了为川普游说到了一些重要人物的支持以外,Jared还帮川普在新媒体上赢得了胜利。总结一下Jared做的事情:像硅谷最好的数字营销人员拜师学习;关注营销的投资回报率,不乱花钱(川普团队的花费是希拉里团队的一半);拥抱新媒体--在传统媒体上投入较少,在新媒体上利用数据快速试验和迭代;接入共和党的数据系统系统,分析出了选民最关注的问题,并自创了一个基于地理位置可以分类选民的工具;通过机器学习选出最有效的竞选宣传文案,并每天发送10万个个性化推文给目标选民。听起来像不像是一个有经验的marketer? 可要知道,Jared在这之前连一个推文都没发过,他手里的竞选资金又很有限,所以他能帮川普在新媒体打下一片天地实属不易。 做产品最忌讳“酒香不怕巷子深”的想法。即使是大公司的产品,产品再好,如果不能很好地推广,那也和成功无缘。成功的产品推广除了创意以外,数据分析是必不可少的工具。完善的数据分析能力包括:数据挖掘和清理,数据分析,利用数据做决定,数据可视化。很多产品经理都可以利用数据做决定和实现数据可视化,但对于数据挖掘和清理以及数据分析就不是很擅长,而是依靠数据科学家来完成。我很赞成术业有专攻,在公司里大家也应该各司其职,但是对于产品经理来说,提升自己的数据能力其实是前期需要投入但后期事半功倍的。第一,在数据挖掘,清理,和分析的过程中,有很多和产品相关的决定。比如在进行一个A/B测试时,要制定相应的数据采集方案和时长--是用用户ID还是用cookies,试验对和对照组分别需要多少人,是进行半个月还是一个月,等等,每一个决定都有关于产品特性的考量,可以说如果产品经理有很强的数据能力,那么和数据科学家之间的沟通协调就要容易很多,大家也可以提供自己的观点从不同的视角进行有效的讨论。第二,在产品背后的数据库的构建上,由于产品经理最了解对于产品的长期策略和迭代的需要,因此一个有数据能力的产品经理可以告诉工程师他对data table的建议,使得工程师的工作更高效。第三,产品的前端设计也会影响后端数据的收集,所以一个懂得数据的产品经理可以更好地考量产品设计,将日后的数据收集考虑进去。第四,一个有数据能力的产品经理对数据更加敏锐,所以可能通过数据发现一些潜在的或其他人忽略的问题。 产品经理提高自身的数据能力的方法很多。对于已经在做产品经理的人,最有效的学习途径就是快速学习最相关的数据分析工具,重新熟习基本的数学和统计学原理,然后将更多的精力放在解决实际问题上。对于渴望成为产品经理的人,积累一些相关的产品经验是最有用的,同时掌握一些数据分析工具也是十分必要的。总结而言,无论是现在处于什么阶段,对于提高产品经理的数据能力来说重要的就是:1. 基本数据分析工具; 2. 实践。 对于基本数据分析工具,网上的资源非常多,但一个问题就是学习每个工具都需要一定的时间,因此找到一个帮助你筛选出最重要的工具并且总结出每个工具中最重要的基础知识的资源就十分有用。对于实践,最有效的就是做project。Project不仅增加了学习的乐趣,还可以帮助我们从理论走到实践,增强学习效果,另外,project还可以作为自己的portfolio来展示。 关于在线学习,最大的障碍就是:缺乏及时的反馈和互动,拖沓以致最后不能完成课程。但即使如此,在线学习仍然是最简便高效的。为了帮助大家选择,我简单分析一下几个网上的学习资源: Lynda.com:已被LinkedIn买下;以看video为主,对于了解一个新工具/领域,讲解十分清晰有逻辑;缺点在于没有什么反馈或互动,全靠自己去听讲和记笔记,更加靠自己的自觉去完成; Codeacademy:以看静态的文字instruction为主,每节课都有problem set帮助学生了解自己的学习程度;有论坛可以互动,但是基本都是学生之间的;课程讲解比较浅显而且不够系统化,需要自己额外自学很多; Coursera/Udacity/edX:以看video为主,讲解框架设计科学;有论坛和mentor office hour等制度来增加反馈和互动;有project, 但是比较简单;由于内容繁多,但是上课时间没有限制,容易半途而废或者拖沓; BitTiger:以直播为主,限定了观看时间,对于督促完成很有效果;基本的知识框架和project结合,可以从project中学到很多;可以根据project选择课程;时长短(只有5–6周);收费低(少于$1000); General Assembly/Product School/Galvanize:线下教学;面对面的反馈和互动,学习效果更好,也更有动力完成;课程时间长(9–12周),线下不够灵活,容易缺课,缺课后也很难弥补;有project,可以从project中学到很多;收费昂贵 ($4000-$16000左右); 川普在产品宣传上益于Jared对于新媒体的把控,针对选民特点和反馈来进行的新媒体宣传则是以数据分析为基础的。这一仗川普的团队打得十分漂亮! ------------ 总结下来,川普的团队在了解用户痛点和使用数据对产品的宣传进行迭代上都做得很出色,在很大程度上川普的胜利也得益于此。对于产品经理而言,这是一个很好的学习案例。我们当然要把握好自己的道德底线,但除此之外还有很多软技能和硬功夫需要我们去学习。在这个过程里,有一些资源可以帮助我们更有效地提升,这些好的产品不仅是我们的学习对象,也是我们可以直接利用的,在这里总结一下上面的分享,希望对大家有帮助:
做产品说到底是不断自我修练和挑战的过程,让我们成为更好的自己更好的产品经理,共勉!
0 Comments
Last time, we talked about Being a Product Owner and Communicating with the Technical Team in Part I. Today, I will continue the topic “What it’s like being a B2B product manager” and focus on Bridge the Gap between Technology and Product Backlog.
Bridge the gap between business and technology Technology is always a means not an end. The goal of a product is not how cool the technology it has, but what it can actually achieve through the technology. After all, a good product should add value to users. Users don’t care about what technology it uses, but what results they could see. Being the bridge between business and technical is crucial to a product manager’s job. Real pain point The very first step is to understand the real pain point of users. For B2B product, we can talk to customers directly. While having conversations with them, it is crucial to be a good listener. However it doesn’t mean we have to take whatever they say literally. Usually, users’ mindset is in their current way of doing things, so very constrained. What is important here is to understand the rationale behind their current behavior. Quite often the reason is not solely related to technology, but also related to the entity’s culture, industry’s standard, and other more subtle ones. If they don’t mention the rationale proactively, simply ask. Here is an example to explain my point: We have a law school customer who insisted on having one step form for on-campus recruiting registration, while all the customers of business schools are quite happy with two step form. Having the form in two steps can provide employers more flexibility, because they can finish two steps at different time and submit to schools for review and approval. In addition, two steps are for different user types — one is for career center, and the other is for both career center and students. So we naturally thought that two steps is the way that makes sense, until we got to know why law schools use one step form. In recent years, there are too many law school graduates, so it is very hard for law school students to land a job in big law firms nowadays. In recruiting, law firms have the bargaining power, and law schools are trying their best to impress/please the law firms for their students. Changing system from existing one to ours already needs learning and forming new habits, so the schools would like to eliminate as many obstacles as possible for employers. If employers are happy using the new system, the school can maintain good relationships with them. For above example, their real pain point is not about one step form or two steps form, but more about how to maintain good relationships with employers. Understanding this makes a huge difference for us to figure out the best solution for them. User education Depending on the industry, it might be necessary to educate users for an appropriate expectation on the technology. We have customers who used paper and Excel to handle all the student data, and they were really happy with this way. Explaining to them what they couldn’t even image but could do with a software and using data to convince them can help them visualize the benefits. We also have customers who were using software, but in an old-fashioned way. Customers like this might behave in two extreme ways. One extreme is that they want to change and at the same time are afraid of having big change. This is particularly true in more traditional industries and non-profit driven entities. Take schools as an example: Shools are non-profit entities, so stuff at schools are less motivated by financial return (the upside), but more concerned with potential risks (the downside). Letting them understand the direct benefits they would have by adopting the new technology and brainstorming with them together for methods that we could use to eliminate the risks are the essence to get them onboarded. Another extreme is that schools are very tech-savvy and advanced, and they have very high expectation on the new technology. One of our customers used to think that by clicking a “set up” button, the API will be automatically set up and two way sync of two totally different calendar systems can be done. It took me some time to explain to them why this is not the case. Customers like this are easier to communicate with though, as they are more open-minded to new things. What we need to do is to let them understand the limitation of the new technology and figure out the solutions with them together. Best solution Based on customers’ size, resources, team culture, and other possible attributes, the best solution can vary from one to another. Advanced technology might not be the optimal, and we need to be cautious here, as working in a tech company usually makes us more inclined to adopt the cool way of doing things. Witholding our own desire and having the real empathy on customers is crucial: If a fast horse is more appropriate for them, then we shouldn’t build a car. When desining the best solution, our product goal needs to be taken into consideration. It is important and helpful to build the product in a configurable way, but beyond this and making special changes for a particular customer should be minimized. If it’s hard to make customer agree on a solution, it might be a signal that:
For reason 2, it could be a tricky issue, depending on the sales team’s practice. However, it does need paying attention to and having a conversation internally to make sure every team is on the same page. Onboarding Onboarding can be painful, especially if the software is not an easy or straightforward one. Having a knowledge library and dedicated customer service team can make the whole process a lot easier. But still, it can be a difficult process. Doing demo to users is very helpful to get them started. Based on my experience working with numerous customers, letting them use the software is the key to learn about it and form the new habit. It sounds easy, as they can play around it by themselves, but without much effort from us, the result can be quite unexpected. Users might think they got plenty of time to use it after the product is officially launched, so they might be reluctant to extensively use it during onboarding. This could cause the situation out of control after launch if they are so unfamiliar with the software. An effective way is to let them use it is to let them share their screen and demo to us how they use it, or if resource permits, it’s more efficient to conduct it in person. Another effective way is to let them do a simulation. This is particularly useful and necesssary if the end users are from different teams or entities. When the users are seriously using the software, things will really move forward effectively! Another crucial part of onboarding is customer’s past data transfer. If there is in-house onboarding tool built, hooray! For many startups, they might not have it or have it partially, which means manual data transfer is needed. If this is the case, using Excel VBA can be really helpful to streamline the process a bit. However, I still think taking sometime to build the onboarding tool makes lots of sense, as hiring human beings to do onboarding can be very expensive. Last but not the least, stress test is a must. For a simulation, a number of users will join, but this is just a number of. When the product is used by hundreds of and thousands of users at the same time, UI can be different, the server burden is different, and the whole experience can be different! Product iteration Once product is launched to customers, it is the end of the development stage and the beginning of product iteration. The journey just got started! Though we have talked to customer a lot during onboarding stage and have a very good understanding of how they use our product, the usage in real case can be different. Google Analytics is a good tool to see how users use our software. Looking at the log inside database can also give us insights into how a particular feature is used. There is a saying that “The challenge with data though, is that it often tells you what is happening, but not why something is happening.” So quantitative information is not enough, we also need qualitative feedback to get a sense. Usually, qualitative feedback can come from customer service team and sales team. If your company has a online blog or forum, or any social media page, user comments could be another source. Another useful method is to observe. Without giving users any guidance, just see how they actually use it, which might surprise you. Survey is a popular tool to get user feedback. However, I do think survey is hard to be effective. There are so many potential biases when users answer a survey, and so many ways of asking the wrong questions to make the bias more serious. If it’s not expensive, it could be complementary to other methods though, but don’t take it too seriously. Product backlog Usually PM team will have a very long list on product backlog. Requests can come from customers and internal teams, e.g. sales, customer service, marketing, engineering, and product team itself. Making decisions on what to be included and prioritize the long list is an important task of product manager. What should be taken As mentioned above, not all requests from users should be taken. There are several considerations: Competition landscape:
Product vision:
Impact on users:
PMs should take Must-Be, and should not take Indifferent. For Performance, the increase of additional satisfaction is declining, so there could be an optimal value. For Attractive, too much positive unexpecation means the product strategy has issues. How to prioritize Prioritization is a combination of arts and science. One set of criteria can be similar to the “Impact on users” section above. Another important aspect is the internal efforts.
Last but not the least, the overall timing.
For some criteria above, different people might have different opinions. Different opinions can be a combination of objective and subjective. Many times, people who should give opinions will also be affected by the prioritization, so inevitably their personal agenda or emotion will be involved in the evaluation. It is important to listen to different opinions and be clear on the standard to make final decision. However, many times, PM has to be the bad cop. It is not fun, but very important. So if it’s necessary, we make our decisions and say no to others. Being a product manager is not easy, and it also needs life-long learning, as industry, market, and product are changing too fast. So the most important qualities of PM might be being open-minded, being curious, being resilient, andlearning fast. These will make sure that even if we are not good at it today, we can get better; even if we will fail, we can get up, reflect, and keep moving; even if things change, we can adapt; even if everything goes on well, we can still be alert and listen to others…The journey is tough, but very rewarding! Enjoy! This is Part II of “What it’s like being a B2B product manager”. I realize that there are still things to talk about, e.g. sprint/scrum management, team management, cross-functional communication. However, I do feel like the rest could be more common in different roles, and there are already plenty of information online. Hope my writing is helpful to you. When we talk about product management in tech, usually we don’t explicitly distinguish between B2C and B2B. What we often hear people say is “Product management is very vaguely defined and varies a lot in different companies depending on the type of product, the size, stage, and culture of the company.” This is very true. The size and stage of the company might refer to the amount of resources the company has and in turn decides the scope of product manager’s daily job. For type of product, B2C and B2B is just the first layer. Inside B2C / B2B, it can still be very different. For example, a product can be transactional or non-transactional. In this article, I would like to share my understanding of B2B product management. If you are also interested in the differences between B2C and B2B product management, here is a very concise article about it.
Being a product owner Many B2B companies, especially small ones, follow agile/lean process. Per every 1–2 weeks (for some it might be 3–4 weeks), sprint/scrum team focuses on certain tickets and release the new features in the end. Agile process is very common in fast-changing environment, within smaller teams, and when users are not that sensitive to change of plan and easy to communicate to. There is usually a sprint/scrum manager, a role similar to project manager, responsible for moving the agile process forward. However, in smaller companies, product manager can also be the sprint/scrum manager (this is the case in my company). Usually the product manager is the product owner. Product owner is responsible for the module of product (complex one) or the whole product (simple one) from idea to launch, and after launch feedback gathering and further iteration. An important task of product owner is to move things forward and get things down according to schedule with high quality. Product owner doesn’t “own” a team, but needs to coordinate among different teams — this is why a critical skill of product owner is leadership without authority. Everyday’s tasks are different. In general, daily jobs include market research and competitor analysis, discussion with customers, product design discuss with UI/UX designer, development discussion with technical team, QA arrangement, testing, and review, other product related issues , e.g. data migration, internal and external training, sprint release announcement, marketing collateral discussion with marketing team, sales demo idea, product feedback and data collection, and review and analysis. Communicating with technical team Many B2B products are complex and technical, so product manager might need to have certain technical background. However, this is not a must to most companies. What they really need is someone who has the curiosity, the empathy, the judgement, and articulating skills to communicate with technical team. Having technical background is a strong signal of these qualities, but not a must. Below is how to achieve each part: Curiosity: It’s very easy to have curiosity towards business side / front-end of the product. Back-end is not that interesting. However, how the data tables are constructed, what algorithm is used, and how the whole infrastructure looks like, can strongly affect how the frond-end performs, and how you can design the product, and plan the development process. We don’t have to code or understand the details, but getting to know about back-end can make our job much more effective. I believe curiosity can be cultivated. Maybe letting us put aside all our concerns, assumptions, or judgments is really hard. Instead, we can start from understanding the benefits of having the knowledge. Once we know the benefits, we are more willing to give it a try. With the knowledge, we can make better decisions and plans. And once we start to see the real benefits, our belief got reinforced. A good virtuous cycle can keep going like this. Every day, when we deal with product design and development, we can have the habit of figuring out how the back-end works:
Depending on the job, but most of the cases, you don’t have to have extensive database or programming language skills. The basic query skills and knowing how to read the code can be extremely helpful though. There are already too many resources online. It’s not very helpful to write another article on it, but I can list some of the sources I find useful (I only learned SQL and Python): SQL: Step 1: Understand the fundamentals of relation database and get familiar with basic commands https://www.lynda.com/: Lynda is very good at bringing you into the door. Its videos are very easy to follow, and the teaching is well structured. Step 2: Play around in the real database and find solutions by yourself http://www.w3schools.com/: 3W school is a very good place to find quick guidance. It’s well organized and easy to search, and pretty concise and to the point. Step 3: Figure out more complicated issues and contribute to others’ questions http://stackoverflow.com/: Stackflow is a good place to find answers to some issues others might have encountered, and you can share your solutions as well. 2. Python: Step 1: Understand the fundamentals of Python http://stanfordpython.com/#overview: This is Stanford’s Python class. It will help you lay a solid foundation upfront. Step 2: Learn about different concepts of Python http://learnpythonthehardway.org/book/: Learn Python the Hard Way is very comprehensive and easy to follow. Step 3: Exercise https://www.codecademy.com/learn/python: Codecademy is not very easy to follow (maybe just my thoughts), because it won’t teach you the higher level idea, so you couldn’t have an overall understanding and it’s easy to lose in the details. In addition, the instructions are usually not clear enough, so you have to search online to find better explanation. However, there are many exercises on Codecademy, and solving problems in exercises is the best way to practice. Step 4: Read others’ code and try your own https://pypi.python.org/pypi/pip, https://github.com/python: There are so many well-written Python code out there, and you can learn a lot by reading the code. Later on, you can try improving the code and write your own code. Empathy: Communicating with technical team needs us to treat them as real human beings, instead of programmers. They have their motivations and concerns: they want to do a good job and contribute, and would be worried about the quality of the code and future maintenance. It’s easier said than done, especially when the product manager is very concerned about the business side. In the deep level, PMs and developers have the same goal— to make the company and product successful, so the product manager really needs to make it obvious and move things towards that direction. Technical team seldom has the chances to face customers. When discussing the technical solution with them, it’s very helpful to let them know the business rationale behind, and your overall product strategy and future plan. First, this will help them relate to the users. Second, it will also help them have a bigger picture of what’s going on so that they can provide better insights. A even more important thing is to let technical team know how valuable the final product is to the customers. Gathering data and also forwarding customers’ feedback and/or “Thank you letter” to technical team is a great way to show gratitude. Judgement Having a good judgement is crucial in sprint planning. Sometimes we might think doing something is very simple, but actually it’s not. If it needs a database change, there might be lots of work, especially if the table touched is one of the main tables. Developers or data team might need to do data migration too. It might also take lots of time to do QA and review. If more complicated, code refactoring or even architecture refactoring might be needed, which is much more time-consuming. So when a developer tells you how long it’ll take to finish your request, how can we judge it? Understanding the back-end is very helpful here. Another way is through learning by doing — we’ll have the judgement once we’ve seen and experienced a lot. Of course, we can learn faster if we constantly reflect and summarize. Articulate Articulate is crucial to make sure our message is clearly delivered and received so that everyone is on the same page. There are different ways to describe an idea: user stories, wireframe, workflow chart, product specs, and ticket writing. If time permits, a video or a prototype can be produced and provided too. For wireframe, so many tools are out there: Paint, Balsamiq, UXPin, Azure, Sketch, PPT wireframe, Photoshop…It depends on each person’s habit and the need of the wireframe when deciding which one to use. Besides, personally I find Excel and PPT good tools to use. When designing complex products, I like providing my insights into the design of data tables based on my understanding of current request and future product iteration needs. In addition, Excel can be used to define business rules when different rules are needed for different users under different stages. PPT is a good place to illustrate user stories by combining wireframe in sequence. The above is all work on paper. Talking to technical team in person (conf. call with screen sharing if remotely) is equally important. Being open-minded and taking in their feedback and advice can help us reflect and re-think through the issue — maybe there are better ways, maybe an important user case is missed, or maybe things can be more complicated than we expect…Sure, finishing all the wireframe and other paper work is not easy and we don’t want to re-do it, but ignoring the issue won’t save any time but cause big troubles later on. Hope this article is helpful to you. I’m looking forward to knowing your insights into B2B product management. In Part II, I will keep sharing and topics will include “Understanding customer’s real pain points” and “Prioritizing the product backlog”. Stay tuned:) |