Influence Is Internal Product Discovery

TL;DR

• Influence is the work required to help a good decision survive contact with competing goals, limited attention, organisational risk, and incomplete evidence.
• Treat stakeholder conversations as discovery. Understand how the decision-maker sees the problem before designing the argument.
• Measure influence by decision quality, shared commitment, and what the organisation learns, not whether your original recommendation wins.

---

Good product work does not speak for itself. It enters an organisation where leaders carry different goals, information, incentives, and consequences.

Influence is how a product leader improves the decision inside that system. It is not manipulation, executive performance, or collecting approval after the real choice has already been made.

The same skills used to understand customers apply internally: observe the situation, ask what matters, test assumptions, and shape the response around the job the person is trying to do.

Map the decision system

Start with the decision, not the presentation.

For consequential work, map:

People can agree on the facts and still prefer different choices because they carry different consequences. A security leader may optimise for containment. A commercial leader may value timing. An engineering leader may be protecting a migration the product team cannot see.

Discover those conditions before labelling resistance as politics.

Treat stakeholders as a research population

Product managers often use curiosity with customers and advocacy with executives. That switch weakens both the recommendation and the relationship.

Before seeking support, ask:

• What outcome are you accountable for this quarter?
• Which part of this proposal creates the most concern?
• What evidence would change your view?
• Which dependency or prior decision am I missing?
• If we proceed, where do you expect implementation to fail?
• What would make this decision difficult to reverse?

These are not rhetorical questions. The answers should be allowed to change the proposal.

Internal discovery also needs sampling. One senior leader's reaction is evidence about that leader, not automatic proof of organisational truth. Speak with the people who will execute, operate, govern, and measure the work. Compare their accounts before generalising.

Earn the right to challenge

Influence without domain authority becomes presentation technique.

A product leader should be the person in the room who can connect the customer problem, operating mechanism, evidence, economics, and main risks. They do not need the deepest expertise in every discipline. They need enough command of the complete decision to know where specialist judgement changes the answer.

Build authority through visible behaviours:

• Bring source evidence rather than unsupported synthesis
• Name the strongest counterargument before someone else has to
• Distinguish observed facts from assumptions and recommendations
• Admit where specialist review changed the proposal
• Return with an answer when you said you would
• Report weak results with the same clarity as strong ones

Trust compounds when people learn that you will not hide inconvenient evidence to protect your idea.

Pre-align consequential decisions

The formal meeting should not be the first time an affected leader sees the problem, options, or trade-off.

Pre-alignment is early discovery with the people whose context can materially improve or block the decision. Share the emerging frame while there is still room to change it. Ask where the logic breaks. Resolve factual disagreement before the group spends meeting time negotiating implications.

Pre-alignment becomes political when it is used to manufacture a majority, exclude legitimate challenge, or present a settled outcome as an open discussion. Keep a clear boundary:

• Seek missing context, not secret endorsement
• Update the recommendation when the evidence changes
• Bring material disagreement into the decision forum
• Give affected owners time to inspect the proposal

No surprises is a useful operating rule. No disagreement is not.

Frame for the decision-maker's attention

Senior attention is fragmented. Restore the minimum context required for the choice instead of replaying the complete project history.

A useful decision brief contains:

1. Decision required: the specific choice and commitment level.
2. Why now: the consequence of deciding, delaying, or doing nothing.
3. Recommendation: the proposed action and the mechanism behind it.
4. Evidence: customer, product, financial, technical, and operating evidence relevant to the choice.
5. Trade-offs: what the recommendation improves, sacrifices, or leaves uncertain.
6. Alternatives: credible options and why they are not preferred.
7. Next boundary: what can be tested reversibly before a larger commitment.

Adapt depth to the audience without changing the truth. A finance leader may need the cost exposure. A platform owner may need the dependency path. A customer executive may need operating responsibility and proof of value.

The story should become more relevant, not more convenient.

Diagnose disagreement before resolving it

Disagreement has several causes. Treating all of them as communication failure wastes time.

Ask what led the other person to their view. Repeat the reasoning back accurately enough that they recognise it. Then identify the smallest point on which the recommendation depends.

Constructive disagreement can strengthen the decision or expose that no shared objective exists. Both are useful outcomes.

Make difficult conversations operational

Avoided conversations turn into delivery risk. A missed commitment, declining performance, unresolved ownership gap, or hidden objection does not improve through softer status language.

Use four parts:

1. State the observed behaviour or decision without diagnosing motive.
2. Explain the consequence for the customer, team, system, or commitment.
3. Ask for the context you may be missing.
4. Agree on the next action, owner, and review point.

Specificity lowers defensiveness because it gives both people something concrete to examine. It also prevents a relationship concern from being disguised as a process complaint.

Use AI without outsourcing judgement

AI can help reconstruct a decision history, compare stakeholder concerns, test a narrative against likely objections, or compress evidence for different audiences. It can also produce false alignment by making every option sound coherent.

Keep the accountable work human:

• Verify summaries against source material
• Do not infer a person's motive from their messages
• Do not fabricate stakeholder support or consensus
• Form an initial recommendation before asking the model to improve it
• Use AI to challenge the argument, not to simulate approval

Sensitive conversations and private organisational context also require an approved data boundary. Convenience does not override confidentiality.

Review the decision, not the performance

After a consequential decision, inspect the influence system:

1. Did the right owner make the decision?
2. Which context arrived too late?
3. Was material disagreement visible?
4. Did the brief distinguish facts, assumptions, and recommendations?
5. Which prediction should be reviewed after execution?
6. Did people commit to the outcome after the meeting?
7. What should change in the next decision forum?

The result may disprove your recommendation. That does not mean the influence failed. A strong process makes the reasoning inspectable and turns the consequence into better judgement.

What influential product leaders look like

The anti-pattern: executive theatre

The team spends two weeks polishing a strategy deck. Difficult questions are removed during pre-reads because they might distract from the narrative. The meeting ends with broad approval and no named trade-off, owner, or next boundary.

Two months later, the functions involved interpret the decision differently. Delivery stalls. Everyone remembers agreeing, but nobody agreed to the same thing.

Influence should reduce that ambiguity. Its output is a better decision system, not a better performance inside a meeting.

The Product Competency Model describes influence proficiency. Empowered Teams defines the authority required to act, while Thinking in Bets makes the evidence and abandonment conditions explicit.