Building a Unified Team In Unprecedented Times

Kax Uson at UXDX Community: Barcelona. Video: https://www.youtube.com/watch?v=xZbD6KkLVeM

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.

Introduction and the product manager meme

[00:00:00] My name is Kax. I'm from the Philippines, and I moved to Barcelona five years ago and forgot to go home, so I'm still here in Barcelona. I am a product manager by profession with over five years of experience, and on the side, after work, I also do product management mentoring and coaching for both new product people and product teams. I also have a community called Career Hacking for Women, which I started with two other friends. We're based here in Barcelona, but we're doing workshops online, so we actually have a pretty big community now, with people showing up from Singapore to Toronto depending on the time of the workshop and who's awake. And sometimes I also like to show off my non-existent singing skills in karaoke. That's pretty much me.

[00:01:00] I first wanted to show this image, which I'm pretty sure a lot of you have seen at this point. A few months ago I saw this image circulating on LinkedIn, and normally I would have laughed along with the other people who reacted to this post. But it was shared by an academy teaching a product management course, and there were a lot of people saying, "Oh, this is so true. I actually spend 24 hours doing product management and I do every single thing." Instead, I found it problematic. I wanted to laugh, but I was like, "Nope, this is wrong."

[00:01:45] I found it problematic because of a couple of things. First, I think it romanticizes overworking, and it glorifies the practice of putting everything on the product manager's plate. In that sense, it also encourages gatekeeping on the product manager's side. I think it undervalues the contribution of other people in the organization or in the team, and it completely underestimates the importance of collaboration, what other people can contribute, and how people can help each other out when it comes to building great products.

[00:02:33] You're probably thinking at this point, "Kax, it's a meme. It's supposed to be funny. Loosen up, have a bit of humor." I would, but it actually reflects the reality for a lot of us, and why we don't have the time to sit down and think about the things we're supposed to think about, like strategy. I've had so many conversations with new product managers, for example, feeling overwhelmed day in and day out, and thinking that they're not really doing the job they're supposed to be doing, because there are a lot of small things that keep falling on their lap. When will they have time to think about strategy or the roadmap, even if we go simpler? Like all real problems, I think this is a problem that deserves to be solved, for the sake of all of us product teams out there.

[00:03:30] Today, or tonight, depending on what time you are watching, I wanted to share with you that this meme doesn't have to be true. There are other ways of working that leverage involving other people in your own team in the tasks that used to be labeled as product things, like managing stakeholders or PRs, even writing PRDs and Jira tickets, like we have done in our team. We're still doing it, because we're constantly testing. We're constantly trying to improve the ways we're working.

[00:04:05] Today I want to walk you through the problems that made us decide to change the way we work, the solutions we have tested and are still testing, and the impact these changes have made on our team. Just in case you're facing the same problem in your own product team, you might want to start having a conversation with the rest of them on how you can change things, so that you have time to define a product strategy, which we all know is a very important thing, have a nicely curated backlog for everybody, and also provide opportunities for growth for everybody else in your team that might not be so obvious from the very beginning.

How my role expanded

[00:04:57] I work in a company called Adevinta. We do marketplaces, and I'm part of a central tribe within the company where we build products to be used in the marketplaces you're seeing right now, which is pretty much 12 countries worldwide. When this year started, our tribe started expanding our ambitions and wanted to provide more value to the marketplaces we work with and the users that they have. In the middle of all of this expansion, my role as product manager also expanded, from being the product manager of a team to becoming the product lead of a domain. That pretty much meant more meetings, more work streams and a whole lot more expectations.

[00:05:55] Boom. But I still had to remain the product manager of the product team I was part of, which meant I still had my old responsibilities and accountabilities as their product manager on top of the new ones I had as the product lead of a domain. Unfortunately, getting another product manager to replace me in the team was not an option, or at least it's not yet an option.

[00:06:23] On top of all of this, my seniority and my years in the company put me in a position where I'm also doing other things outside of my team. For example, hiring: I'm part of the hiring committee. I'm also mentoring junior PMs in the company. Sometimes I'm pulled into different workshops, et cetera. Having all of these things on my plate had a huge impact on my workload. The impact was starting to show, apart from the obvious "when am I allowed to have lunch", in small things like emails and Slack messages that would take time for me to respond to, or overlapping things in my calendar. It was starting to become obvious that we needed to offload me before I became a bottleneck to the team, or before I became completely ineffective in my new mission.

Distributing accountabilities

[00:07:31] So how did we do that? How did we make things better for this little problem of me? I'm the problem. Huge disclaimer: these are not solutions we just applied from one day to the next. These are things we were putting in place and testing over time. First, we looked at distributing our accountabilities. We looked at distributing our responsibilities. And lastly, we challenged product norms. What do they mean?

[00:08:01] First, distributing accountabilities. When we were forming our team in the beginning, the engineering manager and tech lead [?], the UXer and myself divided our accountabilities between ourselves. Things like: which problems do we need to solve first? What will we prioritize? How will we know if we've solved these problems? What value are we providing back to the business? Those were my accountabilities as the product manager. What user problems do we need to solve? How have we identified them? What solutions can solve our user problems? How will we keep our users happy? Those were the accountabilities of our UXer. What's the best way to provide these solutions? How fast can we put our solutions out there into production? How will we make sure our solutions are working properly all the time? Those were the accountabilities of our tech lead and our engineering manager.

[00:09:10] Revisiting our decisions about who was accountable for what, like the UXer being accountable for finding the right solutions for the problems we're trying to solve, and the tech lead being accountable for finding the right way to build solutions, made us question our own behaviors. Like, why are we running after the product manager alone for the PRDs or new features to build? It gave us space to redistribute the accountabilities to free up space for me, and for everybody else too, asking ourselves the questions of where there was capacity available and what made sense to delegate accountability for.

[00:09:55] For example, operational things here and there that would normally fall on the PM's lap, on my lap, automatically, because of tradition, job descriptions and Medium articles: stakeholder happiness, product documentation and communication, team happiness and productivity. If you read all of these, they're all in the job description of a PM. But because we started asking ourselves who has capacity and what made sense to delegate, we looked at the things that made the most sense to distribute, like product documentation and communication, and team happiness and productivity.

[00:10:36] Product documentation fell on the lap of our UXer, and team happiness and productivity fell on the lap of our tech lead and engineering manager, and they had their own reasoning. For example, team happiness and productivity made sense to become the accountability of our engineering manager or tech lead, because we were mostly engineers in our team anyway, and who better to understand their needs and their happiness than the tech lead and the engineering manager themselves?

Distributing responsibilities

[00:11:06] Next, we looked at distributing our responsibilities. But first we need to understand the definition of what an accountability is and what a responsibility is. Accountability is making sure that the task or goal is accomplished appropriately. Who does that? While responsibility is accomplishing the task or goal, and who does that? We also tried to simplify the definitions of accountability and responsibility. Accountability became pretty much who our managers will follow up things with, who they will ask if they need to find out the status of X, Y or Z. And responsibility became who can actually do it: who has the capacity or capability, and even the courage to try if they don't know what it is.

[00:12:09] For example, our UXer is accountable for making sure we can provide the best solution to solve our users' problems. But that accountability came with so many things, like ideation, prototyping, research, even A/B testing, or the solution's requirements. A lot of things for one person alone, if you think about it, especially since that was not the only thing they would probably do in the matter of three months, in a quarter.

[00:12:40] So we enlisted the help of other people. We distributed the responsibility for these things. We enlisted the help of the people who have the capability to do it, like our data scientists, who have the capacity to do it [?], for example in the case of the testing. And that included those who were complaining about the quality of our requirements and documentation, the engineers, when it came to writing the solution's requirements. If there are engineers watching this, that was supposed to be a joke. But no, not really. People complained.

Challenging product norms: OKRs

[00:13:16] Lastly, we challenged product norms. OKRs are one of those traditional product manager tasks. Product managers are usually both accountable and responsible for them, but they take up a lot of time. They take up a lot of my time, from defining what our actual OKRs are for the quarter to driving the actual OKRs to get things done during the quarter: lots of meetings, a lot of following up.

[00:13:54] While this is traditionally a product manager's accountability, there is really nothing written in blood anywhere in the world saying that only the PM is allowed to take accountability and responsibility for this. In our team, since we were already in the business of moving accountabilities from one person to another depending on who has capacity and capability, what was really stopping us from moving OKRs as an accountability as well? Nothing. So we did, and this is actually what we're testing this quarter.

[00:14:26] The accountability for defining the OKRs still remains with me. I'm still taking that accountability and the responsibilities that come with it, like getting alignment on important goals with our stakeholders. But the overall driving of the defined OKRs during the quarter, making sure they were moving and getting done and that we were following up on them, fell into the hands of our engineering manager.

[00:14:57] But again, we were not satisfied, so we wanted to take it a bit further and try something different. Like we did with our UX accountability, we also started distributing the responsibilities for the key results themselves to everybody, and that meant including the engineers. Everybody got a key result to be accountable for: not just myself as the product manager, not just the UXer or the tech lead, but also the engineers. But that came with strings attached, like holding meetings with our stakeholders, understanding their problems and bringing them back to the team to understand how best we can solve them. Or pretty much being in meetings.

[00:15:51] You're probably thinking, how did the team feel about those additional responsibilities? Specifically, how did the engineers feel about those responsibilities and having key results for themselves? First of all, this is a test, and it's a test we're doing now, this quarter, Q4. Now that we're nearing the end of the quarter, some key results are in great shape and some key results are not so much in great shape. They still need a little push, and that we expected. What we did not expect was what they felt about owning those key results, and we were starting to get feedback. We probably still need to do a full retro around this, but getting constant feedback from them, to make sure they're still in a good space, was something we made sure of.

[00:16:47] What we've heard so far: some wanted to improve their stakeholder management skills. Some people wanted to know how to drive meetings better, for example, or how to communicate better. Some wanted to improve their time management and prioritization skills because, of course, they were also doing other things apart from driving these key results. Some were still coding, some were still designing A/B tests, some were still doing retros, for example. And some wanted to improve the process for next quarter, because we were also facing the reality that this is not going to go away. This problem is going to be a problem continuously, so we just need to solve it and make things better for ourselves.

What we learned

[00:17:43] What did we learn from all of this? First, team culture trumps preference. Our team culture pretty much dictates: ask for help when you need it, help out when you can, and team goals contribute to your personal agenda. Those are three out of probably many unofficial things we like to say during our dailies and like to think we live by as a team, like Thursdays are the best days of the week and you always need to end Fridays with beer, et cetera.

[00:18:27] Why is this important? Because a lot of people, and a lot of Medium articles, keep saying, "Yeah, but engineers are not into these things," or "Yeah, but we shouldn't push people to do things they don't like doing." That's preference. But for our team, that wasn't really as important as: somebody needs help, can we help them? What's the best way to make sure that by the end of the quarter we've achieved as much as we could, and who can chip in? For us, that was more important than anybody's preference. Because who likes going through meetings? Nobody really. Who likes context switching? Nobody does. But if this is a problem we all have to face, we just need to make it better for everybody, so it doesn't hurt as much, especially if it's toward the goals you wanted to achieve in the first place.

[00:19:29] Exposure brings opportunities. That's our second lesson. During the course of all of these solutions we are trying and testing, we found people who are super good at running workshops. We found people who were really good at running retros for the team, and because they were super good at that, we volunteered them for bigger kinds of workshops, for example tribe-wide retros, which meant more exposure in the company for that person. We found people who were really, really good with stakeholders, good at influencing stakeholders' decisions, and that's a super plus for all of us. It meant more help on that side of the business.

[00:20:25] We also found people who were really good at managing projects, driving people to completion, following things up, et cetera. Again, three out of the many discoveries we found in our team, apart from people wanting to be better at what you would call soft skills. Of course, this is driving discussions now about what's next for their careers, especially when there are job ladders involved. Job ladders will always say, "You need to be better at A, B, C." With these things, we're giving them opportunities to actually be better at those expectations and meet them.

[00:21:11] For myself, it was to lean back and trust: trust the team to be able to manage the stakeholders. I have to admit, during those first few meetings where I was just participating and not driving, to help support the engineers who were now running those meetings, it was very, very hard to just sit back, not say a word and not drive that meeting myself. It was hard, but I knew I had to do it. I knew I had to trust the team to communicate as well as they can with the stakeholders we have, and that they can drive the meeting to achieve the goal the same way I would. It's just that they have a different style of doing it, and that's completely fine.

Challenges, management support and advice

[00:22:01] Just in case you're wondering, maybe there are questions already popping into your brain, I'm going to try to preempt a couple of them. Did we have any challenges? Yes, a million. Things like engineers who own key results also helping out in other projects, and balancing both of them was pretty difficult, especially in the beginning, because we were all trying to figure out the best way of doing this. And probably some projects could have been better handled or better communicated, for example. But at the end of the day, it was a learning curve, and we were all prepared to face those challenges from the beginning.

[00:22:51] How did we get management support? We actually didn't ask. We just went with it. We knew we had a problem. It was going to get bigger any time soon, and we needed to solve it preemptively, before it exploded in our faces. So we just went with it, and shared with everybody else afterwards that we were doing it, to get feedback, and that's pretty much it. At the end of the day, it was for our team. We were not risking anything bigger than us. We also positioned it as an experiment on our side. It was something for us to learn, and if it didn't work, we would just go back to the old ways of doing things and find a different solution.

[00:23:45] Do I have any unsolicited advice for those who want to start doing something similar? I would just say: encourage collaboration and build that culture in your team, where helping each other out is more important than "this is a product management thing" or "engineers are not interested in doing this or that". Throw those stereotypes out the window and focus on your team's goals, your objectives. What do you want to achieve by the end of the quarter, by the end of the year? How are you going to win? How are you going to help your stakeholders win? A lot of things will fall into place after that, or maybe some kinks will need to be ironed out, but it's a lot more important than egos and preferences and stereotypes.

[00:24:50] Lastly, that famous line I always hear and read about at conferences and in Medium articles: bringing the team closer to the business. If you really want to do that, it's more than just sharing slides with the team when you're already aligned on the OKRs, or sharing a presentation with them about the vision and the metrics. Actually bring them to the business, bring them to the stakeholders, and make them understand the problems themselves. You're probably going to have a richer conversation after that, because they will bring their own perspective.

[00:25:42] That's pretty much it from me. I'm all over the internet, by the way. I come from that generation that vomits feelings on the internet, and I'm still doing it up until now. So it's easy to find me on LinkedIn and Twitter. It's Kax Uson. If you have any questions, feedback, violent reactions, if there are any, I'd be happy to hear them.