How to negotiate with product managers (and why you should)
I recently gave this talk to
and would like to open up the conversation to a broader audience. Like most tech talks, mine started out with a meme:
Most of us can relate to this on some level, but the truth is that PMs and engineers actually aren’t adversaries. In reality, a PM can be your biggest ally for managing scope and increasing development velocity.
Now, I’m not saying tension doesn’t exist. It’s the PM’s job to figure out where the product should go, while you’re responsible for getting it there as quickly and safely as possible. Because the destination is often a moving target, naturally, conflicts arise. But, it’s possible to work with this tension to get better results for everyone.
For example, I recently spec’d a feature that required some user education, so I included a tooltip. When we reviewed the spec as a team, our engineer pointed out that building a tooltip in this part of the UI would be possible, but harder than usual. She then suggested that instead of a tooltip, we animate some icons to teach people how to use them, which would be much cheaper to build and still achieve the same goal. Awesome.
It seems simple, but I’ve worked with plenty of engineers who would have just accepted the spec as is and spent too much time trying to make that tooltip work. Many of them assume that not building the tooltip would make them look lazy or incompetent or antagonistic. In reality, identifying opportunities like this that save time, and effectively communicating that to your team, is a sign of leveling up.
So, how can you push back in a way that consistently leads to better outcomes instead of conflict and resentment? The key is for both sides to consider the spec merely a starting point for negotiations. Here are some tips to help you navigate the conversation from there:
Understand the problem
Like most negotiations, the best way to start is by listening. Your PM has likely done some research — talked to users, analyzed data, studied competitors, etc. — and they can provide you with the context necessary to fully understand the problem you’re trying to solve for the user. Spend some time digging into this together.
Agree on goals
Most of the time, the PM’s goal isn’t to deliver a complete solution to the user’s problem in one big launch. They’ve more likely mapped out a series of incremental releases and hope each one teaches them something new about the direction they’re headed. Once you know what they’d like to learn each step of the way, it’ll be easier to make decisions about what exactly to build (and when) to get that data.
It’s equally important for your PM to align with your goals — whether it’s minimizing code complexity, cleaning up tech debt, improving security, etc. — let your PM know your top priorities so they’re better able to support decisions you make about how to build a feature. Doing so will help you avoid disagreements over when to do the quick, cheap thing vs. invest in something more stable.
Bring your expertise to the table
As an engineer, you know better than anyone all the different ways to build a feature and the tradeoffs associated with each approach. Once you’ve chosen the appropriate technology to get the job done, you can continue providing value by calling out limitations of that technology and challenging your PM to reconsider their requirements based on this information, which may be new to them. Constraints are often very helpful, so don’t be shy or apologize for pointing them out. And, don’t worry about figuring out a workaround before raising an issue (see next point).
Get creative together
Once everyone is aware of constraints, now it’s time to find creative ways to work within or around them as a team. Going back to the example I gave earlier, the option to animate an icon instead of building an expensive tooltip wasn’t obvious to everyone. It seemed obvious to our engineer, though, because she was closest to the problem and knew more about our options as a result. Brainstorming workarounds with your team is another opportunity to bring your expertise to the table and ensure the final outcome achieves your shared goals.
Repeat
Project kick-offs are a great place to start these negotiations, but they shouldn’t stop there. New or unforeseen constraints are bound to show up throughout the development cycle, so it makes sense to keep negotiations going until launch. Repeating the process of grounding in the problem your team is trying to solve, realigning on goals, identifying opportunities to save time or energy, and finding creative workarounds will lead to faster development, better products, and stronger relationships with your teammates.
If this sounds interesting to you, join us!
