Building a Unified Team In Unprecedented Times

My name is Kax. I'm from Philippines and I moved to Barcelona five years ago and I forgot to come home. So, I'm still here in Barcelona. I am a Product Manager or by the person 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 it's called Career Hacking for Women, which I started with two other friends were based off of 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 some things I also like to show off my non-existent singing skills in karaoke and that's pretty much me. I first wanted to show this image which I am pretty sure everybody, or a lot of you have seen at this point. A few months ago, I actually saw this image circulating in LinkedIn and normally, I would have laughed along with the other people who reacted to this post. But because it was shared by an Academy teaching product management course, and there were a lot of people say, "Oh, this is so true. I actually spend 24 hours doing product management and I do every single thing." Instead I actually found it problematic. I wanted to laugh but I'm like, "Nope, this is wrong." And I found it problematic because of a couple of things. First, I think it romanticizes over working and it glorifies the practice to put everything on the product manager split. And in that sense, it also encourages gatekeeping on the product managers’ 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 that other people can contribute and help each other out when it comes to building great products. And you're probably thinking at this point, gaps. 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 actually sit down and think about the things that 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 that they're supposed to be doing because there's a lot of small things that keep falling on their lap. And when will they have time to think about strategy or roadmap even if we're going to go simpler and 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. Today or tonight depending on what time you are watching. I wanted to share with you that this meme doesn't actually have to be true, that there are other ways of working that leverage is involving other people in your own team on the tasks that used to be labeled those product things like managing stakeholders or PRS, even writing PRDs and JIRA tickets like we have done in our team and we're still doing because we're constantly testing. We're constantly trying to improve the ways that we're working. Today, I wanted to walk you through the problems that made us decide to change the way that we work. The solutions that we have tested and still are testing and the impact that these changes have made on our teams. So, that just in case you're also facing the same problem in your team, 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. Very important thing. We all know that have a metric 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. So, I work in a company called Adevinta and we do marketplaces and I'm part of a central tribe within the company wherein we build products that are to be used in these marketplaces that you're seeing right now which is pretty much 12 countries worldwide. And when this year started our tribes started expanding our ambitions and wanted to provide more value to the marketplace. So, those marketplaces that 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 a product manager of a team to becoming a product lead of a domain. That pretty much meant more meetings, more work streams and a whole lot more expectations. Boom. But I still have to remain being the product manager of the product team that I was part of, which meant I still have my old responsibilities and how the abilities as their product manager on top of the new ones that I have as a 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. On top of all of these, my seniority and my years in the company puts me in a position where in 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 PM's in the company. Sometimes, I'm pulled into different workshops, et cetera. And having all of these things on my plate have huge impact on my workload. The impact is starting to show apart from the obvious when am I allowed to have lunch or small things like emails and Slack messages that will 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 become a bottleneck to the team or before I become completely ineffective in my new mission. So, how did we actually do that? How did we make things better for this little problem of me? I'm the problem. Huge disclaimer, these are not solutions that we just applied from one day to another. These are things that we were putting and testing in place over time. So, first we look at distributing our how'd the abilities. We looked at distributing our responsibilities. Lastly, we challenged product norms. What do they mean? First, distributing accountabilities. When we were forming our team in the beginning, the engineering manager that they could need and the UXer and myself, we 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 where 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 with the accountabilities of our UX team or UXer. What's the best way to provide these solutions? How fast can we put our solutions out there to the production? How will we make sure our solutions are working properly all the time where the accountabilities or our tech need in our engineering manager? And revisiting our accountabilities our decisions for these accountabilities of who was accountable for what. Like the UX was accountable for finding the right solutions for the problems that we're trying to solve and that the tech lead is 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 and gave us space to redistribute the accountabilities to free up space for me and for everybody else too. Asking ourselves, the questions of where what's capacity available and what made sense to delegate the accountability for. So, for example, operational things here and there that would normally fall on the PMs lap or my lap automatically because traditions, job descriptions and Medium articles like Stakeholder Happiness. Product documentation and communication team happiness and productivity. Read all of these, they're all in the job description of a PM. But because we started asking ourselves who has capacity, 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. It looked like product documentation fell on the lap of our UXer and team happiness and productivity fell on the lap of our tech lead and engineering managers and they also have their own reasonings. 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 best to understand their needs and their happiness than that the tech leads and the tech leader, the engineering manager themselves. Next, we look at disturbing our responsibilities. But first we need to understand the definition of what an accountability is and what their responsibility is. Also known as accountability is being making sure that the task or a goal is accomplished appropriately. Who does that? And while our responsibility is accomplishing the task or the goal and who does that? We also tried to simplify the definition of accountabilities and responsibility pretty much to who will our managers follow up things with, who will they ask if they needed to find out what's 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, if they don't know what it is to try? So, for example, our UX is accountable for making sure that we can provide the best solution to solve our user's problem but that accountability came with so many things like ideation, prototyping, research, AB testing even, or the studio Sean's requirements, a lot of things for one person alone. If you think about it, especially that was not the only thing that they would probably do in the matter of three months, in a quarter. So, we enlisted the help of other people. We distributed the responsibility of these things. So, we enlisted the help of the people who have the capability to do it, like our data scientists, the capacity to do it for my son. For example, in the case of these testing and including those who are complaining about the quality of our requirements and the documentation, the engineers, when it comes to the right thing solutions requirements. And if there are engineers watching this, that was supposed to be a joke but no, not really. People complained and lastly, we challenged product norms. OKRS is one of those traditional product manager tasks. Product managers are usually both accountable for it and responsible for it, but it takes up a lot of time. It takes up a lot of my time from defining what our actual OTRs is for the quarter to driving the actual OKRs into get things done during the duration of the quarter, lots of meetings, a lot of following up while this is a traditionally a product managers accountability. There is really nothing written in blood anywhere in the world saying that only the PM is allowed to take accountability for this and responsibility for this. So, in our teams, since we were already in the business of moving accountabilities from one person to another depending on who has capacity and capability, what really was stopping us from moving OKRS as an accountability as well, nothing. So, we did, and this is actually what we're testing this quarter. So, the accountability of defining the OKRs is still remained with me. I'm still taking that accountability and the responsibilities that came with it, like getting alignment of important goals with our stakeholders, but the overall driving of the defined OKRs during the quarter and making sure they were moving and getting done. And we were following it, fell on the hands of our engineering manager now. But again, we were not satisfied. So, we wanted to take it a bit further. So, we wanted to try something different and 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, which meant everybody got the ket result to be accountable for. So, not just myself as the product manager, not just the UX or the tech lead but also the engineers but that came with strings attached like holding the 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. And you're probably thinking how did the team feel about those additional responsibilities specifically? How did the engineers feel about those specific responsibilities and having key results for themselves? First of all, this is a test and this is a test that we're doing now for this quarter, Q4. And 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 or actually what they felt about owning those key results and we were starting to get feedback. Probably we still need to do a full retro around this but getting constant feedback from them to be able to make sure they're still integrated space was something we made sure. So, 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 better communicate or some wanted to improve their time management skills 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 AB tests, some were still doing retros, for example. And somewhere they wanted to improve the process for the next quarter. Because we were also feeding 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 we just need to make things better for ourselves. So, what did we learn from all the things? First, theme culture trumps preference and our team culture pretty much dictates ask for help when you need one, help out when you can and team goals contributes to your personal agenda. Three out of probably the many unofficial things that we like to say during our dailies and we 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, et cetera. Why is this important? Because a lot of people keep saying or a lot there's Medium articles keeps saying, "Yeah, but engineers are not in there in these things." Or "Yeah, but we showed that push people to do things that they don't like doing." That's preference but for art theme that wasn't really so much 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. And for us, that was more important than anybody's preference because who likes going through meetings? Nobody really knows. Who likes context switching? Nobody does, but if this was a problem that we all have to face. We just need to make it method for everybody. So, it doesn't hurt as much, especially at those a third as much the goal is that you wanted to achieve in the first place. Exposure brings opportunities. That's our second lesson. So, during the course of all of these solutions that we are trying or testing, we found people who are super good with running workshops. So, we found people who were really good at running retros for the team and because they were super good at that, we've kind of volunteered them for bigger kinds of workshops. So, for example, Tribe wide retros which meant for that person work exposure in the company. We found people who were really, really good with stakeholders that they were good at influencing stakeholders’ decisions and that's a super plus for all of us that meant more help in that side of the business. And we also found people who were really good at managing projects, driving people into completion, following things up, et cetera. Three again, out of the many discoveries we follow in our team, apart from people wanting to be better at their, what you would call, soft skills and of course this is driving discussions now for what's next for their career, especially when there are job ladders involved and job ladders will always say, "You need to be better at ABC." With these things, we're giving them opportunities to actually be better at those expectations and meet them. For myself, it was to lean back and trust. Trust on the team to be able to manage the stakeholders. Well, I have to admit during those first few meetings that I was just participating and not driving it to help support the engineers who are now running those meetings. It was very, very hard to just sit back and 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 on the team to know how to communicate better or as good as they can with the stakeholders that we have and that they can drive this meeting to achieve the goal the same way that I would. It's just that they have a different style of doing and that's completely fine. And just in case you were wondering maybe there are questions out there that already popping in your being, just going to try to preempt a couple of them. Did we have any challenges? Yes, a million, probably some things like engineers who are owning key results who are also helping out in other projects and balancing both of them were pretty difficult especially in the beginning because we were all trying to figure out what's the best way of doing this and probably, some projects that could have been better handled or could have been better communicated for example. But in the end of the day, it was a learning curve and we were all prepared to face those challenges from the beginning. 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 be big or bigger in anytime soon. And we need to solve it preempt before it exploded in our faces. So, we just went with it and just 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. So, we also position that as an experiment on our side, it was something for us to learn and if it didn't work then we're just going to go back to old ways of doing it and doing things and find a different solution and the way 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 wherein helping each other out is more important than this is a product management thing and engineers are not interested in doing this or that. Throw those stereotypes outside of the window and focus on your team's goals, focus on 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? And that's it. A lot of things will fall into place after that or maybe some kinks need to be ironed out, but it's a lot more important than that egos and references and stereotypes. Lastly, that famous line that I always hear and read about in conferences and medium articles, bringing the team closer to the business. Actually, if you really want to do that it's more important. It's more than just sharing slides to the team when you're already aligned with the OKRs or sharing a presentation with them about the vision and the metrics, actually bring them to the business, bringing 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 afterwards. That's pretty much it from me. I'm all over the internet, by the way, I came from that generation that feelings vomited on the internet instead of doing it up until now. So, easy to find me on LinkedIn, Twitter, it's Kax Uson and if you have any questions, feedback, violent reactions. If there are any, I'd be happy to hear them.