The journey of Kax Uson from employee #1 at an e-commerce start-up in the Philippines to Head of Product at Adevinta looks familiar to the path so many product managers have taken. At every turn, she’s learned the processes and tools that come with the role – and then unlearned the ones that became a burden to her effectiveness in it.

In this episode of Product Momentum, Kax guides us along her journey and offers a primer on what it means to be a successful product manager in the 21^st century.

“When users look at the products we build,” she says, “they don’t care whether it was built using Kanban or Scrum or Waterfall. Our users see only the product and feel the experience we’ve delivered for them. The process that we use to get there is not relevant.”

There’s a lot of focus in the product space on ‘getting these things right versus actually getting things done.’ The outputs over the outcomes, Kax adds.

“Things to do. Rules to follow as product managers. When really, that’s just a very small part of how to build products. I feel that we’re favoring more these tools and these frameworks, rather than learning how to work with people in order to build good products.

“Our contribution [as PMs] to product building is very intangible. Our role is to bring people together, to rise through the uncertainty and make sense of things, so that other people can actually understand what’s going on and bring trust inside the room. That’s a skill that you cannot learn from school, or any camp probably…it’s a skill that you learn by practice and by getting feedback and failing in some cases.

Be sure to catch the entire pod conversation with Kax Uson; so many more nuggets to share.

Is this a reunion of Product Momentum alumni? Not quite. It’s ITX’s Product + Design Conference 2023. June 22-23 in Rochester, NY. Featuring Radhika Dutt, Jesse James Garrett, Rich Mironov – additional speakers coming soon! Learn more.

Podcast: Play in new window | Download

Paul [00:00:19] Hello and welcome to Product Momentum, where we hope to entertain, educate, and celebrate the amazing product people who are helping to shape our community’s way ahead. My name is Paul Gebel and I’m the Director of Product Innovation at ITX. Along with my co-host, Sean Flaherty, and our amazing production team and occasional guest host, we record and release a conversation with a product thought leader, writer, speaker, or maker who has something to share with the community every two weeks.

Paul [00:00:43] Hey, everybody. I’m excited to share this conversation with Kax Uson. Today we got into a journey of hers that’s followed a path similar to many of us who’ve been in the product space for a while. She broke in almost accidentally and then followed a path to learn and then begin to unlearn some of the processes and tools that become almost a burden after a certain amount of time. She’s developed a really great story around freeing ourselves up to focus on the outcomes over the outputs and really delve into what makes people tick. I really enjoyed our conversation and I’m excited to share it with you now.

Paul [00:01:18] Well hello and welcome to the pod. We are pleased to be joined today by Kax Uson. She’s been working as a product person for ten years but has been in tech for almost 20. For her day job, she currently serves as the Head of Products for a cross-functional tribe and an international tech company based in Europe. After work hours, though, Kax teaches a product management course in a tech academy for women by women, called AllWomen.tech. She also coaches product managers and aspiring and new product leaders to confidently grow in their product careers. Kax, thanks for being on the show. We’re really happy to have you.

Kax [00:01:50] Super cool. Thanks for inviting me.

Paul [00:01:52] Absolutely. So I’d love to just share a bit of your story about what your journey into product has been like, to introduce you to folks who might not be following the things that you’re doing. Can you tell us about your background and how you became a product management expert?

Kax [00:02:06] Sure. I guess you can call me an old-school product manager. So I came from the batch of ‘we fell accidentally into this role.’ Technically, though, I did graduate with a CS degree, so I do have a computer science background. But after graduation, I never coded a single line in my life. After graduation, I was like, “I’m done with this, I’m going to do something else.” And many career choices later, that something else brought me closer to product management.

Kax [00:02:35] And actually, that something else specifically was when I was working in a startup in Philippines. So I’m originally from Philippines, and sometime in 2012 probably I was working in a startup as employee number one. In Philippines back then, e-commerce was not so much a thing and there was this guy who was like, “I have an idea, we’re going to copy Groupon and we’re going to bring it here in Philippines.” And I said, “Cool, count me in.” [I was] employee number one, which pretty much meant I was doing every single thing that there needed to be done and I was sharing those tasks with the CEO because for a few months, it was just the two of us. From customer service to category management to shipping facilitation, and even reception because people were coming into the office to pick up items, I was doing every single thing. And of course, working with the engineers to build the website for it.

Kax [00:03:31] Of course, we needed people, so we started hiring people into the company, and I needed a title. I had a very generic project manager role, but we all knew that it wasn’t what I was doing exactly, and me and my CEO were like, “We need a title that I could put on my LinkedIn and explain to my mom what I’m doing.” So we went on Google and we were pretty much Googling for job titles that kind of matched what I was doing and we landed on product manager. Product management didn’t exist in Philippines back then, or maybe it did, but we were what, five people or ten.

Paul [00:04:13] Right.

Kax [00:04:13] And we were like, “Nobody knows what this is; nobody’s going to question if this is really you; let’s stick with that.” And from that day on forward, I was a product manager.

Paul [00:04:24] I think that’s very typical of that era. I came into product at about the same time and I held several titles that were kind of overlapping Venn diagrams of combinations of titles. I empathize completely. I love that you were doing the job and then figured out what it was called as a result.

Kax [00:04:39] Yeah.

Paul [00:04:40] It’s kind of very meta in a product sense. So you’ve been coaching product managers, product leaders into their career, especially women in tech. What do you believe are the most critical skills for a product manager to have?

Kax [00:04:51] Oh well, we’re coming off the bat with tough questions. Well, I think for product managers, especially for the ones who are starting, there’s two sets of skills. There’s the hard skills, the more technical skills, the ones that would probably include prioritization, user research, et cetera, and those are important. But I will set that aside and focus on something that’s probably more inherent to the human, which is the people, which are people skills. And some people call them soft. I really think they’re nothing but soft. So a couple of things: communication, number one, it’s our bread and butter. It’s all we do.

Paul [00:05:30] Yeah.

Kax [00:05:30] We have meetings. We align people, we pitch things, we influence the sessions and it’s all through communication at the end of the day. So we need to be really good at telling stories. We need to be really good at invoking excitement and passion, especially on the darkest of days.

Paul [00:05:49] Yeah.

Kax [00:05:49] And good communication also builds trust. If you’re very transparent, but know when to limit your transparency, if you can also share a little bit of vulnerability, if you’re okay to say, “I don’t know, but I will talk to the people who know it.” It’s trust building and connection building.

Paul [00:06:08] Yeah. During the chat that we had before the show, you shared a personal anecdote a few years ago when you were pitching an idea and it was the quote-unquote right idea, and it didn’t happen to land. And then you shared about how somebody else came in later. Can you fill in the blanks? How did that story end?

Kax [00:06:26] Yeah, it was actually maybe three, almost four years ago. I was building a product for trust and I was building a ratings product. Transactions was a huge topic in our organization back then. And things were connecting in my brain like, “Hey, we have an opportunity in this part if we do this.” And I was speaking in front of maybe ten product managers coming from different areas of the organization and there were product leaders in there, and I just went with the idea: “this is what I think we should do.” No context, no impact, just that it was a great idea. That was it. And I expected them to believe it. But there was really no reaction. There were barely any questions after that. So I didn’t land at all. And of course, I walked out of that conversation disappointed, thinking like, “okay, people are not ready for my brilliant mind,” but what, one year later some person comes in and they’re doing the exact same thing that I was talking about. And the biggest difference was that person just told a better story than I did. And I heard it and I felt compelled, and I just had to remind myself, “Hey, I talked about that next year.”

Paul [00:07:41] Right, right. So I heard a couple of things In those list of critical skills. We have to be able to organize the spaghetti as product managers. We need to be able to take this ambiguity, this uncertainty, and start to make sense of it. We need to be able to tell stories. We have to have a compelling talk track and not just be influential or be persuasive, but really empathize with the people. And that comes down to the last thing that I heard, which is there are human beings in the mix and humans are complicated. So these relationships are really more product management than the products themselves. If we can empathize, if we can lean in, if we can assert or persuade… Those relationships in a real sense, become the product. The DNA of our products are a result of the relationships that we build. Is that a fair summary of what you’re trying to say?

Kax [00:08:22] Exactly, especially since, for the most part, we don’t code. Our contribution to product building is very intangible. Unless we can code, or maybe we’re missing some experts here and there then probably we’ll do the user research ourselves, we’ll prototype ourselves. But when there are other experts in the room, our role is to bring people together. And this is where communication comes in, being able to rise through the uncertainty and make sense of things, organize the spaghetti, so that other people can actually understand what’s going on and bring that trust inside the room. And not just trust for us, the product managers, but for people to be able to trust each other. That’s a skill that you cannot learn from school, or any camp probably…it’s a skill that you learn by practice and by getting feedback and failing in some cases.

Paul [00:09:13] Hundred percent. That’s a great reminder. It’s simple, but it’s not easy. During, again, our talk before we hit record, you had a hot take. I’ve been excited to ask you this question. You had a bit of an unpopular opinion on kind of the state of product today and how there’s a lot of talk and not a lot of doing when it comes to tools and frameworks. And I know there’s a lot of helpful things, but there’s a risk that comes with it. Can you unpack a couple of those ideas about where you see us being able to improve as a product community?

Kax [00:09:42] Sure. This is where I hope my Twitter doesn’t explode after this podcast comes up. But basically the gist of it is that what I’m observing so far is there’s a lot of talk about things to do, rules to follow as product managers, steps that we should take to get the right insight. And I think what I’m seeing right now is that there’s a lot of focus on getting these things right versus actually getting things done. And I think the risk here is that then I get feedback from people about, “Hey, I don’t feel senior enough because I don’t know how to do X,” or, “I don’t know how to write good OKRs,” when that’s just a very, very small part of how to build products.

Kax [00:10:30] And I think it’s just that there’s a very unhealthy obsession in this case. And I mean, I’m part of it, I teach these frameworks and tools in class, but then you get into a situation when these tools and these frameworks don’t work because these tools and frameworks were probably borne out of a context. Somebody somewhere had the problem and invented these tools to optimize for their situation. But it’s their situation and every situation is unique. An organization, a leader, a team…and these tools won’t work for every single one of them. And then you get into a feeling of when these tools don’t work, “am I the problem? Did I just not do those rules properly? Or, “my organization sucks, they have no idea what product management or what product building is supposed to be,” but should they, actually? There are other teams in there who have nothing to do with product management, so they shouldn’t be following the rules at all.

Kax [00:11:30] And I feel that we’re favoring more these tools, these frameworks, rather than learning how to work with people in order to build good products at the end of the day. My ‘hot take’ actually is that, yes, use these frameworks to guide your thinking. If they don’t work, build your own.

Paul [00:11:53] Love it. I think that empowerment is important for product people to remember. We’ve become beholden to the outputs and not the outcomes. And I think that that thinking can help remedy some of those things. So I think it’s really kind of getting back to those basic ideas. I think it’s a great idea. You know, you also mentioned in that response that there’s an importance of getting back to basics. Things like talking to users, getting ideas validated in the market. And I wonder, as we step away from the hyperfocus on process, what are some of the ideas that an aspiring product manager or product leader could do to build these things into the organization, if they’re not coming naturally as part of the ‘organization that sucks,’ as you say. If we’re afraid to talk to users or there’s just not that muscle memory to do it, what are some ways that we can break out of the mold a bit as product people and help our organizations level up?

Kax [00:12:40] Let me contextualize that a bit, because I don’t think product managers now are afraid to talk to users. I think they’re hungry to talk to users, which is a good thing. However, sometimes it’s not always accessible for them. Maybe it’s a B2B product and the user is at the other end of the company that they’re selling their products to, and they’re not always accessible to us to talk to, and that’s fine. But then this is where the frustration comes in. Just the thinking that, “Hey, I’m not talking to the end users, I must not be doing my job right.” But that’s not actually the case. So, here I think it’s really a matter of optimizing for what you want to learn.

Kax [00:13:20] At the end of the day, our purpose as product managers is to put value out there so there’s value captured back for the company. It’s still a business. We need that value captured back. So what do we need to learn to bring that value out there? And maybe that’s the first one. Like, for example, every idea starts with an assumption. We assume that it works. We assume that it’s a good idea to build in the first place. And maybe we just need to break down these things and understand, what do we want to learn? What does ‘works’ mean?

Kax [00:13:52] And we don’t always have to go to the extreme of, sit in a nice, clean UX lab and sit in front of an end user with paper in front of them and get them to do a test. Sometimes the learning is actually with customer service. Sit with customer service instead, answer those tickets and get firsthand knowledge about what people are complaining about. That’s learning just the same. That’s still invaluable insight that you can get. And it’s okay if you didn’t sit in front of the end user. It’s okay. It’s the same thing. You will get the same insight one way or another. So for me, it’s about, optimize for learning, because then when you optimize for that, there’s more options to do instead of optimizing for a user interview.

Paul [00:14:37] I love what you said in the middle there, calling out assumptions per se. The word assumption is very loaded. It often gets a bad rap, right? Assumptions are bad. We need to ‘root out assumptions.’ The problem is we need to be able to validate that and that kind of going to the market, even if we have to get creative, going to a Reddit community or a Discord server where they talk about this kind of stuff and just kind of validating ideas. It’s not bad to have assumptions and make ideas part of our workflow. The challenge, that hunger that you talked about product people having comes from not necessarily having that access and getting creative about ways to solve it. Is that kind of a fair summary of what you’re trying to say?

Kax [00:15:16] Absolutely. I think I could even summarize it through two words: be resourceful. Some of these processes, some of these tools that we were mentioning earlier, they’re expensive. And when you’re working in a startup, for example, you probably don’t have the budget or the resources to get things right. If you’re working in a big organization, time is your enemy because things need to be approved because bureaucracy, and time is the enemy of building products. The market is going super fast. The behaviors change every day just because a volcano erupted somewhere. So we need to be resourceful. We need to be resourceful in terms of how do we learn, how do we put things in front of users, how do we iterate? Then the world is your oyster because they’re open to any kind of option now.

Paul [00:16:09] You’re reminding me of a mantra that one of my mentors mentioned a long time ago. It went something to the effect of, “when in charge, take charge.” So, you might not have the permission, or in your case, you may not even have the title to go with what you’re doing. But if you’re the person in the place at the time to do what needs to be done… Oftentimes, product people have to operate in this uncertainty and make some decisions that are going to drive the product to the place that it needs to be. And oftentimes, we’re not going to have that direction just given to us on a silver platter to know which way to go. I love that. That empowerment is why I think being in product is so exciting. It’s kind of blazing a trail for people to follow and to help solve problems.

Kax [00:16:49] Absolutely.

Paul [00:16:53] Hey, folks. Please excuse the quick break in our conversation, but I wanted to share a quick reminder. Coming June 22nd and 23rd, 2023, ITX is hosting our Second Annual Product and Design Conference. I can now confirm three of our guest speakers. Jesse James Garrett, one of the founding fathers of UX Design and currently a UX design leadership coach, will be delivering a day two keynote. Rich Mironov, a legend in the software and product space, will conduct a workshop in addition to a keynote talk. And we’ll also have Mike Belsito, CEO, of Product Collective, returning to help us emcee the conference. New to the lineup is the amazing Radhika Dutt, who like Jesse, Rich, and Mike, was a guest right here on the Program Momentum Podcast. Radhika is an entrepreneur, leader, coach, and the author of Radical Product Thinking: A New Mindset for Innovating Smarter.

Paul [00:17:38] The conference is a great time for networking, learning, and bringing some great ideas back to the product teams that you lead to help level up your game. It’s also going to be the opening weekend of the Rochester International JazzFest, which is always an awesome event. Lastly, early bird pricing ends Friday, April 21st, so be sure to take advantage while they’re still available. If you have any questions or want to know more, you can go to ITX.com/conference2023. That’s ITX.com/conference2023. All right. Let’s get back to our conversation with Kax.

Paul [00:18:11] I want to come back to one thing that we were talking about a minute ago in terms of processes and tools. There is a balancing act, right? At some point, tools and processes are going to need to be part of our kit. We need to balance the need for standardizing things, but also maintain this freshness and this, you know, new learners’ mindset. What are some of the best practices that are able to remove the risk, to work with assumptions, to help empathize and connect with users? How do you reconcile this kind of hot take that you have along with the need to standardize some things?

Kax [00:18:47] To be honest, I’m still trying to figure it out.

Paul [00:18:49] Okay.

Kax [00:18:50] But I think, for me, when it comes to best practices and standard practices and tools, I always look at it from the lens of, the best practice is the practice that works best for the team. It’s not about whether you’re doing Scrum or you’re doing Kanban, it’s about, how do we get cadence? And maybe we’ll just use Scrum and two other teams are using Kanban. It’s fine as long as we’re able to deliver in the time that we’re supposed to deliver.

Kax [00:19:19] I actually had an experience the other day. I was pushing for a best practice myself and my engineering counterpart was pushing for a best practice of sprint reviews at the tribe level, which is a lot of people. And this is a huge change from the way that our team worked. Just a quarter ago, we didn’t have sprint reviews at the tribe level. Sprint reviews were done at the team level and they were pretty closed. But we were so focused on the process itself of doing a sprint review and we were being very top-down about it. But we were forgetting that it didn’t really work for the teams at this point because it was a huge change for them. It was a huge change of culture, they weren’t ready. There were things that they were still working on that wasn’t ready to be shared with other people. They didn’t feel comfortable and that’s fine.

Kax [00:20:07] And then we had to find a middle ground. And for me that’s the important part: finding a middle ground that is about being able to answer the need in the first place. So my PM, she said, “well, what is the goal in the first place? What are you trying to optimize for? What do you want to achieve?” And it was really about visibility. So if it was visibility that we needed, there were other things that we could do for us to get that visibility across, it didn’t necessarily have to go to the other extreme of not sharing, from not sharing to overtly sharing. We could have a transition there. And for me, that’s finding that balance: by being clear on the goal, by understanding the context that we are operating in, and being open to different kinds of practices, because the goal is what’s going to keep us standard. The goal is what’s going to keep us aligned anyway. The practices could be different.

Paul [00:21:00] That makes a ton of sense. When you look at products, there’s no way to tell, “Oh, this product was built by Kanban; this product was built by Scrum; this product was built by waterfall.” The users just see the product and they feel the experience that we’ve delivered for them. The process that we use to get there, at the end of the day, is irrelevant. You’ve focused a lot on teams in your response, and I want to dig in just a level deeper there and talk about how to build a culture of fun in your teams. If they’re feeling either psychologically unsafe or they feel like there is a high or low degree of trust in the organization that needs to be unpacked, there can be some hesitance to put themselves out there. But I think one of the themes that might have been implied is just having fun. In building a team, there are human beings that are building the product as well as human beings on the other side using the product. How about these people that are building it? How do you lead a team at the same time as you’re solving product problems?

Kax [00:21:51] So let me zoom in first on the question of fun. How do we ensure that the team is having fun? That’s difficult because the definition of fun can be different from person to person. So I can probably say that for me, having fun means having beers after work and then that’s not fun for the more introverted half of the group. So I think here, what’s important is also to understand the individuals in the organization. Understand what their needs are, understand what their definition of fun is, and make space for that. Some people like to go to escape rooms and that’s their team building. Some people just want to have a relaxed weekend in the mountains and that’s their team building, and both are fine. For me, it’s about giving them the space and the budget to go forth and explore what fun means for their team.

Kax [00:22:45] For me, it’s also about not taking things too seriously. We’re not heart surgeons. We’re not building products that are gonna save lives. Unless, of course, you’re in health tech. That’s a different story. Don’t listen to me. But for most of us, it’s okay to not take ourselves seriously, be okay to make mistakes, and be comfortable to say them out loud, and be okay to laugh about these things. And I think in that part, it’s also about leading by example. So for me, I try not to take myself too seriously in these situations. Yes, I can tax and I can be demanding, but then I can go and say, “That was hard, want to go for a beer…”.

Paul [00:23:30] Yeah.

Kax [00:23:31] “…So we can walk through it?” And then you iterate based on whoever it is that you’re working with.

Paul [00:23:37] Yeah, I think you’re getting on some sort of core human issues there. I think we’ve covered a lot of ground here. One of the themes that just at a high level that I heard is the need to unlearn some of the process focus and the output focus and get back to the basics of outcomes that we’re trying to drive and really think deeply about both the people on the teams that we’re working with and the humans that are building, the users at the end of our product journey who are going to experience these things in the world. As we’re coming to a close on the time that we have today, are there any summary tips for a product manager thinking about, you know, “I’ve been in this grind, I’ve been in a team, I’ve been in a rut, how do I get unstuck?” Anything come to mind that would be a way to get them thinking outside the box, to bring some fresh life into their teams or their product roadmaps, maybe their relationship with their users?

Kax [00:24:25] I talk about people a lot because I feel like the core of the work that we do as product managers is about people. When the purpose is about providing value to users, that’s people. But we build it with people and we cannot run away from people in this role. So that’s why I focus a lot on that aspect and not on the frameworks, because somebody smart once told me, “you can be the best product builder in the world, you can build amazing products, but when people don’t want to work with you, you’re nothing; what’s your ability to build products on your own?” Impossible. Unless you’re a solopreneur, then that’s a different story.

Kax [00:25:04] But in this context of organizations, that’s impossible. That’s why we focus on it a lot. Because then when these frameworks and tools come in, it’s supposed to help us unlock thinking, it’s supposed to help us engage people into the thinking. And when we’re stuck, that’s why there are people around you anyway. It’s about asking for help and being able to say, “Hey, I don’t know what to do with this, do you? Yes? Come and help me and we can do this together.”.

Paul [00:25:35] Yeah.

Kax [00:25:35] And that’s the beauty of being in an organization. It’s supposed to look this way. I know it’s hard. And that’s an ideal scenario because some organizations can be tough, some cultures can be not a fit for everybody, but it’s a mission that we can aspire for. If we can have vision for our products, if we can have vision for our organizations, we definitely can have vision for the way that we want to collaborate and build our products with other people.

Paul [00:26:01] Yeah.

Kax [00:26:01] For me, that’s my main takeaway here. Have a vision, then build that vision with people.

Paul [00:26:08] And there’s a note of humility that I took away from that. You might not have all the answers, but go find people who do. You know, as we come to a close, I just have two last questions for you that are quick. The first one we ask all of our guests before we let them go, what would be your definition of the word innovation? How would you define it?

Kax [00:26:24] Well, I have thoughts about what I don’t think innovation is, and maybe I’ll start there. Yeah, I don’t think innovation is just about building the next big thing. I don’t think innovation is just about using the latest tools and technology. Right now, AI is the buzzword just because we’re using AI, I don’t think we’re innovating. It’s about solving problems in the best way possible. Maybe that problem has been solved two years ago, but like I mentioned earlier, context change, life changes, and that problem needs to be solved in a better way. Now, for me, that’s innovation. And innovation always needs to have a purpose and not just a shiny new toy to fixate on.

Paul [00:27:07] That’s a really great take. I like that a lot. Last question before I let you go. What have you been reading or watching or listening to or anything in your volunteer work that you’d like to plug that you think a product manager would benefit from a podcast perhaps, that you found helpful that should be on a product manager’s shelf? What inspires you?

Kax [00:27:24] I’m laughing because I just wrote about this in my own blog about I cannot read product-related books. I just cannot. I haven’t read the bibles of product management. I couldn’t get past chapter one. So for me, rather than recommending specific titles, except for RuPaul’s Drag Race, I think RuPaul’s Drag Race has been my biggest…biggest inspiration for a product because, I mean, you have limited time, you have limited budget, but you need to churn out an amazing thing to achieve a goal, which is to win. So definitely a great show to watch and maybe stir up some creativity in one’s brain. But instead of reading the usual titles and listening to the podcasts because there are many and they can be overwhelming. My take is first, understand how you want to learn. For me, learning method is definitely not reading. Reading for me is pleasure; it’s not for learning. So that’s why I shy away from it. Some people learn by doing, so maybe it’s about building something instead outside of their day job. Some people learn by teaching, so that I would definitely recommend. It’s a great way to synthesize one’s knowledge. At the end of the day, everybody has a preference to learn. Cater to that, and don’t try to just read the books because everybody else is reading them. Somebody can probably summarize it for you, the ones who like to read those books.

Paul [00:28:53] Love it. That’s a great take. Well, I’ve really appreciated the time that you’ve taken the insight, and just sharing your journey, your transparency and candidness. Really appreciate it. I’m sure you’re going to inspire a lot of people on their journey, so thanks for taking the time today. It’s been a pleasure.

Kax [00:29:07] Thank you.

Paul [00:29:10] Well, that’s it for today. In line with their goals of transparency and listening, we really want to hear from you. John and I are committed to reading every piece of feedback that we get. So please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch and inspire the world just like you’re doing. Thanks, everyone. We’ll see you next episode. You.