Mobility Spotlight

Episode 01: Talia Comorau's journey from Client Services to Product Management

Post by
Nick Ionita, Co-founder & CEO
Episode 01: Talia Comorau's journey from Client Services to Product Management

Welcome to the inaugural episode of Flux's Mobility Spotlight where we interview incredible people who have made big career leaps. Our goal is to highlight these transitions and understand what drove them, experience and working-style overlaps that might not be obvious, and to share advice for others considering a similar move.

If you prefer podcasts, you can follow/subscribe through your favorite player here!

In this episode we're speaking with Talia Comorau who is a Senior Director of Product Management at Comcast. Before Talia's successful rise in Product she started in Client Services as a Support Engineer and later a Solutions Engineer. In this discussion we cover:

🌱 Growth paths between Support, Customer Success, and Product Management

🏃🏽‍♀️ Under-appreciated skills and working styles that translate well into Product roles

💡 What Talia looks for when hiring PMs, and why emotional intelligence is a critical skill

Talia's career pathways

Interview Transcript

Nick (Flux): Talia. Welcome.  Thanks for joining us. This is the first one of these we're doing. And I think like I was telling you before, it was really important that you were the first person we did one of these mobility spotlights with. I'll let you introduce yourself and get background, but just so anybody listening or reading gets the background, when we started flux and raised our initial round of capital to build the company, you were literally the use case that we use to explain what we were trying to do with software. And that was very much about finding people who had all the right skills and motivation to do things the business needed, but just maybe didn't see themselves making that move or knowing that that was available. 

And for background, Talia worked with myself and a number of people on the Flux team back at a company called FreeWheel that's now part of Comcast and made this amazing transition from the services team into product. And is still there running a big part of the product team, which is awesome.

Let’s start with your current role. What are you doing and what does it look like? 

Talia (Comcast): Yeah, sure. I'm very excited to be here talking to you Nick.  Very honored to be the first in this video series.  So my current role is Senior Director of Product Management at FreeWheel. Nick mentioned that we're owned by Comcast. It's a part of the Comcast advertising business. And FreeWheel builds technology solutions that support buyers and sellers of media in activating their targets and goals through media consent. So there's a whole set of technology that we build, and my team is responsible for looking after the data products and related technology that FreeWheel builds. It's a cool topic to work on right now. 

Nick (Flux): FreeWheel really got integrated into Comcast almost as the beginning of a Software and Services Division. So I think the growth that happened for people even after the acquisition was pretty unique. It was one of these things where we were left alone for a while but kept growing and then really became part of the strategy and data is a big part of it. So it's amazing. You're leading that now. What does your team look like? 

Talia (Comcast): I have a team of 11 people. It's global, largely based in the US with a couple of folks in Beijing China that are embedded in our Beijing office.  I have three directs, they each have a handful of folks working for them, all of us are our product managers of various titles. So it's a pretty big team. And then we have this whole engineering team that our counterparts so I have an engineering lead. That's my counterpart on the data side of things, and he has his own rather large team working for him. 

Nick (Flux): That's great. And it's so cool that you're running a team of that size now because I know when you and I got to know each other when you came into product. You were wanting to explore managing people and going through that experience was important. So it's a testament to you that you're doing that now and you're continuing to grow.

Let's go back in time a little bit. I kind of spoiled this at the beginning, but let's talk about where you started in the services group. I don't think you had a traditional background from something like computer science, and you had majored in math and something similar. What got you into services and what were you doing there? And then what led to thinking about product or trying to make that move? 

Talia (Comcast): Yeah, I feel like this is gonna be a little bit of a longer answer. But my role at my last company and my last role prior to FreeWheel was an ad operations role. I was doing ad operations for a health video content owner, a little StartUp Health video company, and I was trafficking in the Google ad server. And as part of my role in ad ops at this company, was reviewing or evaluating other ad servers. FreeWheel was one of the ad servers that we evaluated and a couple of folks one of whom is actually still at FreeWheel came to pitch came to pitch to me and to the rest of my team, and I was immediately impressed by how knowledgeable the people were.  They were super sharp, they understood the technology, the salesperson, Katie could answer pretty deep technological questions very instinctively.  They're just a really impressive team and at the time, I will be honest, that FreeWheel was too expensive for my company. So we did not go with FreeWheel.

But the company sort of stuck in my brain and so when it came time to look for new opportunities, and I was talking to recruiters, they mentioned a support engineer role at FreeWheel. I was just interested in FreeWheel, that was really what pulled me to work there more than anything else.  I started at freewill as a support engineer, I actually moved fairly quickly into a solutions engineer role which those roles are closely aligned but not identical. Support engineers ran tickets through Salesforce, now we do it through Zendesk, but really just manage on a case by case basis client problems. Solutions engineers are more attached to clients and they are responsible for implementations and advanced technology setup etc. And at the time, I moved from support to solutions engineering, for a variety of reasons. But the biggest thing for me was that I was solving problems in a very sort of point solution focused way. 

So I was given a problem or asked a question, and had to come up with an answer. And I would do that by getting to know our existing technology and raising gaps to the product team and raising issues to the engineering team. And the solutions role I was more able to be part of the solution, it was less about me just handing over the question or the issue to another team, or back to the client. In some cases, it was much more about me saying, okay, this is how our technology works. It may not have been built for exactly the use case that you're asking me about. But I think if we squished this and pulled this one, I think we can sort of do what you're trying to do. Product, on the other hand is even further along in that spectrum, where we actually get to say, I hear your use case, the technology doesn't work that way, I'm actually going to rebuild it or build something new so that it does what you need it to do. And for me, I just felt like I was getting closer and closer and closer to solving the actual problem. So, you know, starting in support and hearing about all of the concerns, or the new things that are happening in their world that we now needed to support, I was able to sort of move further and further towards the solving of the problem. I won't say that that was like, completely comfortable for me, I'm sure you'll ask me questions about that. But, you know, but that was a large part of why I started moving from services to solutions and then eventually moved over into product which is where I am now. 

Nick (Flux): Yeah, that's great. And it's a fantastic answer. I feel like there was such a close parallel, so that progression makes all the sense in the world. And I think sometimes it's hard because if orgs don't align that way, right, this was moving from one thing to another and I know at the time the company was doubling in size. And this was post acquisition, and one of the challenges I had running product was that it (Comcast) wasn't always the place that people were looking to join. And yet we had this team over here, particularly with this role of solution engineer who are figuring all those things out and really getting to the root business problem having to go figure out how to get this done if there wasn't a product solution, which usually involved other teams and indirect influence and had all the makings of being a PM, they just weren't writing the specs. So we had a conversation and Max was great about wanting to create progression, and you landed in product. 

As you were starting to think about product was there anything else driving you wanting to go in that direction? 

Talia (Comcast): Yeah, I think so. In general, the way that I've thought about my skills, from very early on in my career is that I think that I am both strong in working with people and strong and understanding and speaking about technology.  I think that those skills are necessary for all three of the roles I described, like support for solutions and for product. But again, product for me really represented the pinnacle of that I needed to both be able to speak directly to engineering to be able to describe the feature set and then the product that I needed them to build. And I needed to be able to go talk to clients about the feature set and I needed to be able to answer client questions and I needed to be able to figure out what went wrong and so there's just this constant pivoting back and forth between those two worlds. And I really loved that with support.

I got this sort of narrow window where I was still interacting with engineering to find out what went wrong and still interacting with clients to find out what their question was or how their business worked. But it was a very small pieces of it, with Solutions (engineering) I was able to look at a broader swath of the client, like I might see a whole client’s business, or I might see all of the audience related businesses for a few clients, that's the sort of scope of that work. Whereas in product for example, I'm looking at all of the data related needs. So there's a lot that falls into that. And it's really allowed me to grow my scope a lot more. I'm a very learning motivated person, I'm super curious. I really love learning new things. Product was, in a lot of ways, a really great opportunity to do that.

I realized pretty early on in my FreeWheel career that I wanted to probably move to product actually, before I think even I moved to solutions (engineering).  I sort of had started to feel like this is probably a direction I'd like to go. So I actually started reaching out to you and your team. At the time I was not an expert networker by any means. So I would do it around the edges like, “do you think you'll ever be hiring people?” Just like, really awkwardly probably. But I think that  in our case that was necessary. It's actually something I coach women on frequently when I mentor.  I think it's important to ask for what you want, even if it feels like it's maybe not super attainable, and that was a bit of me doing that in my own awkward way. 

Nick (Flux): That makes so much sense. I think so many people either don't see themselves playing the role even though they want to or feel nervous about asking when they have all the right to.  I think your work kind of spoke for itself too. I talked to people on my team, and the feedback was always “Talia is awesome. We should bring her over into product.” And it’s one of the scenarios where we had two teams working together that knew each other well.

What would you say to someone wanting to make a move from a similar team to something like product?  What were the skill or experience gaps you needed to close to really feel like you were getting over that learning curve of a new role like that? 

Talia (Comcast): The biggest thing for me is actually the thing that made me want to be in product was also the hardest thing for me to learn.  I want to say time it was “management”, but it's really more complicated than that. In support I had cases and I would close the cases. And I would do it relatively rapidly. So there was this quick turnaround, I always knew what I needed to work on. It was always right there on my desktop, it was sort of easy to manage what I was working on. With solutions, I had implementations and they were longer in scope. They were, maybe three months, and maybe in the case of our beloved RPM advertiser nine months, but they were sort of clear in scope. My experience of product, at least when I first joined was really that my work was not super clear in scope. Often, I needed to be a lot more flexible with how I spent my time. I needed to be researching a given feature set or talking to clients about a feature set that didn't even exist in my head well in advance of designing it and starting to work with engineering to develop it or starting to put it on our backlog or roadmap and that evolution in my own mind.

My own sort of ability to work and my own day to day was really hard for me, in both cases actually moving from support to solutions, and then moving from solutions to product. I remember having a lot of conversations with other folks on our team where I just wanted them to tell me what to do. You know, I didn't know what to do in this moment. And the answer was get in touch more with clients, read some industry articles, ramp up on existing products. It wasn't always like you can design this, and then you're done. There's a lot more independent work, I think, within products than within the other two areas. So that was hard. 

Nick (Flux): That makes a ton of sense. You did a good job covering the skills and working styles that you had that carried into product. You were already in roles where there was a lot of problem solving and there weren't answers. And a lot of times you're figuring out that 80 / 20. What's going to happen if we don't do that? And doing that trade off. I think just being curious and constantly wanting to learn, which is just such a big part of it. It's not a job to become stagnant in. 

Talia (Comcast): Totally. I think in product, there's also a lot of business implications and business decisions that I also wasn't quite as exposed to as a solutions engineer, but that also took some, some ramping.

Nick (Flux): That's true. This is a bit of a curveball - what attribute do you think is important in a product role that people don't typically associate with it?

I feel like product is definitely one of these roles where people think the path is “go to business school or go do this thing” and none of that's actually required to do it well. I think there's a lot of these other skills like people management and indirectly working with people that are critical. Is there anything else that you've come across that’s just so obvious now thinking about it, but it's not a bullet point on a job description. 

Talia (Comcast): Your example rings very true for me. I had a manager recently who pointed out that the word manager is in the product manager title at every level, actually, even Associate Product Managers are still managers. I'm super passionate about people leadership. I love my team, but I also love the idea of helping people grow in that way. It was that person who pointed out that I was managing people all the time, that none of those people reported to me, but it was my responsibility to manage the engineers to the deadlines that we had agreed to for the company, it was my responsibility to manage the client account teams to help support them and in talking to their clients and also help me get the information I needed from the clients. It was my responsibility to manage the partner team, and so like there's so much people management and people skills involved in product that I think that's one of the number one things I look for when I when I interview a product person now. 

The technology skills are very important, particularly for an organization like FreeWheel, some organizations that's less important.  Technology fluency is something that I think you can pick up on pretty quickly. It's really much more to work with people effectively. I think its been core to my successes as a product person. 

Nick (Flux): Yeah, that makes a ton of sense. You're kind of answering my next question. So you've got a team, you've been hiring people for product roles, if we strip away the context of the specific things they might be doing, like product wise.  What do you typically look for when you hire people in product related roles? 

Talia (Comcast): I look for different things in somebody who is going to come in as a manager than in somebody who's going to come in in a more independent role, but thinking more towards the junior roles because I think that's more relevant for this discussion. I look for like I mentioned, technical fluency, the ability to understand and articulate technical concepts. The technology at FreeWheel is complicated and it's unique. I actively look for Talent within FreeWheel and Comcast. But if I'm not looking within the organization for a given role, I'm not going to find somebody who's an expert in our technology, I need to find somebody who can learn our technology and then be able to speak to it both to a technical audience and to a client facing audience or an internal less technical audience. I think the flip side of or maybe another side of the people management skills that I talked about is emotional intelligence. You know, just knowing how to moderate. To go back to my favorite example in this call, knowing the way that I talk to a group of engineers is very different than the way that I talked to my team of product managers, which is very different than the way I talk to clients, and a lot of that, I think is attributed well to emotional intelligence and knowing your audience. Being able to follow when others are following the conversation and run something back when you realize that you lost people. Those kinds of skills are really, really, really, really critical. And probably the top couple of things that I look for.

Nick (Flux): I think with product roles in particular, you touch so many different parts of the organization just to get things done, and some many different personality types across different teams.  I know one of the hardest things I found was balancing execution with engineering and expectations of a sales team and that would manifest one way with features we were delivering on a tactical level that would manifest another way, at a management level, with roadmap. But being able to understand how to navigate the situations, read different personality types, and still try to make it all work is one of the magic pieces for people that can do it really well. 

Talia (Comcast): Totally agree.

Nick (Flux): My last question for you is on advice to services and customer success - there's a bunch of different names for that kind of organization depending on the company and how it's organized. But for folks in those roles wanting to move into product specifically, what advice would you give them?

Talia (Comcast): Definitely get as close as you can to the product organization, both in terms of just getting to know folks on the team and also in terms of getting to know the product. Some companies may have product aligned solutions engineers already. So those folks are aligned to certain products, those folks understand the products really deeply. They're a great pool of talent to potentially pull from and we've done that before. Also expressing interest in moving into that kind of role or doing some sort of creative creation of that kind of role within your own expertise, I think can be really critical. Especially for folks who are working at organizations that have really rich technical products, deep knowledge of the product is incredibly valuable. That will save the product team up to maybe four months of training. If you're the candidate that they bring in, helping the product team reduce their time to activation of a product manager can be huge in terms of you peeking a leader’s interest in in hiring because we always needed the person six months ago, by the time we actually start looking for somebody.

I'd say that the other thing is that I really just encourage you to ask for what you want, talk to your own leader about it, talk to the people that you're starting to get to know within product about it. I think there's lots of ways to do that without being aggressive, but just sort of stating your interest and asking a lot of questions. I'll end on that - ask a lot of questions. Ask them about what they do. Ask them how they got into the role, ask them how they see their own career progressing. People love to talk about themselves. And hopefully, you'll learn something that might be useful to you and your own career progression along the way. 

Nick (Flux):  To add on to that I think there's a special level of empathy and insight that people from client facing roles can bring into product that a lot of product managers don't have at that level if they've not been servicing the product that way, particularly for complicated products where every enterprise setup is some different configuration. And there's just so much knowledge buried in the application.  I know when we brought people like you and some others from services into product, I think the level of understanding of how the product was being used was just very profound and very additive to what the team was doing. So it was a big, big upgrade on top of the time savings and everything else. 

Talia (Comcast): Yeah, that's, that is a great point. One thing that I have found sort of interesting in my own experiences, as a person who is new to the product team is that one of the first projects that I worked on, I was partnering with another person who was new to the product team, who was coming from engineering. That was fantastic I think for both of us because we both needed to learn what the other person was an expert in, in terms of me learning to communicate with engineering and him learning to understand client needs and think about client use cases.

In general it was amazing how much he added to the relationship and I hope that I added to the relationship and our ability to build something together. It was a pretty powerful experience and a powerful example of exactly the kind of mobility Flux is trying to drive from a couple of different directions. 

Nick (Flux): That's awesome.  This was fantastic Talia. I was really looking forward to this. I think this was super insightful. So thank you for your time. Any hiring?  Anything you want to plug while you’ve got some airtime?

Talia (Comcast): I'm not hiring right now but we'll let you know, so that maybe you can do a plug later if I'm if I am. I also was really looking forward to this and I would just say that this kind of mobility and this kind of opportunity, creating space for this within an organization is really powerful. And I think is a big part of why FreeWheel, at least in the case of my example, has been able to retain so many people. I think that it's critical to retention to allow people to have more opportunities in areas where they're passionate. It's really important.

Flux
An internal mobility platform that develops, engages, and retains your workforce.