The Role of the Product Manager

Nigel Yeo, Phúc Nguyễn Khánh, Rory Madden at UXDX APAC. Video: https://youtu.be/80WqNXWpeQ0

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introductions and team structures

[00:00:00] Rory: We're going to be talking about the role of the product manager. I'll just ask Nigel and Phúc to give a very quick introduction. Nigel, we have been speaking to you, but if you can just give a very quick recap of your role, and then we'll be asking the same for Phúc, and then we'll get into some of the more details afterwards. Welcome.

[00:00:24] Nigel: Thanks, Rory. Hi Phúc, hi everyone on the meeting. My name is Nigel. I'm currently the chief of staff to the head of product at Xendit. Xendit is a Southeast Asian payments and financial infrastructure company that's looking to build digital infrastructure for Southeast Asia. It's a company headquartered in Indonesia. I've been a product manager since I joined Xendit, which is four years now. What I do in my role currently as chief of staff to the head of product is to effectively help the head of product do his job better, and the scope that covers would potentially take up this entire time. So I'll pass the time over to Phúc to introduce himself and his company.

[00:01:11] Rory: Thanks. I think you might be on mute.

[00:01:23] Phúc: I can unmute now. Thanks, guys. Hi, my name is Phúc. Thanks, Nigel, for the introduction. I work for Live Payments, a company in Australia founded in 2006. My company builds solutions for whatsapp [?], SME and taxi industries. We have an online solution and an in-store solution. I work as senior product owner for the online solution, where we offer a payment gateway for all the cards in Australia. My company has its head office in Australia. We also have offices in the Philippines and in Ho Chi Minh City in Vietnam, so I work remotely from Vietnam to support a product manager in Australia to deliver the solution for the Australian market.

[00:02:20] Rory: Excellent. I'll just dig into that a little bit more while you're mentioning it. Can you explain that structure? You're a product owner based in Vietnam, and then product management is based in Australia, is that correct?

[00:02:33] Phúc: Yes. The whole product management works based in Australia, because the market is there, the targeted customers, and the governance team. The IT team and myself are based in Vietnam.

[00:02:49] Rory: Great. And can you give me an indication of the scale of it? How many product managers are there, how many development teams are there, and how that structure works?

[00:03:01] Phúc: We have two product managers in Australia and we have four development teams in Vietnam. The product managers do the research work, product vision and product metrics in Australia, and we need to transfer that vision into the backlog for the four development teams in Vietnam. So my team will be in charge of the delivery.

[00:03:28] Rory: Excellent. And then Nigel, if we can jump back to your structure. I know you touched on it briefly in your last talk, but can you recap on what the product structure is within Xendit, particularly touching on the product managers, how many there are and how they're aligned?

[00:03:47] Nigel: Sure. Currently we've got about 70 to 80 product managers. By managers I just mean people working at the various levels of seniority in the PM role, so that can be anything from associate PMs, the most junior, to senior PMs, to product leads that are in charge of product groups. The way that the product function is structured at Xendit is we've got a head of product who is the ultimate owner and accountable for product at Xendit. Then we've got four product groups within the product org: payments, merchant experience, internal services and the fintech group. Each of these is headed by a product lead who is accountable for that domain.

[00:04:30] Within each of these product groups there are multiple product teams. Each of these product teams will have at least one PM. At times one PM could have a portfolio of multiple products, and most of the teams will have an APM also helping to staff the team and to help the PM work on various tasks. The product teams are not intentionally structured or organized around regions. Xendit has always been a remote-first company, even before the pandemic, so I was pretty used to working in t-shirts and shorts even before COVID hit us. In the way in which we hire PMs, yes, we do focus on the countries that we're operating in, but if there's good talent that we find has a culture fit with Xendit and has the right skill set, and they pass our hiring process, even if they're working in a place such as London or in the UK, we will do our best to make it work.

[00:05:35] Rory: Excellent. So is it quite a geographically diverse team then, or is the majority of people co-located and then a couple diverse?

[00:05:45] Nigel: The majority of people are co-located in places like Indonesia, the Philippines and Singapore. We have a couple in Malaysia. That's just the way in which, how do I put it, the majority of applicants come in from these countries, and whenever we find a fit we will of course want to bring them on. So it has turned out that most of the product employees are in these territories, but it's not intentionally so.

Marty Cagan's 60-hour week and what a PM is measured on

[00:06:17] Rory: Okay, excellent. Thanks for giving us that background on your structure, because I think that's going to be relevant as we go through the rest of the questions. Nigel, can I touch on one point? I'm going to bring up a quote from Marty Cagan, where he said in his book Inspired, which is often referred to as the bible for product management, that he can't see how a person can do all of the responsibilities of a product manager in less than 60 hours a week. He lists things like: they need to be talking to customers, managing relationships with internal stakeholders, preparing the vision for the products, tracking delivery, managing performance, looking at the market, all of these tasks. So what are the responsibilities of the product managers within Xendit, and how do you manage that overburden? Do you have ways of trying to lighten the load for people?

[00:07:19] Nigel: I think Marty, in Inspired, is listing out all of the various tasks that a PM will expect to encounter in their role as a PM. Of course we don't have the opportunity to press him in the book, and if he ever attends something like UXDX, maybe on a panel like this...

[00:07:42] Rory: We've had him before.

[00:07:45] Nigel: Yeah, I remember seeing that. But I think if we were to ask him, he would not say that many of these responsibilities, so to speak, are the core role and measure of success of a PM. Because if you're joining ten meetings a day, if you're talking to various stakeholder groups, if you're running your sprints, if you're putting in requirements, the list goes on and on, but you're not building a product that achieves the outcomes that your company and your team want to achieve, then in my view, and I believe in the view of a lot of Xendit product leaders, that PM would have failed. That's the measure of success at Xendit: as a product manager, are you building a product that customers want, and not only want, but they're willing to pay for it in some way, in a metric that is important to your business? That metric need not always be money. Of course money is the best, but sometimes it could be things like data, which your company might then use to earn revenues from other sources.

[00:08:51] So whatever metric is the most important for your team in the company, are you building products and improving your products and organizing your time in the best way to allow you to achieve that result? I think for any manager of a PM, if the answer to that question is yes, it's hard for them to say that that PM is underperforming, even if, for example, other people say, "Hey, they're not really responsive on Slack, they did not fill in this particular document correctly or on time." The question is: did they build a product, were they instrumental in driving and building this product, and was that product used by customers, which then grew important metrics for the company? If the answer is yes to all these, then I think they've done a good job. If a company does expect a PM to do that plus do all the other responsibilities 100%, then yes, I think they're overburdening that PM, and I think any company that seeks to do that should probably rethink that approach.

[00:09:52] Rory: Just playing a bit of devil's advocate, Marty's point was that you need to do those activities in order to get the outcome. So is there anything that your company does? I know some companies have maybe a product ops, research ops, design ops, those kinds of functions that can alleviate some of the burden, because then the product manager doesn't need to do all of those activities. Is that something that Xendit has to help?

[00:10:27] Nigel: Yes, we do, but not by default. We don't have, say, a policy whereby we think every single product team needs to have at least one designer, one researcher, one UX writer, one ops person, one marketer attached to each of these teams. Of course it's unrealistic to have one unique person in every team, but it's not even the case that we necessarily think that every team should have someone assigned and have that person's time split amongst these additional product teams. Because having such a policy by default would essentially be saying, "I'm going to apply a solution before I even figure out what the problem is." Not every PM requires those types of support at every stage. It does depend on the phase of the product, it depends on the maturity of the product. For example, if it's an experimental product that the PM is looking to put in front of customers to get their feedback and see if it's something that can drive growth, and if the answer is no they will not continue with it, then having a whole bunch of additional staff attached to them right from the start might turn out to be not that good a use of resources. So the answer is yes, but it's case by case.

Splitting product manager and product owner across Australia and Vietnam

[00:11:43] Rory: Excellent, thanks for that. I'm going to jump over now to you, Phúc, because you explained during your introduction that you have a separation of responsibilities. Can you dive a bit deeper there, in terms of what I was saying about talking to customers, understanding the problem, setting the vision, managing the delivery? Where is the boundary, and how do you work between the PMs in Australia and the product owners in Vietnam?

[00:12:14] Phúc: That is a very good question. At the beginning, when a team sees a product manager and product owners, the first question is who does what. Some may say, like the example you gave, the PM has to know everything, from the research to the delivery. In my company's structure, I would like to share, product managers would be in charge of product strategy, with four pillars. Number one is the product vision and mission. Number two is the persona, meaning the targeted customer. Number three is the product metric, and number four is the product roadmap. What is this? I will tell you a bit later.

[00:13:02] What is the product owner's role? Product owners focus mainly on one thing, that is delivery, with five pillars. Number one is the product backlog, number two is design experiments, number three is the feature roadmap, number four is release planning, and number five is making sure the methodology is agile delivery. So those are the five for product owners. You will see there's some crossover, which is the product roadmap and the feature roadmap. The product roadmap means anything large, more than three months, or maybe sometimes six-month work, should be in the product roadmap, to make sure that whatever we deliver will follow the company's vision. For product owners... sorry.

[00:13:54] Rory: I'm just going to jump in there, I just want to thank you. Just to let the audience know, you're recovering from COVID at the moment. Thank you for joining us today, because I know during the last week you haven't been feeling very well.

[00:14:09] Phúc: Actually, I'm still staying in hospital now. I'm planning to go out of the hospital tomorrow.

[00:14:19] Rory: Okay.

[00:14:23] Phúc: To make the team know all the product visions, product owners and product managers work back to back in sprints and iterations. The product roadmap will be shared from the product manager to the product owner. The PO will work as a proxy for the PM to share the customers' needs and market needs and the north star metric that we are targeting.

Managing the risk of miscommunication

[00:14:55] Rory: Excellent. One of the challenges with that split model of the product manager and the product owner is that there could be the risk of miscommunication, or maybe not even miscommunication but missing the context. If the product manager is talking to the customers, then there might be a gap between what the product owner understands and how they translate that into the short-term delivery, as you highlighted. So how do you manage that risk of miscommunication?

[00:15:29] Phúc: That's correct. Of course we stay in Vietnam and someone else stays in Australia. Number one is we have a different time zone, so the way we think about it is very different. In Vietnam we never care about the differences in time zone, because Vietnam has only one time zone. But in Australia everyone knows that there are three time zones, and whatever you do, you have to handle different time zones for different customers, for example. Someone who doesn't realize that gap, we encountered that miscommunication. The next thing we did is the retrospective session, and we found the gap is market understanding. So we decided that before we do anything, we give broader context than normal. It takes more time to do.

[00:16:25] If everyone stays in the same country, you know the country, you know the market, everything. But if you are not in that country, number one, you have to say what is the legal requirement, what is the context of the market. Things like that take a lot of time if you spend the whole time sharing with the whole team. So the product owner should be the one who overcomes the obstacle of the culture and market. He or she should be the one who learns about the market from the product manager, and when you talk with the team, it saves a lot of time, rather than everyone having to learn about a whole new culture and market.

[00:17:11] Rory: Do you have any examples of areas where that miscommunication arose, and how you solved it?

[00:17:20] Phúc: Time zone is one of the requirements. Other things are like legal requirements. For example, in Australia the financial year starts in the middle of the year, meaning July 1st, but in Vietnam it's January 1st. Things like that should be translated from Australia to the team in a sharing session: "This is the structure, what is the tax law, what is the practice of the market, what is the customer base, and even what is the competitors' practice," for example. Without knowing that context, we would divert the delivery into other outcomes that don't fit the targeted market.

[00:18:10] Rory: Excellent.

[00:18:11] Phúc: So sharing is the key.

Keeping 70 to 80 PMs aligned

[00:18:16] Rory: Brilliant. Nigel, do you have any issues with that? There was a definite transfer of knowledge there in Phúc's case. But do you have an issue, because, as you were saying, you've got 70 to 80 product managers all working on different areas? How do you ensure that there's cross-alignment between those different areas and there are no gaps, things that fall through the cracks?

[00:18:42] Nigel: I think we can't ensure 100% that there are no gaps. What we do is a mixture of processes, education and training. We invest quite a bit into our managers of PMs, so senior PMs and product leads, and they are expected to pass on these types of good disciplines and good habits to the junior PMs, in terms of the cadence, the regularity and frequency, as well as the content of the information that they are sharing or that they're requesting. One example is many senior PMs will always remind juniors, and in fact not just PMs but staff in other functions, to not isolate information in direct messages and to keep communications in public channels, unless it's confidential or sensitive.

[00:19:43] Oftentimes people just send a DM because maybe they are less confident about the question. They don't want to be embarrassed for seeming to not know something in a public channel. But we very much encourage asking in public channels instead of closed direct messages, and we tell them that there is no shame, there's no penalty or anything like that, if you're just asking about something that you do not know. That's one example.

Async by documentation instead of meetings

[00:20:12] In terms of processes that we put in, as much as possible we record everything, and that's why we favor async communication, asynchronous by documentation, instead of calling a meeting for everything. One, it saves people time. I think one of the biggest crimes for workers, especially in a remote environment, is being invited to meetings where you don't actually need to be there. Then you're probably just spending the time either working and not paying attention, and then being surprised when someone calls on you and says, "Hey, what do you think about this?" and you've not been paying attention. Or you just spend the entire time quiet and you don't contribute at all, but it was still a use of 30 minutes of your time.

[00:20:55] What we do is we record everything. Before meetings are called, we always emphasize that there should be a doc circulated to discuss the issue at hand or the proposal or anything like that, and people should be given time to read that first and add their comments or questions. If there are enough people who believe that a meeting is necessary, and this is most often the person who initiates the doc, then and only then would they call it, getting the key people who they need to resolve some outstanding issue with on that call. The other people, who might have no comments or might say, "This looks good to me, I have no further questions, I know what you want me to do," don't even need to join the call. It's just a couple of people who still have certain things that they want to iron out, or maybe some decisions need to be made. That's another way in which we try to mitigate things from falling through the cracks.

[00:21:46] Another example I can think of, which also makes use of documentation: when we've got a large organization, it's difficult for people to really identify and narrow down who they should be approaching for what purpose and what each of these people are doing. We use documentation for that as well, where when someone asks about this, we can point to a clear resource that identifies all of this and puts it down on paper, or rather on the screen. They can refer to that first, and if it's still unclear, then number one, we have an opportunity to help them, and number two, that's feedback on the doc that we can use to make the doc even clearer.

[00:22:22] Related to all of that, something that my manager, the head of product, taught me, which I now make a request of everyone, is when we are giving instructions or requests to people, it's like an idiot-proof approach. We break it down into extremely easy-to-follow step-by-step instructions, and assuming that we have the time, we even create templates of the documentation that we're asking people to complete. For example, if we wanted to say, "Hey, we want all PMs to start to write a certain template for sales," or some other thing like that, we provide it first and we make it idiot-proof. It's not to say that we think our PMs are dumb, that's not what we mean. But essentially, as someone reading this, I can just mechanically execute it without having to ask you, the requester, any further questions in order to do what I'm doing. Because we recognize that when we make requests such as this, it takes up their time, attention and bandwidth.

[00:23:18] Rory: Excellent. I'm a big fan of those async comms, but one of the challenges that I've personally faced is that you send out the documents, and because people are busy and up to other things, you're just not seeing comments come back. You can't always just assume that they don't have any feedback. It's more that they haven't reviewed it at all. So how do you balance that? Because then you end up going back to a meeting to try to get their time and attention.

[00:23:47] Nigel: If we want to avoid a meeting at all costs, then what I find has worked out for me is directly messaging those people. Because in a thread they're more likely to think, "Maybe I'm not that important, it's fine, other people can give their comments and I don't need to." Sometimes that's true, because sometimes we want to be inclusive, we want people to give their buy-in on things that we ask them to do. But if their personality or their working style is, "Thanks for being nice about that, but I don't really need it," then we're happy to say, "Okay, we've given you the opportunity to comment or give your input. You don't think it's necessary; that works for us."

[00:24:31] But if it's someone who's just really busy, but they are an important stakeholder, then I find that just being naggy, and not thinking that you're being naggy, but just holding true to the belief that you're doing this for the good of the company, and of course not doing it in a pushy or aggressive way. You say, "Hey, we really need your input on this because of reasons XYZ. Can you please find some time to give us your comments?" And if they really can't do it async, then at that point in time, some people live by their calendar. For some people, you drop a meeting into the calendar and they'll be like, "Oh, okay," then they'll pop in and say, "Hey, what do you want me for?" and they will give you the attention that you need. So it really is about what works best for individual people.

[00:25:17] Of course, having to DM lots of people is not the most scalable system. That's what I mean by you have to prioritize between the people who you absolutely need input as well as decision-making from, and the rest of the people who, if they just don't want to comment despite being given the chance to, and if you make the call that it is not critical, then that could potentially be raised as feedback to the managers, to say, "Hey, this person isn't really the type that will respond to various things async. That could be a problem in the future. It's not really a problem right now, but as they grow in the company they will be needed for more things, so maybe we can talk about that."

[00:26:05] Rory: Brilliant. Phúc, do you have anything similar? I like that example of async documentation over meetings. You did mention that one way that you try to solve it is through retrospectives, through daily stand-ups, getting a lot more collaboration. Do you have anything similar in terms of more of a written approach, or how do you try to scale that communication?

[00:26:30] Phúc: Thanks. All the activities that Nigel shared, like recording meetings, are important. For example, the sprint review is very important. I want everyone there, because this is a new product, everyone should be aware and everyone should know how it works. Otherwise we have to go one by one and explain how to use the new product. So recording the meeting is a very good way to deliver the material that people can later see. The other thing is the retrospective sessions. It's held every week, and we use a Miro board to record everyone. What we document is agreed action items, and on the next Monday I put some of the action items into the sprint planning, to make sure that everything we conclude from the retrospective session goes into action. It doesn't just stop there just to please anyone; it should be in action. So we have a place to document the retrospective actions.

Challenges they are working on now

[00:27:37] Rory: Excellent. We're almost out of time, but what we've been talking about is the different structures, the different ways that they're working, the challenges of miscommunication. What other challenges are you facing right now with your structure that you're actively working on, that maybe could be useful, like some of the techniques that you're trying that might be useful for somebody watching? I'll start with you, Phúc.

[00:28:04] Phúc: One of the issues I got in my new company is there are too many Slack channels. People think, when they want to chat with one, two or three people, "I'll open a new channel to chat." So reducing those channels is very critical. Now we know that email doesn't work anymore; everyone is too busy. So for all my companies, we seldom send email. When we send email, it's for items where it's important to send an email; everything else will reach you in Slack, by DM or in some channel for the project. Because with email, you should read it, and it's easy to know you're in the CC. But in Slack you're notified immediately if you're mentioned by name, or it's just for information. So typically we use Slack for all the communications, and anything important will be documented in email. So email is like a storage.

[00:29:15] Rory: That's a brilliant example of the more real-time versus the more archival information. But the Slack overload is a definite problem.

[00:29:26] Phúc: We have some rules too. Whenever you want to create a new Slack channel, there should be an outage issue or something. Even for the outage issues we have a channel for that. So we have some rules to try to not create so many Slack channels, otherwise we'll be flooded with so much information.

[00:29:52] Rory: Brilliant. And just to finish up then with you, Nigel, on a similar point: is there anything that you're actively working on right now for some of the pain points that are emerging as you keep evolving and changing your structure, that might be useful for other people?

[00:30:09] Nigel: One thing that we are working on now that could be useful to staff in other companies that might be experiencing hypergrowth stages, where not only your teams but various functions are enlarging, on the product side, would be your roadmap. I think the roadmap, in terms of its friendliness to other orgs, may be ignored. You don't want to leave your roadmap in a state where it gets to a point that other functions feel extreme pain, lots of pain points, before they raise it to you and you start to improve it. That is something that we're looking to actively improve now. I think the roadmap is a great way of facilitating communication between product and other organizations about what releases you have planned, what you need from various teams, what launches you have going out, all that sort of stuff. That's one thing that I would recommend product leaders start thinking about. Even if your roadmap is really great and meeting all those needs, it doesn't hurt to periodically check in on it from time to time, get some feedback from other stakeholders and think, "Hey, how could we improve this for you?"

[00:31:35] Rory: I love that example. I could dig into roadmaps for a whole other conversation, but it is great to think about the roadmap as a product. What are the consumers, the customers of that product, and is it fulfilling their needs? Exactly, because it's often more external value than internal. But that's all we have time for today. As I said, I could go on for a long chat about roadmaps and different styles and pros and cons, but unfortunately we don't have time to get into it. Thank you, Nigel and Phúc, for joining us and sharing your thoughts today.

[00:32:10] Nigel: No worries, thanks for the invite. Take care.

[00:32:12] Rory: Thanks, everyone. Thank you.