How to work with Product Managers
For departments such as sales, marketing, customer service,etc.
Product Managers (PMs) are generally required to work with cross-functional teams. That means the basic requirements for a PM is to know how other teams function. The reverse, however, is sadly rarely the case.
Working closely with PMs is a great way to learn about the job. But there are caveats, and hidden side to the role that might not be so apparent. Let’s explore ways departments like sales, marketing, customer service could help with improving the product along side development teams.
PMs always need data. Help them out.
Data-driven decision making is almost the default nowadays for most professions, Product Management is no exception.
To a lot of product teams, gathering high quality users’ feedback can be a daunting and costly task. Sure, you have several free tools to collect feedback directly from your product. But when it comes to deep diving into users’ usage and habits, more elaborated interview and observations are required. These days, the pandemic is not making this part of the job any easier.
Product-driven companies spend generously on focus group and other UX research activities, because the investment in UX improvement is likely proportional to revenue (read more about how companies should spend on UX research here).
Be ready to offer help asking the users or clients about their experience using the product. Sales and Customer Services are two departments that have most access to the user pools, in most companies, more so than the product team. Here’s some simple questions that PMs often use in User research:
“What was the (first) experience using this new product/feature?”
“Which tasks did you use our product for on daily basis?”
“Is there any other product in the market that you would consider/you feel is similar to our product?”
Or more useful questions that can help with user research here.
Get the answers in any form you can, then give them straight to the product teams, no filter. Part of their jobs is read between the line and pick out the ideas that will be turned into meaningful features/improvements for the users.
At my company, sales teams are nice enough to periodically send us a list of feedbacks from their key accounts. While many of them have little to nothing to do with the product itself, quite a lot of them were turned into useful features and improvements that really helped with the metrics and sales figures.
Don’t be upset when they say “No” to you. It’s their job to say no, frequently.
Each of us has a group of people or clients we want to make happy. PMs do too, only their groups are much much bigger. The whole user base, actually. While the feedback you may get from your clients can potentially become the most valuable there is, it’s most likely that there are more than just yours. Again, PMs receive a lot of noises daily and good PMs will have to pick the best ideas out of all the noises.
“But you just told me to give them more data and feedback. Doesn’t that mean they can serve my clients better?”, I hear you ask.
Yes, by having your contribution, they will have more chances of successfully discover an idea that will eventually make your clients happy. But it would be such a dystopia if all requests are heard and new features are churned out in matter of days instead of weeks or months. While in fact, most development teams are merely 15 people of various roles. You have PMs, business analysts, developers, quality controllers, UI designers and newer roles that are invented in recent years like UX researcher or UX writer. That’s why there are Product Backlogs, that are literally ordered lists of what product teams will develop first, second, and so on, to the least important task. And who makes that order? The PMs, of course.
Here’s a list of comprehensive reasons why your PMs say no to you sometimes:
Or an excellent medium article on why and how PMs say no:
But even when they say no, PMs value every feedback they receive. After all, that’s the most direct and immediate response they could get about their work from the most important people they have to serve. Saying no to those who just helped them with getting data seems a bit ungrateful, but good PMs know that diverting from a Product Vision ,that is already well-researched and thought out, is even more dangerous. And most of the time, a good PM would spend their time to make sure they have a convincing reason to explain for saying no to requests from stakeholders.
Know what a Sprint is, and when it’s best to make some request to quickly get what you want.
Say, you go to work every day, and set out to answer all unread emails in 1 hour. A sprint is like that 1 hour, but typically lasts 1 to 2 weeks for a development team to get something done.
A sprint isn’t something that’s just starts and ends. It needs reviewing and planning. So development team will have to sit down and take a good look at what they’ve done, as well as what to do next. Ask your PM when the current sprint will end and how long a sprint is. Heck, ask if they could share a schedule of some sorts that will show you when the next sprint planning will be.
Most PMs might give constant release window updates (me included). Don’t hesitate to ask about the details of the sprint, they are more than happy to let you know. Don’t be held back by the fact that your requests might be too vague or you don’t have all the details yet . Instead, focus on getting a good window of time that you can voice your requests, so that the PM will see it and have enough time to do some research or work with you directly to understand the requests better. And it’s very likely that the PM will find out that it’s critical to work on your requests ASAP.
Leave the decision of what to prioritise to them, but let them know before the Sprint planning to have more chance of getting things developed quickly.
Know the Product Vision.
A product vision is a statement like this (1 sample, there are variations):
For [our target customer], who [customer’s need], the [product] is a [product category or description] that [unique benefits and selling points].
Unlike [competitors or current methods], our product [main differentiators].
You can read more about it here:
As you can see, the product vision includes the information that can sell the product. It’s even more important that everyone is informed and reminded about the product vision. If you never heard of it from your PMs, ask them to tell you.
Why do you need to know this? Because it is the general objective of the product teams and their stakeholders (you included, whoever you are). It is what your company is striving towards. It is the key selling point of the product and it gives a hint of what the product will grow into.
Why is it important that you know it even though you don’t directly work on the product itself? Because knowing this vision by heart, you can help the PMs do another round of filtering the noises from clients or users. You can at least distinguish what sort of requests will or will not fit into the company’s vision. Don’t just be a messenger, be a product seller.
Working with Product Managers shouldn’t be so intimidating. Your voice matters, and PMs are generally reasonable people who love to make others happy. So give them data but give them challenges, too. They are there to support and understand, and to make your job a bit easier.
