What it’s like being a B2B product manager — Part 1

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 the 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:

• Understand how different parts of the product work cohesively, how the data is stored and read, and how an action got executed.
• Go to the database to see how the data tables look like, and read the relations. Think why this is the way and if there could be better ways.
• Ask developers for the code and read their code. Think why this is the way and if there could be better ways.

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):

1. 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:)