Alongside my Product role I am a sustainability champion. As a champion, I identify areas where we could do better, set a strategy to help us achieve those goals and then put initiatives in place to move us towards them.
Some of that is about building knowledge across the business and helping people understand how they can work more sustainably. I also manage a network of colleagues in local offices who can take some of this forward where they are. But I do not have authority over everything needed to make those initiatives happen.
Some require funding or decisions from elsewhere in the business. If, for example, we want to create more opportunities for people to take volunteer days, I need to speak to the Managing Director and leadership team. I can identify the opportunity, explain why I think it matters and work out how we could take it forward, but the decision is not mine.
That is a fairly clear example of leading without authority.
Product Management often feels similar, although the boundaries can be much less obvious, particularly in complex government programmes where the decisions needed to move a product forward sit across different roles, teams and governance structures.
A Product Manager may have a strong view on where a product should go and what users need, while still depending on decisions made by Delivery, programme leadership, policy, operations, commercial teams or other products.
We normally describe this as influencing without authority. I think that is right, but I have become more interested in what sits underneath it.
If something is not moving, I do not always need to become more persuasive. First I need to understand why it is not moving.
Where the decision actually sits
Government Product roles make some of this visible.
The Product Manager may be responsible for the direction of the product, meeting user needs and setting priorities, but that does not mean they own every decision needed to deliver the outcome. There are good reasons why authority is distributed across different roles. I see this quite often between Product and Delivery.
Risks are one example. Product may have a strong view about how a risk should be highlighted or what action needs to happen to mitigate it, while more of the responsibility for managing that risk sits with Delivery.
Dependencies can be similar, particularly when they involve other teams and are being managed through the wider programme. I can identify that a dependency is creating a problem for the product, but that does not mean I control how it gets resolved.
Roadmap sequencing can become more contentious. Product may be working from user research and identified user needs, while programme leadership is hearing different priorities from senior stakeholders. Those priorities can conflict and at that point the problem is not necessarily that one side has failed to communicate clearly enough. We may simply be trying to achieve different things.
That is where I find it useful to understand who is actually making the decision, who is shaping their view and whether the person I am speaking to can change the thing I need changed.
Influence is wider than the decision-maker
If I know a decision ultimately sits with somebody else, I normally start with the team.
I want to bring with me the people who are closest to the problem because they usually understand parts of it that I do not. I want to learn from them, work out what I might be missing and understand how best to articulate why a decision is needed and what impact it will have.
That helps me build a better case, but it also means I am not approaching the decision from a Product perspective alone.
From there I may use existing networks or speak to people I know who can help influence the decision-maker. I also think about whose voice is being heard.
Different people around a decision can carry different levels of influence. A senior stakeholder, an operational colleague, an architect or somebody in programme leadership may all shape how the problem is understood before the person with formal authority makes a decision.
If the people around the decision broadly understand the problem and are reaching a similar conclusion, it becomes easier for the decision-maker to move. If Product is saying one thing while everybody else around them is describing the situation differently, the opposite is true.
That does not mean everybody has to agree. There can be good reasons for disagreement and those should remain visible. But influencing without authority is rarely just about persuading one person.
The people around the decision matter as well.
Knowing when influence is no longer enough
Some situations can go on for too long because everyone is still trying to find agreement. I do not have a formula for knowing exactly when to escalate. Some of it is gut feel.
Usually, I start to notice that we have had a number of meetings and the issue is still not moving. The same conversation is happening again, time is passing or there is increasing pressure to make a decision because other activity depends on it.
Time matters here for another reason as well. It is not only about how long we have to make the decision. I need to think about what still has to happen afterwards and how much time there is left to enact whichever route we choose.
If a decision keeps slipping, the options available can start to narrow because there is simply less time left to implement them. That is often the point where continuing to influence at the same level stops being useful.
Someone may agree with me but still not have the authority to act. Two parts of the programme may understand each other’s position perfectly well but still be working towards different priorities or the decision may sit with somebody who is not yet involved. At that point another meeting with the same people is unlikely to change very much.
Escalating the decision
When I do escalate, I try to give the person the situation, the options available and what I propose we do next. I also want to explain why I think that is the right route.
That does not always need to become a formal pack or a long piece of governance material, it may just be a conversation.
At other times, I will use visual material to show the impact of the decision and what would happen next depending on the route we take. That can be much clearer than trying to describe a complicated set of dependencies or consequences verbally.
The important thing for me is that I am not just passing the problem upwards. I want the person making the decision to understand what needs resolving, what the realistic options are and what I think should happen next.
There may still be legitimate disagreement. Product might be protecting an identified user need while programme leadership is dealing with commitments coming from senior stakeholders. Delivery may be managing a risk in a different way from the one I would choose. None of this requires somebody to become the difficult stakeholder.
Sometimes the decision simply needs to be made somewhere else.
What this has changed for me
I still rely heavily on influence. In sustainability, very little would move if I could not build relationships, explain why something matters and get other people interested in making it happen and Product Management is no different.
But I no longer think that a lack of progress automatically means I need to try harder to persuade somebody. I am more interested in understanding where the ability to change something actually sits.
That might mean speaking to the person with formal authority or bringing the team with me first, understanding whose voice is shaping the decision or using people in my network who can help move the conversation forward.
It may also mean recognising that the issue is stalling, that time is becoming important and that the people currently involved do not have the authority to resolve it.
Before putting more effort into influence, I increasingly want to know whether the person in front of me can actually change the thing I need changed.