It was a pleasure to have Andre on the Product Comms Series today and I am excited to share with you what we’ve discussed.
He shares stories and learnings of what he has experienced at Glovo & Kitch and what he is now teaching at OneMonthPM.
Here are the key learnings of our chat:
✅ Everybody is a product manager: Emphasize a product-centric mindset across all roles, not just product managers, to enhance team communication and understanding of product objectives.
✅ Decentralized Communication: Foster direct communication within teams to speed up decision-making and avoid delays caused by information silos.
✅ In-depth Team Knowledge: Ensure all team members have a comprehensive understanding of the product to improve the quality of communication to leadership and facilitate informed decisions.
✅ Tailored Stakeholder Engagement: Recognize and address the varying needs of stakeholders by customizing how product roadmaps and updates are presented to improve engagement and understanding.
✅ Adaptive Information Packaging: Use different formats and levels of detail in product documentation to meet the specific requirements of different audiences within the organization, ensuring clarity and effective communication.
Andre (00:19)
Yeah, sure. So my name is Andre. I've been a product manager for quite a while.
Currently, I'm leading a company called One Month PM. So this is a product management school. We teach and help people become better product managers, become product builders, help people going to head of product roles. Before One Month PM, I was leading product at Kitsch.
I was VP of product. I was leading the areas of product design, research, and co-leading engineering. And basically we built a food tech company. We sold the company to Glovo, which then sold to Delivery Hero.
And yeah, kind of my story has been building product from the ground up, very much zero to one, scaling it to about 50, 100, 300 people. Yeah, that's, that's kind of the background.
Jack (01:04)****super fascinating journey, I think, and a lot of learnings from there. Um, I'd love to zoom in on two areas, but I think first we're going to talk a little bit about, you know, leading product and then having those PMs that report to you, uh, there's a lot of, of course of communication that goes on between there, right? So PMs updating you as, as they're kind of stakeholder. Um, so maybe we can focus on that first and great if you can tell us a bit of a story about where that didn't work, uh, you know, one time and we can kind of dive into that.
experience that you had briefly.
Andre (01:36)
Yeah, I think often the times more than once that the communication between product and someone leading product and work is when there's a bit of a silo between the knowledge and the role of the PM within the product and engineering and design group. And the information that gets to me is just scratching the surface. It's missing out on a lot of details. It's missing out on the things that are actually preventing stuff from going faster, from being shipped, from having high quality, from increasing the likelihood of being adopted by customers.
But I realized it was actually more a mindset and attitude problem, the way that product, as well as engineering design, saw their roles. I usually say like, I'm very much against the product owner role, because I believe that in the best product teams, everyone's a product owner, everyone acts like a product owner. A small thing we did at Kitsch was we changed everyone's titles. Actually, we recruited this way to be product first and then whatever your hard skills.
Second, we have product managers, product designers, product engineers, product researchers. So it's just, this was just a tiny detail that made people understand that they're a product before whatever they do. And once we started getting people into this mindset, then everyone could actually communicate the product status, the progress, the blockers, the vision, like everything that product really needs to know the same way instead of just being siloed in the PM. And I think that is, for example, one situation because I truly believe most companies, they slow down because of communication flows, right?
Small teams move faster because they have less communication flows. They can communicate faster. You can update an entire three, four people team in literally five minutes or 10 minutes. You can't do that with 10 people team, 20 people team, 30 people team. So I think the mindset, the attitude here is something that, looking back, it was a problem that we solved.
and just make communication flow, you could just decentralize decision making. If someone was out, I could rely on tech lead engineering leadership or design leadership to be able to take the mantle and communicate and deal with a lot of product to myself or leadership or stakeholder communication, decentralized instead of just siloing into the same person.
Jack (04:09)That's fascinating. I haven't really heard it kind of framed like that of everyone having this product, product part, and then product engineering, product design, uh, product manager, et cetera. That obviously makes a lot of sense that they were then more focused on the product itself, but how did that then extend to actually helping the communication? Was it that they were deeper on knowing the status of where they were at with kind of product development or what was the kind of key change that enabled them beyond, of course, just changing the title there?
Andre (04:39)Yeah, so, I think in the end of the day communication is all about what you're trying to convey so that it leads to action, right? If the things you're conveying are missing a lot of details, technical details, information, customer details, then the quality of your actions or your reactions to that communication is going to come down.
So whenever I got PMs telling me what I need to know in order to inform leadership, the board, the CEO, there was a big difference between them actually knowing the details able to actually convey the right message, actually package the right details for me to be able to act the right way, versus them not knowing everything, them not actually being on the turpentine and actually knowing what is blocking, what are the key problems, what things I should definitely know that will make the difference.
So I would say like the change into this product owner mindset across the team allowed everyone to be way more informed, to be able to communicate better to me so that I could actually do my job better.
Jack (05:40)Super interesting. I think also because of course, you know, I've been in those organizations where even for one engineer to talk to another engineer in another team, it has to go like engineer PM across to the PM to the engineer again, and it's just so of course, you know, with all of those steps, like that's three steps, right? So much gets lost in translation. You know, it's super inefficient. Yeah.
Andre (05:58)Yeah, and it slows down. It slows everything down. You're just depending on someone to say something to someone else who needs to get information to make a decision. I mean, in the end of the day, speed cures everything, right?
If you're fast at building, fast at deciding, fast at reacting, you're probably gonna outpace your competition, you're gonna ship faster, and customers, we're more demanding than ever. We want the bang for the buck, and the teams that ship faster and solve our problems quicker, they're the ones who win.
Jack (06:29)Yeah, absolutely. I think it spoke one of the things. I mean, we are very small still 16 people, but we really try and get, you know, really get people talking to each other without me being involved. You know, I'm in, I'm in a million places at once and we don't have any PMs in our team, only, only me as the kind of CPO, but like our two designers do a brilliant job of, of essentially, you know, product work, right? They're pushing projects forward. They're making things happen by speaking to data, by speaking to backend, by speaking to front end and coordinating all of those pieces together. I want to get out of the way as much as possible and not be that bottleneck. Having been that bottleneck way too many times in the past, it's very inefficient.
Andre (07:04)Exactly.
Yeah, 100%.
Jack (07:12)Cool. That was one story, of course, around, you know, product kind of up to you as a product leader. But I'm sure you've had a lot of interactions with, you know, other C level folks, senior stakeholders, less senior stakeholders. Tell me a story about, you know, where that's broken down or a learning that you really have in that area.
Andre (07:35)Yeah, so I think every product manager has kind of stories from hell dealing with stakeholders. I think maybe the thing that resonates with the most people is that, I don't know if it resonates with you, but I feel like stakeholders, they never read the roadmaps. Product teams, they put so much effort into, whether it's building decks, writing memos, creating great docs, great documentation about their plans, whether that's a monthly plan, a semestral plan, a quarterly plan, you think, wow, everything that people need is here.
Like I've collected data from customers, data from stakeholder interviews, the weekly syncs or the monthly syncs, I got data from leadership. Then you package everything in a beautiful way. And we did that and we kind of presented, sent to people, asked them to read it, and they just don't. And then the team gets frustrated.
My team come to me and say, Stakeholder is asking for this and this is on the roadmap. It clearly shows they didn't read it. Like there's no professionalism here. What the hell am I doing? Like what's wrong? And then stakeholders, the problem is, when you talk with them, they say, yeah, but like there's a bunch of stuff in this roadmap that I don't understand. I just need this.
And maybe this is there, but potentially it's written a different way because you talk with, you the stakeholder, you talk to customers or you deal with the operation. Like you think about solutions or features your own way doesn't need to be the way that product or engineering thinks about the solutions. And with all the noise, they don't see the signal, therefore, they're not going to waste time, they just want that one tiny thing, they don't care if the platform needs to be built, if there's refactors, if there's a bunch of bugs, or if there's dependencies to make your solution a reality.
So that creates a lot of frustration. I dealt with that situation so often. It's not just like typical stakeholders like middle management, C level CEO, sometimes like you'd wonder like, CEO is going to read everything, but keep in mind, CEOs are crunched all the time. They have time for TLDRs. They don't have time for 10, 20 page decks or like long memos, like people really enjoy the Amazon way, I'm a big fan of writing, like big writing. So I think that is a very, very common situation.
Happened to me a hundred times, it leads to frustration, even myself, even me knowing this, being aware of this, like it leads to frustration because you just want people to care about your planning, which is a lot of what product managers do, is like planning. And when they don't, it feels like they're not, respecting the role and why we exist but then when things go wrong like it's up to us to solve it right so yeah I think that's a situation that happened to me a hundred times
Jack (10:23)Yeah, I've definitely had that experience, right? And I think one of the big challenges is you try and go super detailed. You write something that, you know, you think is sort of self-explanatory, but often it's maybe not in the language of the recipient, you know, whether that's, if the recipient is another engineering team, then maybe they really need to understand which microservice are you changing? What's the scope of that changes? What's the downstream dependency? Whereas the CEO wants to know, is this feature?
That maybe is their pet feature or they promised to an investor is that thing going live. Like that kind of information packaging is so different, I think. So a part of it is also about understanding who's consuming what you're doing or what you're putting out and why. But the other part is just getting them to read it. And I hear all the time from people like, you know, we prepare documents or we record looms but no one watches them or everything's in product board.
How did you guys get that? Get around that? How did you actually improve it? Because I've never heard someone really come up with a like, you know, we did this and everyone read it. What's your solution there?
Andre (11:28)Yeah, so first of all, I think it's important to make the teams aware of why this happens. And I typically said like, look, the biggest reason is people are misaligned. But often people think about misalignment as in, oh, we want something and you want something else. I actually think there's a different type of misalignment. It's more of an asymmetry. It's like there's an asymmetry of vision and an asymmetry of shouting. Like the asymmetry of vision is, look.
Product folks or engineering, they see things others don't because they have technical knowledge. They understand what is possible, so they envision what they can build that others don't. So sometimes, stakeholders' view of the solution space is very limited because they don't have full understanding of what can be done. So that's an asymmetry. So the way you plan, the way you package, the way you communicate is very different from the way stakeholders are thinking. But stakeholders also have an asymmetry that product folks don't have, which is an asymmetry of shouting.
And that means they're the ones who get shouted by customers. They're the ones who have to deal with the calls. They're the ones who are hearing the nose because the product they're trying to offer isn't cutting, isn't good enough. And typically the product folks say we don't hear that on the day to day, at least not so much as the stakeholders themselves. And I think this misalignment kind of leads to conflict because people they control and they care and they're impacted by different things. So I think first of all making people aware of this is really important. I think it's also to make people aware that... uh... look...
There's a bit of a boy who cried wolf on the product side, meaning like, oh, yeah, we build this, we want this, but then stakeholders, they do nothing with it. Like, oh, we worked super hard, we shipped it, here it is, you said you needed this for yesterday, and now it's live and nothing's happening, no one's using it, you're not being able to sell. It's a bit of a boy who cried wolf, so it makes product folks a bit more skeptical. But at the same time, there's something else that happens on the other side, which is kind of empty promises.
Oh, the product team said they're gonna ship this, this and they never ship it. So the stakeholders stop being able to depend on the product teams. And again, it leads to misalignment, leads to a bit of an asymmetry. And I think making people aware of this situation, I think it's kind of step one. And then step two, a couple of strategies. Number one, I think turning people from foes to allies is really important. Like getting the bonding, getting people talking.
I think it just upgrades or improves the empathy. Number two, it's like, it's important to adjust the communication to the audience. It's like, oh yeah, it's very efficient to just write a memo, but you're not gonna be effective because if no one reads the memo, then you're not being effective with your communication. So I try to make people more effective over efficient. Like if you have to turn a roadmap into a 10 page deck, which works for leadership, a five page deck, which works for sales, a memo, which works for engineering and a TLDR, which works for the CEO, then you do all four, because you want to be effective in your communication.
So I think it's a bit of mindset. And then it's tools, right? Like, I mean, people say, look, talent doesn't need the best sneakers to run faster. But if talent has better sneakers, they'll run even faster. So if you use the tools correctly, if you adapt your situation, if you train people over how to use them effectively, then yeah, things get better. So this is kind of how we resolved it.
.webp)
.webp)
