Leader Spotlight: The case for leveling up, not managing down, with Natalia Walicki
Natalia Walicki is a product leader with experience spanning early-stage startups, high-growth scaleups, and large enterprises. She got her start in politics before moving into operations and then product management — first at Cazoo in London, where she made the transition into leadership, and later as eCommerce Product and UX Director at Cazoo, overseeing the end-to-end checkout and product experience for online car buying. She is currently Head of Digital Product Center of Excellence at Goodyear.
In this conversation, Natalia talks about what actually makes someone ready to step into a product leadership role — and why most people get into management for the wrong reasons. She shares the practical skills she carried over from her time in politics, her approach to building confidence as a non-technical PM, and what she thinks product leaders get wrong about working with engineers. She also offers a candid read on where AI is genuinely changing how teams build — and where the hype is still running ahead of the evidence.
From IC to leader
What was the decision to move into management like for you?
When I started in product I was an IC and then I moved to London and joined Cazoo which opened up my management track. A lot of your career growth — not just as a product manager, but for anybody — is being at the right place at the right time. I was in a position where I had a lot of opportunity to go into a management role, and the trajectory was very clear because of when I joined, how early I joined, and how much growth there was happening in the company.
There wasn’t a principal IC role. I didn’t know that even existed at the time. So management was really the only path. But for me, that was what I wanted — previously I was director of operations, managing an operations team. I liked that a lot because I really enjoyed working with people, managing, but also mentoring, making sure that people have access to what they need. So it was something I naturally wanted to do and was at the right place and the right time to pursue.
What makes a great product manager doesn’t automatically make a great leader. Where’s the line?
If you don’t have interest in working with people on their skills, goals, and ambitions and putting the work into others every day – then you shouldn’t be a manager. You have to have a certain level of empathy and understanding of where people are coming from in their career growth. And at the end of the day it’s not about managing. It’s about leveling up the people. You want to be creating career ladders for people for them to grow.
I think people get into management because they don’t have an alternative, they don’t have a principal track, or because they feel like it’s the only way they can grow in their career — make money, get a bigger title. And they don’t do the bare minimum, which is focusing on your team and your people. Good managers aren’t people who micromanage. They’re not sitting in all the meetings. They let their team grow and go, and they lead with context.
And you don’t just want to be somebody who takes orders. You want to understand the context of the business, so then you can translate that context to your team. I’ve seen teams whose leaders don’t cascade, aren’t transparent, don’t give a full understanding of what’s happening across the company. Those teams really struggle when they’re trying to build the right product. Whereas leaders who are really transparent and guiding people along the way — this is what the thinking is, this is what the strategy is — that gives that team a lot more empowerment.
You can’t always create the opportunity, but are there things you think people can do to be ready to seize it when it arrives?
One is — and I know this sounds more obvious than anything — just say yes to every opportunity someone gives you. If it’s a big project, a teaching opportunity, a learning opportunity, something totally outside your comfort zone, just say yes. Every chance you get to do something moves you in a direction. Maybe you have to take a step back in order to take two steps forward, but I think that’s common. A lot of people will take a step in some weird direction and they won’t know what it means for their career, but eventually it will land you where you want to be.
The other thing is negotiation. It’s not just saying yes to everything and going along. It’s saying yes and then pivoting it so that it works for you. You say yes to a huge project — let’s say you’re an IC and you’re launching a brand new offering. You’re not the only person doing that. You then ask for a team of people to support you. You ask for a project manager if you don’t want to be one. You make sure it’s very clear what your roles and responsibilities are. Because then you’re gaining experience by building the thing, but you’re also gaining experience by working with a whole suite of people you might not have had access to otherwise. And in six months, when a leadership opportunity opens up, you have all of those people there to support you.
Can organizations do a better job of making the IC track a real option for people who don’t want to move into management?
Definitely. If you’re at a startup or a mid-stage company and you’re building out your career ladder, have a principal IC role in that framework from the very beginning. Don’t just have product manager, senior, head of, director — have the IC track built out too. Where I was, we didn’t build that out until maybe two and a half to three years in. If you have it from the very beginning, you give people that option.
But you also have to staff your projects in a way that allows for that role. You’re going to have product managers working in their different verticals, and heads of product supporting them, but you’ll have cross-cutting projects that would be perfect for a principal — a new launch, a big infrastructure change. And I’ve seen companies do that really, really well. You have a huge delivery — people would traditionally put a project manager on that. Put a principal IC on it instead and see how they fare. I think that person, and the business, would be really surprised how well and how quickly it can be delivered.
Lessons from politics
You worked in politics before moving into product. That’s a completely different world — but something translated. What did you carry over?
When I jumped into product from politics, the only translation I saw at first was being able to build stuff with not a lot of money. In politics, you’re always fundraising, always trying to do more with less. So you’re like: how can I do this as scrappily as possible in crazy long hours?
But looking back, there’s more to it. The first thing is understanding the landscape — the context of where you are in the organization. You’re not just within your team or your pod. You’re within an entire company. It’s the same in politics: when you’re trying to change something, you need to understand the context and the ecosystem you’re working within. If you don’t know the external factors, you can’t change what you’re doing in response to what’s happening. Understanding what has been built, understanding the history — that’s a big part of politics, and it’s a big part of product.
The other one is empathy with your users. If you’re building something for an operations team that works in the field in a hundred-degree heat, you have to think of them in those conditions. It’s the same when you’re trying to change legislation: you’re thinking about what really motivates people, why would they want this.
And then there are two more day-to-day ones. The first is reading between the lines. A lot of the time you don’t get an answer to the question you’re looking for. You ask for X, Y, Z and leadership comes back with A, B, C. You have to understand: what’s the line going through here? What can I work with? A lot of the time it’s budget constraints or big shifts within the company you might not be aware of. Understanding that means you don’t get surprised when something happens.
The last one is building and using your political capital. As a product manager, stakeholders will come to you and ask for things last minute when your team doesn’t have the capacity to deliver. Let’s say you decide to push that ticket through, even though your team may be frustrated. But a few projects later you work with that stakeholder to deliver something really complicated and difficult, and they remember that, so those hard decisions and conversations are much easier. It’s all about building relationships and rapport.
Small teams, big orgs
You’ve worked in large organizations and small ones. How does the role of a product leader actually change across those environments?
I actually don’t think that the role changes much, because the fundamentals are always the same no matter where you are. There are a couple of non-negotiables: focusing on your customer — that’s everything you advocate for, building the right product, which is what the customer wants, the right way, which is with engineering. Partnering with your engineering counterparts. And leveling up your team. Making sure you’re building out a structure of capabilities, things that your team needs.
What changes is how you adapt those things to your environment. Maybe you push less on the customer one week and more on your team. Or you wait three months to push on anything because you’re a small cog in a huge machine, you’re trying to figure out where you fit. Or you’re at a startup and on day one you need to publish a 90-day plan — but it actually has to be done in four days. It’s about how you adapt.
The one thing that becomes difficult — probably more so in bigger companies — is how quickly you can get out of the weeds. When you’re at a smaller team, you have more hands-on time. But the bigger you become, the more delegation you do, the less likely you are to understand what’s specifically going on in a given vertical. So you need to learn the ability to drive super deep when needed into a specific area, and constantly work that muscle of getting into the detail. That’s a really key one regardless of where you are.
Working across the technical divide
Your background isn’t technical. Was it a challenge to build confidence sitting with the technical side of product — and how did you get there?
I got really good advice from one of my first managers. We were building out my growth framework, going through this huge list of 20 things to focus on across all these different areas, and he said: “Don’t think about the areas in which you’re weak. Obviously identify those, but look at the areas where you’re strong and can be stronger, and really go all in on those.”
Because we talk about being a well-rounded product manager, a well-rounded person — that’s insane. Nobody can do everything. Really focus on your strengths and become so unbelievably good at them that you are the best person in the room at those things.
On the engineering side: I knew I would never be as good as the senior developer sitting next to me, but I knew I was way better than them at at least three other things. So we would just join forces. That person would focus on what they did best and I would focus on what I did best. I would say, “Listen, I can’t do what you’re doing, but you can’t do what I’m doing. So what if we try to do it this way?” And then we’d find the areas where we could support each other.
So I felt confident in what I knew and what I knew how to do well — and I felt confident in my ability to identify my weak points. It brings you a level of confidence when you can say: I know that I’m not good at this, but I’m willing to learn the basics so I can have an educated conversation with you. So that when you tell me something is going to take a certain amount of time to build, I have the ability to question it. Why? And then why again. And then you’re like, oh, okay, now I understand.
The other thing I learned early on is to bring technical counterparts into your work very, very early — as early as the stakeholder meeting. Someone brings you an idea and a problem, and you go grab your engineering counterpart so they hear it first with you. That’s really powerful because then you’re both starting at the same level. They were in the room with you. And then you can say, this is what I think, and they say, this is what I think, and you come up with a solution together.
People have been bringing engineers into customer interviews for a long time, and they should. But it’s even before that — the bare preliminary information, the very first conversation — because then you’re both at that same starting point and you can really bring each other’s strengths to the table.
AI and the pace of building
How are you using AI in your own work — and is it something customers are actually asking for?
To the question we just had about cross-disciplinary collaboration: I think AI is making that much more possible than it was before. In the past, you’d sit down next to your engineering lead and work through a problem together, but we speak two different languages. With AI, we’re able to speak the same language because we can look up information faster, we can put things into the context we understand and get them back in the context we understand. We’re able to bridge that gap a lot faster — instead of it taking a couple of days, it’s taking a couple of hours.
And that allows you to focus on building, which has also gotten faster. The old adage — I call it the old way, though people still do it — is: you do your research, you write your user story, you get feedback, you do a prototype, you iterate, you go back to engineering and they say this is going to take six months. Now we can cut a lot of that out. We built this prototype together in a couple of hours and it’s really close to what we need — we just have to put it together and spin it up. I think that is already changing the way people build things.
I do want to caveat this: outputs are faster, but are they better? Honestly, I don’t know. I don’t think it’s been long enough for us to see that. I don’t think we’ve had enough outputs from people using it in the field to say that yes, we’re building faster and it’s not breaking in a couple of months. So that’s a big open question.
Where we’re using it most is on the collaboration side, the research side, and prototyping. It’s enabled us to gather insights and translate them into deliverables much, much faster. It’s allowed us to say: we can build the same thing with a fraction of the people. But the cybersecurity, the legality — all of that still exists, and we don’t have an answer for that.
Are customers wanting it? I don’t think customers know what they want with AI, honestly. Everybody is saying they want AI, but they don’t know the difference between generative and conversational, for example. What I think people want is for stuff to get done faster. But my concern is: are those things still going to last? Are they going to break in a couple of months? We don’t know that yet.
Closing advice
Any final takeaways from your experience?
Two things. One is: when you’re making the shift from IC to manager, understand the architecture of what is built — not just individual tickets and stories. What was the product built on top of? What was the thinking behind it? That’s going to allow you to have the bigger picture. If you can understand why everything was built the way it was and the underlying framework, it will allow you to have better conversations than just talking about one feature at the end of the journey. You need to understand the whole journey.
And then from a people point of view: you’re going to work with people you do not get along with. That’s inevitable. You’re going to have to work with people you don’t see eye to eye with, but who are your counterpart and are super, super important. My advice is: make it work no matter what. If you can align on one thing, that’s the thing you keep going back to when you have to build trust. Because you can’t just throw your hands up and say you can’t work with someone. Especially today, with AI changing our roles and our jobs, I don’t think we have the luxury of that. We have to be more creative, and honestly more understanding and empathetic of others.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.