How to communicate tradeoffs so leaders will listen

👋 Hey, I’m Lenny, and welcome to a 🔒 subscriber-only edition 🔒 of my weekly newsletter. Each week I tackle reader questions about building product, driving growth, and accelerating your career. For more: Best of Lenny’s Newsletter | Hire your next product leader | Podcast | Lennybot | Swag.

We’re excited to announce two new speakers who’ll be joining our legendary lineup:

1. Ebi Atawodi—Director of PM at YouTube and LEGO board member. Formerly, Director of Product at Netflix, Head of Product for Uber Wallet/Checkout/Pay

2. Jiaona Zhang (JZ)—CPO of Linktree. Formerly, SVP at Webflow, Head of Product for Homes Platform at Airbnb, Senior Director of PM at WeWork, and PM at Dropbox

Apply now

Applications are still open, and approvals are going out weekly. Check your spam folders in case you might have missed an email from us. Ping us at [email protected] if you have any questions.

Now, on to today’s post…

We all know that sinking feeling you get when everything is on track, your team is humming—and then an exec drops a high-priority feature request on your team. How you handle that ask, and how well you’re able to articulate the tradeoffs required to take on this new work, is a PM superpower. It’s one that can save you and your team from unnecessary stress while helping you do what’s best for the company’s future.

Newsletter Fellow Tara Seshan knows a thing or two about explaining tough choices to higher-ups. She spent seven years as an early PM and Business Lead at Stripe, was Head of Product for two years at Watershed, and founded a health-care startup as an early Thiel Fellow. 

Below, she shares her hard-earned playbook for making tradeoffs crystal clear to even the busiest leaders. I wish I’d had this guide when I was a PM.

Tara is currently working on a new startup in the creative-tools space within Sutter Hill Ventures, co-hosts a podcast called The Red Queen, and writes about the friction between our private and working selves at Working Assumptions. Follow her on LinkedIn and X.

For years, communicating tradeoffs to senior leaders was one of my biggest challenges. While presenting the pros and cons between two priorities, I’d somehow always end up committing to doing both, and in less time than I had planned. As you’d expect, this usually went … badly. I’d burn myself out or, worse, burn out my team. 

But when I started managing, I finally understood why I had been so ineffective at it. Sitting on the other side of the table, I watched others make the same mistakes I had. I realized I hadn’t been framing tradeoffs correctly. 

For example, in an attempt to force a choice, I used to say things like: 

• “We are thin on resources.” 

• “All of the engineers on the team are working on this other feature. Maybe we can sneak your thing in if they can do it in spare cycles.”

• “I’m not sure if this is really high-priority.”

• “I have many things higher in my stack rank [shows list].”

• “Yes, we could deprioritize our new dashboard rehaul [or insert current project here]—what do you think?”

It turns out that statements like these are counterproductive. They actually invite leadership teams to avoid the choice you’re presenting. It’s clear to me now why the answer to my tradeoff presentations was always to “do both.” 

When I learned how to frame choices correctly, I was finally able to convince company leadership to make real, painful decisions. The first time I pushed a tradeoff using the techniques below, it was exhilarating! We only had to do the one most important thing! This led to many fewer late nights at the computer for me and my team, which made me a much more popular PM. These days, it’s a skill I apply in every tough product roadmap conversation. 

If company leaders haven’t heard of or don’t care about your existing priorities, it’ll be inherently challenging to preserve them when an urgent request comes along. The more work that your team has done up front to bring leadership into the story of your priorities and strategy prior to this decision point, the less work your team will have to do when new requests come in.

This involves a lot of repetition of your priorities, your projects, and your strategy (in that order). As Eric Schmidt, the former Google CEO, used to say, “repetition doesn’t spoil the prayer.” 

There are many ways to do this up-front planning and evangelism, but my favorite way is to create a public and ongoing stack rank (OSR) of projects:

In your OSR, every discrete project is sequenced according to its priority, its resourcing, and its outcomes. It is complementary to your OKRs, which might be at a higher level and less numerous. With an OSR, it is clear when a specific project is “above” or “below” the resourcing cutline. Here’s a template for an OSR (remixed from one created by my friend Brie Wolfson).

The OSR takes a common PM statement like “I don’t think this new request is a high priority” and puts it in the context of everything that is and isn’t a priority for your team. It changes the conversation with other teams from “Why can’t we do this one extra thing?” into “Do you agree that X is more important than Y?”

I like to make the OSR document extremely accessible to everyone around the company. I present it at the smallest provocation. I always share it with the team during fortnightly GTM catch-ups, embed a slide version in executive presentations (right up front!), and email a set of short summary statements in our weekly team progress updates. I try to become the “repeater-in-chief,” as Jeff Bezos called himself. 

On one memorable occasion, I mapped the top 10 features on our OSR to the Billboard Top 10 and turned the features into specific song lyrics (“Metered billing-oh-na-na” to the tune of Camila Cabello’s “Havana,” anyone?). I will note that it was unbelievably cringe and that I still hate myself for doing this, but it was effective. Every single person on our broader cross-functional team remembered our 10 most important features. 

Imagine you’re in a big meeting with your company’s leadership team, arguing that the company should not do the new large user request. We should stick to existing roadmap item X, you say. But the CRO pipes up, “Wait. I just heard from the account manager that there are three other large customers who have this same request, and that it represents a meaningful percentage of our revenue expansion for the year.” “Ooh, those are great logos,” the CPO says. After some discussion, the group concludes that you should really do this new request—your case folds. And, of course, it’s expected that you should hit your team goals too. You trudge off to inform your team that you’re doing double the work.  

This hypothetical situation could’ve been avoided if you’d “steelmanned” the new request before the meeting. Steelmanning is a technique used in debate where you present the strongest possible version of your opponent’s argument before countering it. It makes you much more persuasive, and minimizes the chance that you get surprised by new information with the executive team. Because you’ve already thought through every angle, it positions you as the expert in the room and gives you the opportunity to explore counterarguments on your own terms. 

In order to steelman a request, you have to collaborate closely with the requester. Faire CPO Ami Vora, in this clip from her podcast episode with Lenny, suggests approaching requests with curiosity, and assuming the requester has insight and information that you do not have. It’s really hard to do this when you’re feeling defensive! In the moment, I remind myself that the most important first reaction is to pause, think, and then ask clarifying questions instead of reacting defensively. I might say something like “That’s interesting and new to me! Let’s find the customer call recording and then watch it together; I want to hear what you think.” If the communication is over email or chat, I’ve actually fed the email thread into ChatGPT and asked it to advise me as if it were my career coach. It does a surprisingly great job at helping me respond with curiosity. 

When you steelman a request, you’re not necessarily saying that the request is a good idea. Instead, you are saying that colleagues are smart and have information you do not. This technique helps you notice your blind spots, fill them in with research, and make a much more informed decision. And sometimes that decision is to do the request!

An excellent example of this is from a PM at Amazon who once received the dreaded “?” email from Jeff Bezos, in reference to why screws were so hard to find in Amazon search. (Bezos was famous for forwarding customer requests sent to [email protected] with simply a “?” to the unsuspecting Amazon employee.)