Negotiation Skills for Product Managers: 5 Things You Need to Know

How principled negotiation will get you better results and double your team’s speed

Negotiation is half your job as a Product Manager. Perhaps you haven’t thought of it that way before, but helping teams make any kind of decision is a negotiation. Negotiation is defined as the process of reaching agreement when two or more parties have some opposing interests. Given all the strategies to create, sprints to plan, roadmaps to craft and prioritize, speed vs. scalability decisions to make, partnerships to craft, etc. product managers negotiate all day, every day, with everyone — and getting it right helps speed, outcomes, and team morale. Negotiating everyday situations big and small is core to the PM skill of collaboration, yet almost no product managers get formal negotiation training. This article covers the core concepts of principled negotiation. Even understanding and mastering the basics can make a massive difference to your team and your career.

TL;DR of this article:

• Recognize that Product Managers help make many decisions every day, and that many of these decisions are actually negotiations when two parties have any different interests at all, such as a Product Manager and an Engineer deciding together what to work on.
• Those new to negotiation often think of two types: soft negotiation (focuses on preserving relationships, gets weaker outcomes) and hard negotiation (focuses on winning, may harm relationships). A third type exists called principled negotiation that beats the first two approaches but requires more effort.
• Principled negotiation aims to bring both parties of the negotiation together as a team to find the best outcome in an efficient way that maintains the relationship. This includes the following key elements:
• Work together with people to focus on problems.
• Understand what underlying interests matter most to both parties.
• Generate creative options for solving the problem.
• Come up with the best answer that meets an objective standard, ideally using an external benchmark as a starting point.

Do product managers really negotiate all day, every day?

Do product managers really negotiate all day, every day? Here are some more obvious negotiation examples I heard this week:

• Our designer wants more time to keep iterating, but our engineers expected to start work a week ago. This situation keeps happening and it’s hurting us as a team.
• We presented our prototype to the CEO per her request and she gave us a bunch of feedback and requests that don’t make sense. And she wants an update in two weeks. How do I push back?
• How much should our squad work on the company’s pattern library initiative? It’s distracting us from hitting our primary numbers. I think we might ignore the request.
• We’re really struggling working with sales to define products to sell worth building. It feels like we’ve had five meetings about it and we can’t agree. Or even worse, sales keeps changing their mind.
• Promotion cycle is coming up — it’s my time to get promoted right? I’m hitting all my company goals and So-and-So got promoted.
• I want to hire a candidate but he’s got an offer $10K above what we’ve allocated for this role. I really want and need this candidate. Can we increase our offer?

Sound familiar?

Not all negotiations feel like such a conflict though. More everyday examples include:

• What should our team work on this week?
• What features should we consider and choose for this product?
• Should I attend this meeting (that someone else wants me to attend)?
• I don’t entirely buy into this team decision, prioritization, direction — should I say something?
• Am I getting enough help from my boss, the analytics person, the user researcher, etc.?

We need to negotiate with each other when we believe we have some different interests. Even if we have mostly the same goals, there are usually some slightly different ones as well. Within a team that shares KPIs, product managers may want more meetings, designers may want more design cycles or team design thinking involvement, and engineers may want more test cases written or time to build more scalable code. Interests get less aligned working across different product teams (different KPIs, different timelines and commitments) and different functions such as marketing, business development, and sales (different definitions of success, stakeholders less familiar with product development). You and your boss sometimes have different interests. (How much time does a project need? Which direction to go in? Who gets to make decisions?) Negotiation isn’t inherently a good or bad thing, and many of these negotiations may feel small, but getting to the best answer still makes a difference for speed, morale, and outcomes.

Goals of negotiation

Before we jump into how to negotiate well, let’s take a step back to think about negotiation more broadly. What are the goals of a negotiation? Negotiating for a car or a job offer is different than negotiating what to work on with your team each sprint. A successful negotiation is:

• A good result — one that both sides can agree to and is better than alternatives. Ideally both sides are pleased.
• Efficient — one that takes the appropriate amount of time. Deciding your company’s annual strategy should take more time than deciding what to work on every week. You can often reach a slightly better result with many more meetings — but is it worth it?
• Relationship-maintaining. You’ll have to negotiate with your team all the time, so a good, efficient result for you today that breaks your team’s trust and morale will harm your future success. See the prisoner’s dilemma as a famous example of single vs. multiple event negotiation.

Tip: many only consider their goal in negotiation as getting the best result for them, not these other important goals. Know these goals yourself and repeat them to others.

Types of negotiation

Now that we know what we want the negotiation to achieve, let’s review different types of negotiation. Many people think only of the first two types: soft and hard.

1. Soft negotiation: optimize for relationships. Be agreeable to get along, accept a less than optimal result for yourself to avoid conflict. Accept the first offer, or accept others’ changes to reach agreement quickly and easily. A product manager who everyone gets along with, but struggles to help the team get results.

2. Hard negotiation: optimize for results. Push as hard as you can at the expense of others. Never accept the first offer because you can almost always get more, even if it requires more time and conflict. A product manager who initially helps drive team results but is considered unpleasant to work with and unmotivating.

By only considering these two approaches, many people are even uncomfortable with the word negotiation and think of battling wills, shouting, and bullying. Generally hard negotiation beats soft negotiation.

While all of us can be soft or hard negotiators if we need to, we actually tend to have different preferences. See TKI conflict mode preference to learn more about different preferences including your own.

There’s a third type of negotiation though:

3. Principled negotiation: optimize for an objectively good result, reached efficiently while maintaining relationships. A product manager who gets results and brings her team along with her.

While hard beats soft in negotiation, principled beats hard.

I’ve found that once you start framing your daily negotiations in a principled approach instead of a battle of wills, negotiations feel a lot less stressful or personal.

What is Principled Negotiation?

To introduce principled negotiation, I’ve adapted some components of Fisher, Ury, and Patton’s foundational book Getting to Yes for product managers. I read this book every couple of years and it’s on my top five list. Here’s the summary, and let’s use an example of a squad that owns a part of a site/app negotiating with an ad sales team about what new native ad products can be sold that won’t compromise user experience:

1. Focus on problems vs. people

• Leave assumptions and blame behind, and frame the two sides as a team working to achieve the best results.
• Example: How can the squad and sales come up with the best products together that meet both their needs? Treat each other as one team serving the company’s multiple needs, even if past relationships have been bumpy or contentious.

2. Understand positions vs. interests

• Share and understand each side’s true underlying interests so they’re both solving the same problem.
• Example: What is the sales team really looking for to serve their clients — branding vs. performance, reach vs. depth, prominence or not? Minimum incremental revenue? Why is the squad nervous to build for sales — effort, user experience, performance, brand perception? Many of these anxieties are actually measurable.

3. Generate options

• Recognize that what can seem like a zero-sum, one dimensional negotiation usually can be broken down into a basket of several needs and asks, with different values to both sides that provide more options to reach a better negotiation result.
• Example: Consider performance vs. branding, beta test different options to reduce risk, limit timing of biggest risk asks, offer valuable reporting or other services, connect to packages across other products.

4. Use objective criteria

• Mutually agree on objective criteria that will help both sides agree on a fair answer, this time and in the future. Avoid anchoring and positional negotiation. Make sure criteria will be measurable and trackable.
• Example: Use historical performance benchmarks for acceptable product impact and client success bars, and make sure the values will be measurable during the ad program.

5. Negotiate

• Now the negotiating begins — work together to fully solve the same, most important problems with the best aggregate results
• Example: Whatever emerges as the best option that meets both sides’ needs — e.g. a package with a visually prominent native placement in a low performance impact part of site, a lower-key but highly performant native placement with acceptable decrease in other key site behaviors, and valuable new user insight shared with client.

This approach applies for a product manager (or any other professional) within an organization, and more broadly across all negotiations. The only main disadvantage to principled negotiation is the extra time and energy it takes to get it right instead of using a quick soft or hard negotiating approach.

Principled negotiation works particularly well for product managers as they generally work inside performance-oriented, quantitatively-focused, data-measuring organizations that should care about achieving measurable outcomes.

Closer look 1: Focus on problems vs. people

Often a negotiation quickly turns into two people arguing their own positions, feeling defensive of what they think is right. Does your engineering partner need to defend her 10% time against the Product Manager’s desire to do more feature work? Does your boss want to take credit to look better in front of the CEO vs. your wanting your team to get credit for your work? Anytime we get to an “us vs. them” situation, we’re already off track. This type of setup even includes negotiating for compensation or title. And it often treats the negotiation as a zero sum game.

When we focus on getting to the best result — how should the team allocate time, who should present and get credit, what compensation or title should someone get — we can separate the issue from the people on each side. I love this framing because it allows two parties to sit on the same side of the table to try get to the best result, instead of sitting on different sides of the table attacking and defending. This approach even works well for more emotional or zero-sum seeming topics like compensation or performance improvement plans.

To get both parties to the same side of the table, it helps for each side to understand each other’s mindsets and expectations and to empathize with one another respectfully. If your partner believes you are listening to him and understand him, he’s much more likely to want to work with you to get a good result. If a product manager’s partner engineers and designers don’t believe that the product manager cares about their input or listens to them, they won’t willingly work together to figure out the team’s best answer, being concerned that the product manager is unreasonable, unfair, or just a jerk.

At this point in the negotiating, you’re listening and understanding, not debating or judging. No blaming or getting emotional as these actions can make your partners defensive and halt the healthy process. That said, it’s entirely reasonable to acknowledge that emotions exist and might be running high, so that the team can get past them. E.g. “I know I provided messy product specs that created a big bug last week. I’m sorry and I can imagine that you’re upset with me. I’ve learned my lesson and will try my hardest to correct the issue. I’d love to hear what you’re actually feeling and thinking, so we can work together to come up with the best plan this week together.”

Bonus reading: Difficult Conversations is a marvelous book about having productive conversations in emotional, challenging situations. This book goes hand-in-hand with Getting to Yes.

How I help my teams focus on problems over people

• I constantly reiterate that we’re on the same team, here to help the company succeed.
• I affirm that we’re here to get the best answer together, and that we’ll only figure it out together.
• If the room’s feeling emotional, I might call out “I sense some tension in the room and I’m hopeful that we’re going to get through it to succeed as a team. I’m feeling […] — I’d love to hear what you’re feeling and thinking about.”
• I repeat back what others say to show my understanding and empathy and confirm that I’ve got the right picture.
• I involve others early in potentially tricky or controversial decisions/negotiations, such as organizational changes or performance problems, to reduce surprise/defensiveness and bring all the voices and ideas in early.

Closer look 2: Understand positions vs. interests

What are positions and interests? Positions are things that people say they want, such as “I want to change teams.” Interests are the reasons driving the discussion that really matter, such as “I’m unhappy because I feel unvalued on this team.” The important takeaway is that we only make different sides happy by solving interests. So if someone changes teams but still feels undervalued, both that person and the team lose out.

Just as important, by revealing interests we unlock win-win, greater than zero sum opportunities. A common example is two kids fighting over the last orange. They fight and fight until mom asks them why they each want the orange. One wants to eat the fruit and the other wants the rind for a school project. Mom gives the inside to one child, the rind to the other child, and saves the day!

In a tech company example, I’ve seen different teams fight for placement on the home screen/page, with one wanting performance and the other wanting product awareness — both problems can be solved simultaneously. More commonly, teams often negotiate around sticking to a launch date or not. Do we stick to a launch date because we promised the CEO, even if the quality isn’t as high as we’d like? Or do we ask to move the date because we’ll have a better product? The best answer could go either way — for example the launch date may be internally shared only and easily movable, or externally shared with a big sunk cost marketing campaign that’s unmovable. Is the product really far off from desired launchable state, or is the team too perfectionist? Etc.

One easy way to work towards interests is in the old saying “Don’t come to me with a solution, come to me with a problem.” (Common mistake of early-tenure product managers.) If the CEO asks a team for a specific solution, or the product manager proposes a specific solution to the team, best practice is to focus on the problem and almost never to just build the solution.

I have a pet peeve when someone won’t reveal his interest (often because it’s an unreasonable interest), and when I successfully argue against his position, he shifts to a different reason/position to try to get what he wants. Mostly this applies to my six-year-old son trying to stay up late or eat candy.

How I help my teams focus on interests over positions

• I constantly ask what’s the problem we’re solving, and why.
• I state “my explicit interest is …”
• We constantly reiterate outcomes over outputs, which makes it easy for us all to check if we’re really moving outcomes.

Closer look 3: Invent options

People generally want more than one thing in a negotiation. Building a product can have many needs — brand-fit, usability, delight, on-page click through, conversion, retention, visibility, interconnectedness, duration, measurability, etc. With all these different elements that can be used to come up with a solution, I find that inventing options to solve both side’s interests can be the most fun, creative part of negotiating.

In building products, I love to use design thinking such as design studios (<1 day) or design sprints (5 days) to come up with creative options for our toughest problems. Naturally, this part of the negotiation process has the potential of taking the longest, so spend the appropriate amount of time on this step.

One important thing to note when exploring options is that usually something matters more to one side than the other with each individual point. In negotiating a product marketing launch, Marketing may care more about visibility than actual size or on-screen performance. Identifying these asymmetries helps both sides reach the best total outcome later. What’s high value to you that’s low cost to me, and vice versa?

Common product areas to invent options include:

• Scope
• Duration
• Visibility
• Performance
• Risk sensitivity
• Scalability
• Reporting
• Degree of customization vs. shared components

How I help my teams invent options

• Brainstorm options early in the morning when we’re fresh.
• Whiteboard out the problem and break it down into components.
• Ask each side what matters most to them and why.
• Using design thinking tools as appropriate.

Closer look 4: Use objective criteria

Now that we’re on the same team, we know what we’re solving, and we have creative options, how do we actually decide? The most important point for me here is using objective criteria instead of arbitrary starting positions.

Imagine two parties are negotiating an agreement for a carpet, a painting, a house, a salary, or a company acquisition price. Most commonly, the buyer starts low, the seller responds high, and they slowly converge to an answer in the middle. (Or the seller starts then the buyer responds, with subsequent back-and-forth to the middle.) This type of negotiation is called positional negotiation. Don’t do it! While the result might feel good at the end in that the two parties worked together to come to an answer closer than their starting positions, this result becomes anchored to the starting values independent of if they’re the right values. (The anchoring effect is a real cognitive bias that has been proven to affect everyone!) Is the ending result really fair? Just because the car dealer lowered his price to you, is it a fair price?

The better answer in this example is to come up with something fair, ideally an external standard, to set the objective starting value of the carpet (search online for the same or similar carpets), painting (look at painting prices for the same or similar artist + form factor sold recently), house (search for market values), salary (search for salary bands per level in your geography), and company acquisition price (look at other recently sold similar companies for similar reasons) and negotiate around that value. This explanation is little simplistic, but serves as a great starting point. One example I love: two children argue over how to share a piece of cake between themselves. A fair standard is to let one child cut the cake, then let the other child choose the first piece.

Both parties should agree on the objective criteria together, ideally an external standard. If the two sides can’t agree, sometimes they’ll need to call in a third party to make the call. (In the cake example, the children can ask a parent to cut and divide the cake.) If both sides agree, without feeling pressured, then the negotiation has all it needs to run smoothly from this point on in most cases. For example, as a Product Manager, you might have your team agree on what to work on as 70% product innovation/iteration ranked by ROI against the team’s single KPI, 20% risk mitigating tech/design/product debt chosen by the engineering lead, PM, and designer together, and 10% creativity time.

One great benefit of setting up objective criteria is the reusability of this standard in the future! If your team agrees how to prioritize work this week, you can use that same approach every sprint unless the team’s or organization’s needs change.

Ways I help my teams use objective criteria:

• Ensure teams have clear, unambiguous goals.
• Focus conversations on outcomes over outputs.
• Publish KPIs publicly.
• Publish results publicly to compare against initial estimates and to help with future estimates.
• Ask teams to escalate quickly when they have trouble agreeing on objective criteria.
• Build a culture of measurement, estimation, and retro-evaluation.
• Always be open to changing goals or perceptions with new information.

Closer look 5: Negotiate

The hard work is over. You’re working together, with clear, well understood goals. You’ve surfaced creative options and have an objective way to measure success. Finish the negotiation with your partner, and appreciate the work you’ve done together. Next time you’ll be able to move through these steps much more quickly.

Working in agile sprints requires negotiation. Working on quarterly roadmaps requires negotiation. Working on annual strategies requires negotiation. Generally the first time feels quite effortful. Personally I’ve made the waterfall to agile transition three times, and the top down planning to bottoms up planning transition three times. Someone more experienced than me told me to have faith in the process, but that the first month would feel rough. The first month was rough every time, but subsequent work felt an order of magnitude easier — faster, more confident, more harmonious, and with better results. Many of you have felt this gain too with such transitions.

When you extend negotiation to all your product manager decisions, I hope you can see how principled negotiation will get you better results and double your team’s speed.

Product managers who master the basics of principled negotiation help their teams make better, faster decisions and collaborate better across the organization. Those without this skill tend to spin more, waste team time, get blocked when working outside their teams, and ultimately achieve weaker results. Outside product management, I’m regularly surprised at how successful, senior leaders in different companies miss the basics of principled negotiation, often sticking at point one around separating people from problems. Master this skill and you will be more successful. And if you can, help get negotiation training added into the education system, it’s a skill we all need!