We have all been in a meeting where a team presents a well-researched idea, walks through the data, and makes a clear recommendation. The idea makes sense. Yet by the end of the meeting, there is no agreement on what to do next.
Sometimes the issue is the idea itself. But often, the team has not spent enough time understanding the people it needs to bring along. An eng leader may be worried about reliability. A business partner may see a risk to near-term results. Another team may be reluctant to commit resources because it is already stretched.
I have learned that persuasion starts well before the presentation. It takes work to understand those perspectives, build credibility, and find a path that people can support together.
I was thinking about this while reading Jay A. Conger’s article, “The Necessary Art of Persuasion,” in Harvard Business Review. Conger describes persuasion as a process of learning from others and working toward a shared solution. He identifies four essential elements: credibility, common ground, compelling evidence, and emotional connection.
I have borrowed those four elements as the framework for this post. They are a useful way to think about how product leaders bring people together around a customer problem and make progress across teams.
#1: Establish credibility
When we ask people to support an idea, we are often asking them to make a commitment. They may need to shift priorities, put their team on the work, accept a risk, or explain the decision to their own leadership. Before they do that, they need confidence in the person making the recommendation.
Conger describes credibility as coming from two sources: expertise and relationships. We need both.
Expertise comes from doing the work to understand the problem. For a product leader, that means knowing the customer experience, understanding the data, and being able to engage in the details with engineering, design, and business partners. It also means being honest about what we do not know. If the evidence is incomplete, say so. If a team has identified a risk that needs more work, acknowledge it.
Relationships are built over time, often in moments that have nothing to do with the idea we are trying to advance. Do we listen when a partner raises a concern? Do we follow through on our commitments? When a launch runs into difficulty, do we work through the problem together?
I have found that teams remember how we show up in those situations. A strong presentation may get people’s attention, but the trust we have built with them will shape how they receive the recommendation.
#2: Find common ground
One of the more difficult parts of product leadership is bringing together teams that are all trying to do the right thing but are accountable for different outcomes.
Consider a team trying to improve a checkout experience. Product sees customers leaving before they complete an order and wants to remove steps. Engineering is concerned that changing the flow will add risk to a system the team is already working to stabilize. The business team wants to understand the impact on conversion and whether the work should take priority over other investments.
It would be easy to describe this as a lack of alignment. But each perspective is pointing to something the team needs to consider. Customers need an easier experience. The system needs to work reliably. The investment needs to produce a meaningful outcome.
The product leader’s job is to understand those concerns and find a path that addresses them. That might mean starting with one part of the journey, agreeing on reliability guardrails, and testing the change before committing to a broader redesign. The original proposal may change, but the team can still make progress on the problem it set out to solve.
Finding common ground requires us to listen early enough for another perspective to influence the plan. If we wait until the final review to understand what our partners need, we have made the work of persuasion much harder.
It also requires a willingness to make trade-offs. A compromise should be thoughtful and clear about what it preserves. In the checkout example, the team may agree to a smaller first release while holding firm on the need to improve the customer experience and measure the result.
#3: Bring the evidence to life
Product teams are usually comfortable with data. We track conversion, engagement, retention, reliability, and many other measures. These are necessary to understand whether a problem is material and whether our work is making a difference.
But numbers alone do not always help people see the problem.
Imagine telling a team that customers are dropping out at a particular step in checkout. That gives us a reason to look closer. Now show the team what a customer encounters: they have entered their information, receive an error that does not explain what went wrong, and have to start over. The metric tells us how often the problem occurs. The customer experience helps us understand why it matters.
The same is true when we talk about what we have built. We often describe launches through features, technical capabilities, and rollout percentages. Those are useful details, but we should also be able to explain what has changed for the customer. What can they do now? What is easier? What problem still remains?
Conger’s point about vivid evidence has stayed with me. A good example, a customer story, or a simple demonstration can help people understand a recommendation in a way that another chart may not. The evidence still needs to be sound. The story helps make that evidence easier to understand and remember.
#4: Connect with the people in the room
We like to believe that decisions are made on facts and logic. Those matter, but people bring their experiences and emotions to the discussion as well.
A partner who is cautious about a launch may have dealt with a difficult incident in the past. A leader who pushes back on a change may be concerned about the impact on a team that has already taken on a great deal. Someone asking for more evidence may be trying to understand the risk they will be accountable for.
If we treat every concern as an objection to overcome, we can miss information that would help us make a better decision. I have found it useful to slow down and understand what is behind the concern. Sometimes the answer changes how we approach the work. Sometimes it helps us explain the recommendation more clearly.
The other part of emotional connection is showing why we care. If we believe a customer problem deserves attention, or that the team is missing an important opportunity, we should be able to explain why it matters to us. People can tell when a leader is personally committed to an outcome.
That commitment needs to be balanced with openness. We can have a strong point of view and still be willing to change it when someone brings new information. In fact, being able to do both makes it easier for others to engage in the conversation.
Persuasion starts before the presentation
The more I work across teams, the more I appreciate how much of persuasion happens before the meeting where a decision is made. It happens when we spend time with customers, understand a partner’s concerns, work through a technical constraint, or adjust a plan based on what we have learned.
This also connects to something I wrote about in The Undervalued Art of Creating Clarity. Teams need a shared understanding of the problem, the outcome they are working toward, and the trade-offs along the way. Persuasion helps build that understanding by bringing different perspectives into the conversation.
There will still be times when people disagree. We may not be able to address every concern or reach a solution that gives everyone exactly what they wanted. But we can make sure the disagreement is understood, the trade-offs are clear, and the decision is grounded in the outcome we are trying to achieve.
Conger’s framework is a good reminder that a strong idea needs more than a strong presentation. It needs credibility, a shared purpose, evidence people can understand, and an appreciation for the people whose work and decisions will bring it to life.
For product leaders, that is part of the work. The best ideas get better when we bring others into them, and the teams doing the work are more likely to commit when they have helped shape the path forward.