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.
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.
One reason that numerous product management discussions cover the Sales aspect is that working with Sales seems quite “tough”:
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.
Thank you for your time today to help me understand the problem…
What does the customer want to do?
Why?
Why can’t they do that on our platform?
How do they currently do it?
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.
So the problem is that the customers usually have data in format A but we only allow uploading in format B?
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.
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:
With this in mind, collaborating with Marketing should be plain sailing. However, there can still be pitfalls:
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
Reflections and findings triggered by the experience interview with Bas Vodde
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.
