对于产品经理而言，切中用户痛点是一切的根本，但其实执行起来处处是关卡。首先就是我们自己的认知，尤其是对于并非经常使用所开发的产品的产品经理，我们太容易活在自己构筑的乌托邦里，而无法真切地体会目标用户的急切需求，生活琐事，和心理活动。在这里分享一个听起来很平常但真的做到的人不多的增加同理心的方法，对做产品，与人交往，甚至表演艺术都适用：“我们可以在头脑中根据目标用户的特征勾勒出一个具体的画像，比如说一个从小在中国长大的刚刚毕业于美国大学的毕业生。在有了这个画像之后，想象我们就是这个人，这时候需要我们放下心中的一些情绪和看法，更需要我们暂时放下自我（可以在开始前做些冥想，推荐app: Headspace）。当我们可以在脑海里变成这个人之后，开始想象我们作为这个人在普通的一天会做的所有事情，然后我们设定一个和痛点有关的场景，再想象我们作为这个人在这个场景中会经历的事情。有些场景可以演出来－－说出一些对话，做出一些动作，哪怕对面没有人。” 第一次做肯定觉得很别扭，熟练了以后可以很快进入角色，并且真的可以感受到对方的喜怒哀乐爱恨情仇。当然，我们能感受到的毕竟有限，而这个限度和我们的世界观和人生观都有关系。因此，个人的成长和修炼对于产品经理来讲也是必不可少的。
其次就是用户的认知，很多时候用户以为自己需要某个产品或功能，但其实他们并不真的需要。和用户沟通的时候，很多问题是引导性的，在提问的时候就已经有了偏差，比如：你觉得你需要某个东西吗？你想解决某个问题吗？你喜欢做某件事吗？解决这个认知陷阱可以通过用下面的问题来替代：你觉得在完成某件事上最大的困难在哪里？对于你提到的这个问题，你有没有尝试通过什么方法来解决？在过去的一个月之内，对于你喜欢的那件事，你做过几次？总结一下就是：1. 开放性的问题好过答案是Yes or No的问题 2. 真的痛点会促使用户努力寻找解决方案，会让他们克服惰性，只不过你的产品可以给他们提供更好的方法 3. 真的兴趣会促使用户养成一定的习惯和付出行动，而不是嘴上说说（推荐书: The Mom Test）。有的时候，用户提出来的需求是伪需求，但结论并不是这不是痛点，我们可以走开了，而是要继续深入发现伪需求下面的真需求。比如：如果用户告诉我们他的需求是一把梯子，而通过沟通我们发现他并不需要梯子，那我们可以继续讯问他到底是要解决什么问题，问到最后我们可能发现他的需求是上房顶。
《歌罗西书》第2章第18–23节的经文讲述了人类的七宗罪： 傲慢，嫉妒，愤怒，怠惰，贪婪，暴食，色欲。七宗罪的本意是指对爱的违背。这里的爱不是指爱情，而是大爱。可以说即使是出于马斯洛需求层级最底层的人类生存根本－－生存的需要和安全的需要，如果取之过度，都是罪。有些人严于律己讲求精进，但大部分人都不是圣贤，在漫长的一生中，我们都在和这七宗罪纠缠。其实有罪的最大受害者不是别人而是自己，因为一旦有所图，所图之物便成了我们的弱点，我们就容易被控制。除了从宗教角度定义的七宗罪，人性还有很多其他弱点。从商业的角度来讲，许多行业赚钱都是在某种程度上利用这些弱点，比如：游戏行业利用的是怠惰和贪婪，社交媒体利用的是傲慢和嫉妒。PayPal mafia中的LinkedIn创始人Reid Hoffman在谈及自己的投资理念的时候就说过，只有公司的产品涉及至少七宗罪之一他才会投。在利用人性弱点上，考验的是对道德底线的把握。
说到产品策略和推广计划，在这次大选中，我们不得不提到Jared Kushner，川普的女婿。Jared在川普的竞选中扮演了十分重要的角色，除了为川普游说到了一些重要人物的支持以外，Jared还帮川普在新媒体上赢得了胜利。总结一下Jared做的事情：像硅谷最好的数字营销人员拜师学习；关注营销的投资回报率，不乱花钱（川普团队的花费是希拉里团队的一半）；拥抱新媒体－－在传统媒体上投入较少，在新媒体上利用数据快速试验和迭代；接入共和党的数据系统系统，分析出了选民最关注的问题，并自创了一个基于地理位置可以分类选民的工具；通过机器学习选出最有效的竞选宣传文案，并每天发送10万个个性化推文给目标选民。听起来像不像是一个有经验的marketer? 可要知道，Jared在这之前连一个推文都没发过，他手里的竞选资金又很有限，所以他能帮川普在新媒体打下一片天地实属不易。
产品经理提高自身的数据能力的方法很多。对于已经在做产品经理的人，最有效的学习途径就是快速学习最相关的数据分析工具，重新熟习基本的数学和统计学原理，然后将更多的精力放在解决实际问题上。对于渴望成为产品经理的人，积累一些相关的产品经验是最有用的，同时掌握一些数据分析工具也是十分必要的。总结而言，无论是现在处于什么阶段，对于提高产品经理的数据能力来说重要的就是：1. 基本数据分析工具; 2. 实践。
Coursera/Udacity/edX：以看video为主，讲解框架设计科学；有论坛和mentor office hour等制度来增加反馈和互动；有project, 但是比较简单；由于内容繁多，但是上课时间没有限制，容易半途而废或者拖沓；
General Assembly/Product School/Galvanize：线下教学；面对面的反馈和互动，学习效果更好，也更有动力完成；课程时间长（9–12周），线下不够灵活，容易缺课，缺课后也很难弥补；有project，可以从project中学到很多；收费昂贵 （$4000-$16000左右）；
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.
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.
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 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!
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.
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:
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:
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):
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.
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.
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.
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 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:)