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.