Communication as a Product Manager

In the introductory chapters, we already drew the picture of a Product Manager acting as a Spider in the Web, meaning they have to collaborate with all departments. In this chapter, we will drill a bit deeper and shed some light on the specific needs of each of these departments.

Tough Communication with Sales

Most B2B Need Sales

In a B2B business, where navigating through layers of buyer personas and what each of them wants is essential to strike a deal, there’s no doubt that the Sales department is of significant value. This is not to say that Sales are more important than, for instance, Marketing, like we described in Porter’s Value Chain, it takes every activity along the stream to collaborate well to deliver value to customers. As a B2B Product Manager, it’s crucial to work well with Sales.

Why? Because they know the market. Even the best Product Managers don’t talk to customers as often as Sales. Though mostly to buyers, especially for Presales, they know incredibly well customers’ motivation, the competitive landscape, and the deal breakers in your product.

Salespeople Have a Different Perspective

One reason that numerous product management discussions cover the Sales aspect is that working with Sales seems quite “tough”:

  • They seem relentless. There’s never a lack of feature requests and all are at the top level of urgency. As a Product Manager, you’ll always be hearing from them, uninvited.
  • They often focus on short-term gains. The needs of their current prospect are all that matters, compared to which, any product strategy and business goal are not worth mentioning.
  • They are extremely persuasive. One fundamental skill of Product Management is the ability to deliver a qualified “no”. Sales will often strongly challenge this skill.

How to Collaborate with Sales

To work well with Sales, leverage what you need and what you have. Sales can offer valuable market insights. Product Managers can solve problems by delivering features. The missing link is to dissect and transition sales feature requests into customer problems, which is again a fundamental Product Management skill.

Lead the conversation. Before a long solution description starts, be the first to open up the conversation.

Thank you for your time today to help me understand the problem…

Ask questions until you get to the problem space.

What does the customer want to do?
Why can’t they do that on our platform?
How do they currently do it?

Interrupt them when they enter the solution space too early.

Do you mind explaining that again before we continue, what exactly does the customer want to achieve?
Can I just stop you for a second, sorry, I still don’t understand the problem.

Even if after a few attempts, the conversation is still much focused on the solution, which is a normal case, rephrase their solution into a problem.

So the problem is that the customers usually have data in format A but we only allow uploading in format B?

Proactively give them information.
Schedule regular check-in meetings with the Sales team. If you have an open door, they won’t go and smash your windows. The lack of communication is the core issue in most communication problems. Let them know that they can always come to you.
Send them progress reports and updates. Certainly, we don’t and we shouldn’t always know what comes in the next Sprint, but the high-level business outcomes should be known to any Product Manager, e.g., a better experience for a certain user persona when doing a certain job with experiments A, B, and C that may come in Q3 to Q4 this year, etc.
Last but not least, be prepared.

Do background research on the information handed to you, prepare worksheets for the meeting if you need to, and remember that you’re there to dig out customer problems, all else are distractions.

Listen to Salespeople because they do know a lot. But go deeper because they don’t know enough.

Depending on the Sales colleagues and organizational culture, communicating with Sales can be tougher or lighter. But if you experience an uncomfortable level of pressure, opening up to your superior is still a choice.

Collaboration with Marketing

In Porter’s Value Chain we discussed that every role in an organization serves the delivery of customer value. In B2B, where value is delivered towards a group of →personas to assist their particular →jobs to be done, it’s critical to communicate well and manage customer expectations. Be it via a product release webinar, trade fair, content marketing channels, etc., we as Product Managers, need strong backing from the Marketing team.

As B2B Product Managers, we could be collaborating with Marketing on a periodical basis, before a major product release or an event for instance, when we pass on information on the new functionalities; or we could be working with Marketing regularly, such as gathering the latest market insights and design the next survey. The fact that matters is that we should have our “marketing muscles” flexed all the time:

  • When evaluating the viability of the four key risks, we should know if the feature or functionality is going to boost our business and in what way. Thus, we have to be able to write a narrative that contains the target audience, the →benefits, and the feature description. Sounds familiar to marketing release note?
  • When collecting customer feedback, we often formulate a message, tell a story, give a product demo, and even put together a poll. These are all intertwined with marketing skills as well.

With this in mind, collaborating with Marketing should be plain sailing. However, there can still be pitfalls:

  • Don’t produce documentation too late. Write feature benefits early in the Discovery phase, update when new findings surface, and give access to Marketing. Unlike Product Management, Marketing teams work on schedules for a conference, a webinar, or similar. For them, a product release often comes with a non-negotiable date, when all materials have to be ready. There shouldn’t be any bottleneck in the process, especially not letting them wait for us to communicate the feature benefits.
  • Don’t only treat the Marketing team as colleagues but tell the story to them like they are the customer. When Marketing teams are the ones who deliver the message to customers, we have to make sure that the message is correct and consistent. What better way than communicate messages using storytelling? We have learned that in such scenarios, these users encounter this problem. The new feature solves the problem in this way.

In summary, Marketing helps us deliver messages to the customer. It’s vital to get closer to their goals and processes in order to work smoothly together.

Working with Customer Success and Consulting

If you have seen the brutal but true meme comparing typical FAANG products, which have nice and clean interfaces, and your product, that  has 100 buttons, you know that simplicity isn’t always achieved in our line of work.

Among many reasons, some B2B products are inherently complicated, because they do solve a suite of complicated problems for various types of people in an organization. That said, product training, customer service, and troubleshooting are crucial, and the Consulting and Customer Success (CS) teams are critical to achieving customer satisfaction.

While Sales may pay more attention to new customers, Consulting and CS definitely are the advocates for acquired customers, or as they often call it, “our customers”. This means they measure their work by customer engagement and satisfaction. From a high level, this is similar to what Product Management wants as well, with the difference that we move towards our product vision, not customer wishes. And this slight difference in standpoints can sometimes cause debates and disagreements between us and the Consulting and CS teams. When that happens, focus on understanding customer problems and turn friction into clarification.

  • At the end of the day, we as Product Managers are here to solve customer problems. This is where the focus of every contact with Consulting and CS should be. It’s easy to first notice their frustration and disappointment:

Our customers have been waiting for this for a year now!
It’s just a text field. The customer doesn’t understand why you can’t simply fix a text field!
The customer will churn if we don’t develop this!

  • But none of the above are customer problems that we can analyze and solve. Ask questions until we have something to start with the Problem Discovery.
  • We are not the complaint department for Consulting and CS, but we do have the duty to deliver and convey product value. We know from Porter’s Value Chain that we need other teams to help us achieve that. If Consulting and CS have doubts about our Product Management approach and are open enough to share them with us, take the opportunity and turn this into a chance to clarify and win their trust.
Show sympathy.

We do factually know that they want to keep customers satisfied. And customers can be quite difficult to please. Let them know that we get that. When they felt understood, they will fight less and collaborate more.

Express ourselves.

Tell them our side of the story, namely, business outcomes, product vision, resources, technical constraints, etc. From our experience, Consulting and CS are usually grateful to learn what’s going on in our department. We don’t need brownie points, but we want to make sure our goals are well understood.

Be in the clarification zone.

Like staying in the problem space before developing any solution, in this case, take your time listening and asking questions, until both sides can efficiently and calmly talk about the customer’s problem, instead of letting unhelpful comments fly around. If you hear them say, “Thank you for listening”, or “Thanks for telling me all these things that we don’t know”, you can get ready to start digging into the customer problems.

After all, the Product Manager is a spider in a web, proactively building relationships with stakeholders is only going to make our work easier. Try to make them feel more than heard but involved, by interviewing them during the Idea Collection phase and looping them in the Delivery phase, offer progress information when we can, and when seeing them in the kitchen, grab a coffee and have a chat together.

Working with the Engineering Team

We have discussed working with Sales, Marketing, Customer Success, and Consulting. This one, working with the Engineering Team, might be more special. Product Managers and the Engineering Team are like Sherlock and Watson, whose complementary skills can crack any hairy case; like John Lennon and Paul McCartney, in different roles but rock the world playing in the same band; like Messi and Suarez, fulfilling their part in the game, then immediately looking for each other and scoring for FC Barcelona. To successfully deliver valuable products, we must work well with our Engineering Teams.

In a casual and humorous way, Software Engineers are often described as geeky, nerdy, and even quirky. Engineering Teams do often carry noticeable styles with them. In fact, depending on the culture (regional, company, and team cultures), the economic state of the business, and the company processes, Engineering Teams could show completely different styles. Since our goal is smooth collaboration, let’s focus on that.

Know their Craft

In the Product Manager’s Competency Assessment, we discussed knowing our craft, i.e., market, domain, product, and tools. To work smoothly with the Engineering Team, it’s helpful to develop knowledge of the engineering world. Respect their rituals. The Engineering Teams organize their work with many practices that we in Product Management wouldn’t need, such as Daily Stand-ups, Grooming, Retrospectives, Sprint naming, etc. Be it Agile or Waterfall, Kanban or Scrum, it takes good processes for a team of individual problem solvers to program for the same product at the same time. Learn about their ritual and participate or even host if appropriate. This is our path into the team.

Encourage Discussions

The moment we present any ticket, mock-up, or rough idea in any form to the Engineering Team, is the moment we put something up for discussion. The Product Manager is the one who offers a crystal clear context of the problem. It’s the Engineering Team that will solve the problem. Their inputs are not to be discounted. Once again, depending on various backgrounds, in many cases, if the Product Manager fully determines Acceptance Criteria and asks the Engineers to do as told, it’s the quickest way to discourage or even offend talented and motivated Engineers.

Value their Schedule

Engineers go deep into a problem, where they connect many dots, brainstorm feasibilities, and search for solution references. Disturbing this workflow can be rather counter-productive for all. When we need an ad hoc feasibility discussion, look for an opportunity in the upcoming scheduled meeting with them, or check with the Engineering team representative how to approach; increase ticket priority only when absolutely necessary, e.g., the customer cannot continue doing their jobs if we don’t fix the issue; shield the team off overwhelming requests from Sales, Consulting, CS and so on.

Be Part of the Team

Though Product Managers aren’t strictly part of an Engineering / Scrum / Agile / Development Team, experience says we work best with Engineers when they accept us as part of their team. There’s no hierarchy between us and the Engineers. Their goals and metrics, e.g., velocity, burndown, number of tickets done, etc. are barely similar to ours. But they rely on the information we provide to deliver the product. The quality of communication must be robust.

Don’t Stress Them or Yourself

We have hopefully all learned that it’s not smart to rush Engineers when they are thinking. Not only that, software development progress is based on priority, feature effort estimation, and staff capacity, all of which are changeable at any given moment. Accept and expect the fact that things will get delayed, some functionalities will not be realized, and mistakes will be made. The bigger picture is that there’s always an upcoming development cycle, and as long as we work smoothly with the Engineering team, problems will be solved.

Lastly, the most experienced Product Managers would face challenges when working with the Engineering teams. The newbies may collaborate with them magically due to passion and openness. Use every opportunity to learn and always be improving.

Further Reading

Product Strategy Canvas

Programmer- or Product Developer? Why The Difference Matters!

Reflections and findings triggered by the experience interview with Bas Vodde

Barry Overeem | Medium
Product Strategy Canvas

How Product Managers can Communicate Better with Developers

This guide is intended for product managers, it offers 10 tips on how to communicate better with developers — not (only) to make the developers happy, but mainly to provide value to customers in an efficient and sustainable way.

Felix Bauer | Medium