# Bridging IC to Leadership: Directional Clarity and Strategic Horizons

**Podcast:** All Things Product with Teresa and Petra
**Published:** 2026-07-07

## Transcript

Hi, folks.
This is All Things Product with Petra Wille.
And Teresa Kors.
And we're so happy you're here.
Petra, I wanted to ask you about a question that I feel like has been circling for decades and nobody has a good answer.
It's this challenge of like you're an individual contributor.
You really want to step into a leadership role.
Nobody wants to hire leaders that don't have leadership experience.
What can somebody who's like a super icy, like they're very motivated, they feel like they've reached what they can in that role and they really want to be in a leadership role.
Yes, a peak product manager or designer, whatever the role is.
What can they be doing to be ready for their first leadership role?
That's a great question.
I love how you frame it in nobody had the answer for ages and now you asking the answer in a casual podcast episode to me.
So let's see how we can unpack that.
Yeah, the tricky ones.
We're going to answer all the hard questions for people.
Yeah, I love it.
What would my advice be?
So various things.
I can walk you through all of them.
First of all, I...
would see if I can get a hold of anything that talks about leadership responsibilities in your organization.
So that gives you a bit of a compass, for example, what is the leadership role all about?
So what are responsibilities of somebody in a leadership role?
I have some in my managing up talk, for example, we can make sure to link that here so that people can find some if they don't have some in their HR drawers, basically.
But these are things that the organization thinks a good leader has actually to do, to show, to prove responsibilities that they take on in a leadership role or leadership position.
My product leadership wheel, for example, is structured around 12 responsibilities as well.
So that is one thing.
Let me just pause you there because I want to distinguish between a couple of things that you're saying.
Yes, please.
have an understanding of what is expected of leaders.
And you personally have a couple of frameworks around this, your leadership wheel, you give a managing up talk where you talk about what you should expect from leaders.
But I think there's something you said that I just want to underscore because I think the most important part of what you said is you have to understand what your organization expects from leaders because it differs from organization to organization.
And I think this is like, It would be great if your HR department had said, these are the leadership attributes we expect of our leaders, but that doesn't always exist.
So I think we can start from a more general leadership framework, but what can people do to learn about what do their companies care about?
So the easiest starting point if you're in a bigger organization is to ask if there is a leadership training curriculum or something like that, because that usually tells you a lot about what trainings they send newbie leaders to.
Is it more the time management, project management, all these kind of management things?
Or is it more finding your voice, leadership, personality?
Is it more a leadership thing or more a management thing that your company wants, for example?
This is something that you can understand if you look at such an...
onboarding curriculum or leadership training curriculum and usually you can find it somewhere in your company's wiki so hr is usually not hiding them from from the rest of the organization sometimes they even advertise with it so that's an easy one to find And then if you don't find it in the wiki, then go ask people that have stepped into a leadership position within the last three-ish years, because they can usually tell you like, oh, there is actually quite a good framework that we inherit and then use big consultancy organization, Gallup, for example, Conferry, for example.
So companies like that sometimes help organizations to define their leadership roles and leadership skills that they want to see.
And that is sometimes where the junior leaders in your organizations could still point you to because they most likely still know like, yeah, yeah, yeah.
We were at this one particular training day and there was this trainer from this one particular company and they had a framework and it's.
I don't know.
And then it's called something like For Your Improvement by Korn Ferry and talking about one million skills and how to assess them.
And sometimes it's captured like in corporate values too, right?
Like, yeah, that could be the case as well.
Yeah.
These are the attributes we care about.
Amazon has a publicly available page with their leadership principles, for example, of which of which.
One of them is, and it's widely known as this disagree and commit.
I think it origins from there.
And so it's principles like that.
So in a leadership position, you need to be able to still lead the change, even if you don't commit to the change or not necessarily agree with the change that has to happen.
So that's, for example, one of these examples.
So, yeah, exactly.
That's the stuff that you want to look for.
And with that, you can build a bit of your compass of what leadership means in your environment, ecosystem, company context.
Yeah.
And again, there's never harm in finding a mentor in a more senior leader.
And they might be a good source for these kind of conversations as well.
Yeah.
Okay.
So step one is sort of learn a little bit about what is expected of leaders, both generally and then also specific to your organization.
Yeah.
And I would in the beginning not stressing out too much about this definition because it can seem like a big stretch goal if you're still in an individual contributor role.
So put it up somewhere.
You can stick it in your notebook.
You can put it in your Claude Code MD files, wherever you want to put it and keep it.
Obsidian folds.
But don't stress.
too much about it.
What is more important is that you start to practice some of this core leadership skills that need to really go into your muscle memories and really become this kind of more okay, I'm really good at doing this.
I can do that.
And for me, one important one, easy to practice in an IC level role is to saying no to things in a very appropriate way where people understand where you're coming from, even if they're not necessarily agree.
Again, it's a bit of a, yeah, I agree with your sentiment.
I don't like your sentiment maybe, but you have explained it well.
So why are we saying no to a specific feature?
Can you explain it well?
Why are we saying no to a more strategic initiative?
Why do we say no to sunsetting this product?
So all of these cases that you usually have in a product management role.
So get really good and not only saying like, nope, and being the firewall, but also explaining the why, coming with evidence.
That's another thing.
So allow people to always double click on your nose.
So if somebody says like, I don't get it, then you're like, don't worry, I have a lot of data or here's a bit of evidence or this is why we're saying no.
So that's one thing, bring the data.
And then if you can practice to provide this directional clarity.
So always practice to say like, hey, you know, this is where we're currently headed.
And if you're still in a product management or design role on a team, then that might only be the direction of clarity for the next four weeks, right?
Because this is maybe the horizon that you're currently comfortable managing.
And then you might want to go to a quarter at some point, comfortably saying like no two things in a quarter and why and providing direction of clarity for the quarter that is beyond the one that you're currently working on.
And this is how you grow.
basically your leadership horizon, your strategic horizon to some extent, and really by practicing this art of saying no in good ways to stakeholders, to users, to whoever is coming to your desk, executives, board members, whoever shows up, practice saying no to them in constructive ways, I'd say.
Yeah, so this is such a like...
product management trope almost that like the product manager's job is to say no to everything except for like the very small number of things that are going to have an impact.
And I think it can be really misunderstood.
Like I think product managers tend to get themselves into trouble when it looks like they're saying no because they don't like your idea.
It's like you're just making things based on your preferences.
And so it sounds like what you're saying is Saying no is the easy part.
The hard part is how do we communicate almost a sense of procedural justice?
Like what are the rules we're using to decide what we say yes to?
What do we say no to?
Yeah.
And one thing I have found is that you almost don't want to say no.
You want to say, here's what we're doing.
And show that there's no room left for that thing that's being suggested.
So it's a little bit of a way to do so.
Yeah.
So it's a little bit of like, and I think this is part of your directional clarity.
If you can clearly communicate, this is our goal.
This is our customer.
This is our strategy.
Here's how we're going to get there.
Then when somebody comes in with a distractor.
You can say, remember, this is our goal.
This is our customer.
This is how we're going to get there.
And you're almost like helping the other person say no to their own idea.
Yeah, that's the ideal scenario.
You still want them to come and share with you.
So you don't want to send them away forever.
But yeah, still, if they could answer the questions themselves, that would be beneficial.
Exactly.
That is the direction of clarity.
Then directional clarity is given, right?
understand the moment they have the idea how you would assess it and what you would be saying about it, then you have like direction clarity given, I'd say.
Yeah.
And that's something that you can practice.
Yeah.
This directional clarity piece seems like the crux.
Like if I can, and this also seems like a really big leadership skill.
How do you clearly say we're going in this direction and here's why?
Yeah.
Then I feel like if that's in place, all this other stuff gets a little bit easier.
Maybe not easy, but a little bit easier.
Easier.
You talked about, like, if you're an individual contributor, you might be responsible for setting directional clarity for a couple weeks.
Like, if I'm defining a sprint, I'm defining directional clarity for that sprint.
So, like, one way I can grow is, can I provide directional clarity for two sprints, for three sprints, for four sprints?
How do I balance this with the fact that I might learn something in the next two weeks that changes my directional clarity?
Yeah, that's not a, that's usually not a problem.
Because the moment you get better in looking further out.
You get better in being more meta and less concrete about the things that you're working on.
So you go from a backlog item to maybe an epics level or opportunities level or however you would call that level.
And then you talk about, hey, that's the outcomes that we're trying to drive more than actually the features that you're going to build.
So with looking further out, you moving up on the mental model that I'm using for that here, by the way, shout out Martin Erickson.
It's the decision stack.
So I'm going up the decision stack, basically, the further I'm looking out on the timeline.
And this is how you still can react to changes because then you might be learning something and you might want to ditch the two features that you were planning to do, but that has no impact on the outcomes that you still want to drive for the quarter.
So when you move further out on the timeline, you have to move higher up.
on the artifacts that you basically look at for your directional clarity.
Yeah.
And it gets a bit more meta.
It's another thing that you could practice being more comfortable with things not being very, very concrete and super clear what to build, not so feature-based.
It's a bit like when we talk about this problem discovery, solution discovery, implementation discovery, right?
So it's different levels of similar work, I'd say.
Yeah, I recently wrote a blog post about this where I took Jana Bastow's Now Next Later roadmap format and combined it with an opportunity solution tree.
So in the Now column, you have solutions.
In the Next column, you might have opportunities.
You don't know what solutions you're going to build yet.
And in your Later column, you might just know the outcome you're going after.
You don't really have even an idea of opportunities.
And I think this is...
It's just to like clarify what you're saying.
You're not suggesting to grow your leadership ability.
You need to have a 12 week roadmap, a three month roadmap, a six month roadmap, a 12 month roadmap of features.
Because that's not like feasible.
That's not really what you mean by like think further down the road.
It's that the further down the road you get, the less concrete that directional clarity is.
Yeah, in the talk.
Yeah, and the talk that I'm giving, I use an old video from the 70s from Ray and Charles Eames, where they zoom out from a picnic blanket in New York Central Park.
I think it was.
Anyways, park somewhere.
And they zoom out from this picnic blanket.
And I think this is exactly the metaphor that I want people to use, because in the beginning, in the first frame, you still see what food the people on the picnic blanket are having.
And then you zoom out and then you just like see two people are having a picnic.
You can't see what they're actually having for a picnic.
And then it's zooming out and you see like there are people in the park and you don't specifically see the people having the picnic there.
And I think this is exactly the exercise.
So you need to be able to let go of some of the details while still talking about enough context so that everybody can relate to the things that you actually want to say.
And that's what I say with directional clarity is provided in...
different ways on different abstraction levels.
And that's another thing that one could start practicing while still in an IC level role.
Yeah, I actually think it's even helpful to practice this even with your near term work.
So even if you know exactly what features you're building, you still want to communicate.
This is the problem we're solving.
This is the outcome we're trying to impact.
Because what it does is it gives you a lot of flexibility.
Like let's use your picnic example you were planning to make.
barbecue chicken and potato salad and you go to the store and there's no chicken available.
You need to switch gears.
It doesn't mean you got to cancel the picnic.
And I think this is where being able to communicate at all these different levels, even in the near term, helps with creating stability in your directional clarity, even when everything around you is changing.
Yeah, indeed.
Yeah.
And it helps you to stay oriented.
when things are changing.
And that's such a crucial leadership trait because you will be basically the rock in the chaos.
And people will kind of realize, okay, Petra always is very good in quickly sorting out things.
She seems to have a model for it.
I don't know how she does it, but always things make sense after her looking at it for a minute.
And that's what you want to practice.
Yeah.
What?
This might be a hard question, but I think I want to like touch a little bit on before we wrap up, like how do we find the right directional clarity?
That so much depends on how much agency you're able to take within the organization you're currently working for.
And again, I think leading by example never does any harm.
So if you can provide all this context for your work, then always do.
But in some organizations, it's easier.
Their product people and their teams, for example, own the entire product strategy, including the profit and loss and all these kind of things, right?
For them, it's way easier to zoom out and it's way easier to provide the directional clarity because they see all the data that they need to see and they can talk to customers.
Let's assume that is given in that organization as well.
So they can even create a lot of evidence for the things that they're planning to do or for the things that they're planning to kill or whatever, right?
When other organizations, so many of these things are super tricky, not given, not allowed.
And we have episodes, people, how you could still get the most out of your customer conversations, even if your company doesn't want you to.
But it's the reality of some product people that basically what they own is still this backlog and maybe a roadmap.
And then it is harder for you to provide that directional clarity because then oftentimes your company don't have this level of sharing data with you for you to make sense of things properly.
Then it's hard for you to come up with an even napkin sketch of a product strategy because you're just like lacking all the economics for your product.
It really depends.
Don't get frustrated too easily.
But you could always really, I always think it does make sense to start with the people that you try to provide the directional clarity to.
So how would their workday improve?
How could a stand-up be improved by you providing a bit more directional clarity?
So we think like 5% improvement, maybe not 100% improvement.
And that's why that question is a tricky one.
And that's why it looks so different in every organization, basically.
In an ideal scenario, I think it is product team, product person responsible for product strategy, including profit and loss, being able to talk to customers, being able to be really good in the competition and the market and all these kinds of things.
That's the easiest.
setting for being able to provide people with direction and clarity.
Then it's just a matter of storytelling skills if you're succeeding in convincing others that the bright future you see is the bright future that they should actually working towards.
I think even in the scope where maybe the team is being told exactly what to build and they don't have, they've never seen a P&L.
They may not even know what a P&L is.
They don't really understand.
I've worked with teams where they They're basically are working on a value add product and they don't really understand even the nature of the value add product.
There's no revenue model behind it.
It's just all the business context is murky.
I think most of the time the product manager has more business, more exposure to the rest of the business than the rest of the development team.
Indeed.
So like, even if your scope is really narrow, you probably know more.
that you can rely on to set that directional clarity for the rest of the team.
And then I think you can build your skill by showing up with some curiosity and asking questions and learning more about that business context and growing your own lens, your own view, widening your own view so that you can bring more of that to the team.
Yeah.
Yeah.
I like that framing a lot.
Yeah.
Amazing.
Yeah.
All right.
Maybe we wrap it up, right?
Yeah.
I think this has given some people some nice, like, actionable things to practice just start with uh can you think about how to just give a little more directional clarity than you are now and then how do you practice that and how do you keep doing that good i like that thanks