How to communicate tradeoffs so leaders will listenTactical tips for teeing up critical decisions without pissing leaders off
👋 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. ✨ Updates from Lenny and Friends Summit ✨We’re excited to announce two new speakers who’ll be joining our legendary lineup:
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 events@lennyssummit.com 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:
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. How to frame tradeoffs effectively1. Repetition doesn’t spoil the prayerIf 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.
2. “Steelman the request” to find your blind spotsImagine 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 jeff@amazon.com with simply a “?” to the unsuspecting Amazon employee.)
In this situation, most PMs would think, “How can I explain to the CEO why finding screws on Amazon.com is a low-priority, low-impact issue?” Instead, the PM steelmanned the request. He looked into the data and investigated the issue deeply, even though it seemed trivial. After he spent days digging into the data and talking to customers, he realized that the concern wasn’t just about screws. Screws were a representative problem. It turned out that anything on Amazon that was unbranded and “specification-driven” rather than “brand-driven” was very hard to find. Bezos’s instincts were right on this one, likely because he had expertise—or a very well-informed hunch—that the PM didn’t. By steelmanning the ask, the PM was able to discover a really important and widespread customer experience issue behind the seemingly trivial problem. Fixing this class of issue, rather than the specific issue of just screws, required a meaningful amount of engineering and product work. It likely derailed the existing roadmap to make that possible. But the PM now knew it was a problem worth solving.
3. Company first, team secondEven though you really care about your team’s goals, leadership is always thinking about the company’s goals first. They will always respond better to a “company-first” framing of any decision. As a PM, you might assume that relating the tradeoff to your team goals would reassure leadership—after all, they might have explicitly approved of these goals during your planning season. But the company goals are more top-of-mind and important to them. Framing your tradeoff in terms of company goals means that they won’t have to do that same thing in their own heads. It reassures them that you’re making the best global prioritization decision for the company instead of a locally optimal decision for your team. And it means they’re more likely to side with your argument. When I was starting Stripe Billing, the subscriptions and invoicing product suite, it was hard to get my requests prioritized, no matter how well I argued my case. Stripe had been focused on global expansion. As a result, the payments leadership team would deny requests that distracted them from those goals. My team goals around adding subscriptions features weren’t going to directly and obviously support global expansion, so I was rejected in favor of other teams’ requests at every turn. At the time, I was incredibly frustrated. I had faithfully communicated my team goals and how these features achieved them, I thought. But I was completely missing the relationship between my team goals and the company goals in my communication. No wonder these teams didn’t think the tradeoff was worth it! Since my product really did help global expansion, I had to reframe and return in order to get the help my team needed. Framing the decision in the context of company goals helps everyone in the room orient around what really matters. And if you can show a more significant impact on the company goals than the alternative, it provides a very strong case for prioritizing your solution over others’. 4. Predict the future, just a little bitMost incoming requests are framed in the context of a short-term goal. But as a leader on the product team, you should think long-term! Put on your fortune-teller hat and predict the future a little bit. If we decide to take this thing on now, what happens next quarter? Next year? What ongoing costs do we take on? What will happen to team morale if the team works nights and weekends for another quarter? Another two quarters? You should explicitly lay out these prioritization considerations to the leadership team. It’s doubly important to think this way while considering go-to-market requests. Revenue teams are often incentivized around a quarter, but product teams should think beyond that time period. Thinking and communicating about the long term will help you be more persuasive with leadership (who are usually desperately trying to balance “delivering quarterly results” with a big-picture vision). It can also help identify gaps in the plan that the revenue teams may have missed. When I was Head of Product at Watershed, which helps companies measure and report on their carbon emissions, a PM leader on my team named Steve was frustrated that measuring a carbon footprint involved so much manual intervention. But the company wasn’t ready to solve that problem. Leadership was much more concerned with the upcoming seasonal demand surge. The default path to meet that customer need was to hire many analysts to manage the process manually, and have the engineering team build features to increase analyst efficacy. This approach was guaranteed to help the company meet the demand surge, but it would come at great cost to the long-term unit economics and product-building. Steve believed that we were making the wrong tradeoff, especially in light of technology developments in AI. Instead of accepting the company decision, he proposed a big intervention to automate Watershed’s measurement process. In the short term, this would potentially lower the quality bar of the user experience and impact analyst throughput. But in the long term, this reprioritization of efforts would be meaningfully better for the company. A more automated solution would dramatically lower marginal operating cost. It meant that the company would truly build toward becoming a software-driven solution, instead of a hybrid between software and services. To persuade leadership, Steve communicated two things:
Steve’s argument was excellent because it soothed the leadership team’s core fear: that the upcoming demand surge would go badly if we didn’t take the manual approach. He was able to tell the leadership team, thanks to all his detailed work, that the tradeoff was less dramatic than they had assumed. He made it obvious that investing in “long-term automation” had just enough overlap with the short-term need to mitigate fears about the surge. Ultimately, company leadership decided to make the automation path the top companywide priority for the year. To put the cherry on top, Steve gave the new priority a catchy, memeable name (“Transform Measurement!”) that spread like wildfire throughout the organization. Next time you get a request to prioritize something that will hurt the company in the long term, challenge it! Leadership teams want to do the right long-term thing, but there might be a short-term-oriented fear holding them back. If you can lay out the long-term vision while striking at the core fear behind the short-term thinking, your vision becomes the obvious best choice. 5. Always communicate an opinionated decisionYou have mastered the details, you’ve thought through the problem, and you’ve talked to a ton of stakeholders. But equally important is that you make an opinionated proposal for the solution. Teams often shy away from having a POV, deferring to leadership to choose between two unbiased options. But people forget that they have more context on the issue than anyone on the leadership team and are the best positioned to make a recommendation. Whenever possible, leadership actually prefers to endorse a team’s specific opinion. As a PM, you have ownership over execution, but you should also be invested in the decision itself. Presenting an opinionated decision can sometimes be tricky. In order to persuade leadership, I like to hammer home my point with a dedicated document and a meeting. I frame it using “SCQA” to focus the discussion on the single request at hand. Here’s how I approach making a document like that:
Here’s a template you can use for that tradeoff document, heavily based on SCQA. If I’m verbally discussing this document in a meeting, I’ll start the meeting with a quick orientation of why we’re there. Since I’m usually talking to busy executives who don’t do pre-reads, I’ll kick off with a silent reading period (about 8 minutes, depending on the length of the document). I’ll begin the discussion by restating my recommendation and outlining the decision-making period (“I’d like to gavel on this decision at the end of the meeting—the default is that we’ll move forward with this approach”) and then open the floor for new information. “Anything we didn’t account for in this document?” I might ask. If there is new data from the group, we’ll talk about it. Ideally, thanks to steelmanning the argument prior, there isn’t anything new! Three-quarters of the way through the meeting, I’ll know if it’s converging or diverging—that is, if it’s to end in a decision or if it will need further investigation. If the meeting went well, we’ll conclude with the decision and the next steps that I outlined. If the meeting introduces a lot of new information or seems like it isn’t driving consensus, I’ll try to flag that as soon as possible. I still try to end with some very specific actions, such as following up with the decision maker one-on-one, spending more time with the large customer in question to clarify the ask, and then coming back to the forum with an update. Of course, the only “bad” meeting in this context is one that ends without clear next steps and a timeline to get to a decision! Tradeoff trapsNow that you’re armed with the tools to communicate tradeoffs and the terms of a decision, what could possibly go wrong? Unfortunately, there are a few tradeoff traps that are perfectly positioned to lure optimistic, productive, and structured product leaders. 1. The “peanut butter” trapImagine an executive asks you to build this very exciting feature—it shouldn’t take the team more than a couple days to make, and it seems fun. You, brimming with optimism, add it to the list. However, even a small ask is never as small as you think it will be. And each request adds up. It’s easy to understand why the team wants to do these things: They bring delight to customers! Your team is staffed with optimists! But the insidious thing about these types of asks is that they aren’t quite big enough for you to say, “You need to pick between our top priority and this small ask” or “This small ask will delay our top priority by one quarter.” The team becomes “peanut buttered”—spread too thin—over a list of tiny requests. They find that their roadmap is suddenly made up of many cute features, leaving no capacity for the big and important work they need to do. By treating all of these small requests as real tradeoffs, you can keep the team on task. 2. The “just one more engineer” trapWhen Jeff Huber, a former Google SVP, asked product leader Peter Chane if Google should acquire YouTube, Chane balked at the prospect. He said, basically, “I think we just need one more good Java/UI engineer and we’d be kicking butt vs. YouTube.”
It’s funny to think about this request for one “Java/UI engineer” making Google Video competitive with YouTube, but this mindset is actually more common than you’d think. Every product team will always need “one more engineer.” However, adding more engineers to the team is not a good solution to a problem that requires a tradeoff. Productive team leaders often focus on adding more capacity in order to say yes to more requests. And while more capacity can indeed help teams do more, there is absolutely no amount of capacity that would eliminate the need to prioritize new requests. Planning will always scale to match capacity, and you’ll still always have more incoming requests than you can satisfy. Instead, you should prioritize requests based on their importance to the business first. Once you agree on priorities and tradeoffs, you should then ask for the capacity to execute on those specific priorities. A better answer with regard to YouTube might have been something like (based off Chris Sacca’s response² here):
3. The “but we have a framework” trapPMs love frameworks, which can indeed be helpful in making decisions. Frameworks help you order by relative priority, but you’ll still always be evaluating line items on the margin. Also, frameworks tend to be abstract. They can only be put into practice and adjusted through individual cases. Most importantly, business frameworks aren’t laws of physics. They may turn out to be wrong when new data comes to light. In the case of a contentious tradeoff, it can make sense to reference the existing framework as a start. But don’t stop there! Elaborate on the problem by raising details that don’t quite fit the framework. As part of steelmanning the argument, think about where the framework might be wrong. If it doesn’t make sense with new data, mention that and throw it out. A framework doesn’t excuse you from diving into the specifics on an important decision. Trap examplesNow that we know the right way to communicate about priorities and understand what traps are out there, why were those initial examples wrong? Here’s my review.
Ultimately, the best way to frame a tradeoff is to put yourself into the CEO role: If you were responsible for the overall success of the business over the long term, what would you want to know about a prioritization decision? What information or arguments would help you choose? Now jump back into your PM body and figure out how, when, and with what tools you can present that in a clear way to leadership. 📚 Further studyThanks, Tara! For more from Tara, check out her newsletter, Working Assumptions, and follow her on LinkedIn and X. Have a fulfilling and productive week 🙏 👀 Hiring? Or looking for a new job?I’ve got a white-glove recruiting service for senior product roles, working with a few select companies at a time. If you’re hiring, apply below. If you’re exploring new opportunities yourself, use the same button above to sign up. We’ll send over personalized opportunities from hand-selected companies if we think there’s a fit. If you’re finding this newsletter valuable, share it with a friend, and consider subscribing if you haven’t already. There are group discounts, gift options, and referral bonuses available. Sincerely, Lenny 👋 1 Prompt: Imagine you’re a highly competent and empathetic executive coach teaching me, Tara, how to be more curious instead of defensive. Await further instructions. Next prompt: Here is an email thread (attached) between me and our Head of Sales. How would you characterize the relationship? What can I do to make it more collaborative? Next: In reference to this specific request, I want to ensure that I have the most information to make the right decision instead of just agreeing to do what he asks. What’s the best way to elicit that information, if he’s reluctant to share it? Next: Now, help me edit my planned response to his request to be less defensive and to maximize curiosity. I want it to be informal and match the friendly tone of the emails. (Sometimes I’ll ask it to be “even more chill and friendly!”) 2 Chris Sacca’s tweet, if you don’t follow him and thus can’t see it on X:
You're currently a free subscriber to Lenny's Newsletter. For the full experience, upgrade your subscription.
|
How to communicate tradeoffs so leaders will listen
Subscribe to:
Post Comments (Atom)
Google's Big Toggle Button Design Mistake
The right way to show toggle states ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ...
No comments:
Post a Comment