Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="65e763ba9ec42d7f0377b908a7fb10bcb3217234047516df305e7055353e" Subject: How to communicate tradeoffs so leaders will listen From: Lenny's Newsletter To: Hidden Recipient Date: Tue, 10 Sep 2024 11:03:30 +0000 X-Hiring: We are hiring, reach out at header-hacker@emailshot.io X-EmailShot-Signature: EnSji6alzJHdK2ycyv6InvCHB397kIs0uxlUbz28ORlr_0vfnLSLX9dXXurM4BDZ9fbmOxC1HyvArwXGkBUcUg== --65e763ba9ec42d7f0377b908a7fb10bcb3217234047516df305e7055353e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable View this post on the web at https://www.lennysnewsletter.com/p/how-to-comm= unicate-tradeoffs-so-leaders =F0=9F=91=8B Hey, I=E2=80=99m Lenny, and welcome to a=C2=A0=F0=9F=94=92 sub= scriber-only edition =F0=9F=94=92=C2=A0of my weekly newsletter. Each week I= tackle reader questions about building product, driving growth, and accele= rating your career. For more: Best of Lenny=E2=80=99s Newsletter [ https://= substack.com/redirect/1b80322c-98b9-4116-8c9e-ab733983bea8?j=3DeyJ1IjoiM2dm= eXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ] | Hire your next prod= uct leader [ https://substack.com/redirect/2a794a81-d345-4231-9c65-fd334aa3= 7280?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ] = | Podcast [ https://substack.com/redirect/b6729ad7-ce57-432b-aac7-c67443aa9= c44?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ] |= Lennybot [ https://substack.com/redirect/2d2dd34b-86b2-48f1-87c5-b82962d36= 825?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ] |= Swag [ https://substack.com/redirect/8f195e7d-3414-4f04-9af3-ec363dd9f2df?= j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ]. =E2=9C=A8 Updates from Lenny and Friends Summit =E2=9C=A8 We=E2=80=99re excited to announce two new speakers who=E2=80=99ll be joinin= g our legendary lineup: Ebi Atawodi [ https://substack.com/redirect/734396fb-dc96-48eb-9757-3d31570= 440f5?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ]= =E2=80=94Director of PM at YouTube and LEGO board member. Formerly, Directo= r of Product at Netflix, Head of Product for Uber Wallet/Checkout/Pay Jiaona Zhang (JZ) [ https://substack.com/redirect/f56e5f83-d799-4049-bad7-1= 5ddb05ea782?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0= l24U ]=E2=80=94CPO of Linktree. Formerly, SVP at Webflow, Head of Product f= or Homes Platform at Airbnb, Senior Director of PM at WeWork, and PM at Dro= pbox 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 ev= ents@lennyssummit.com [ mailto:events@lennyssummit.com ] if you have any qu= estions. Now, on to today=E2=80=99s post=E2=80=A6 We all know that sinking feeling you get when everything is on track, your = team is humming=E2=80=94and then an exec drops a high-priority feature requ= est on your team. How you handle that ask, and how well you=E2=80=99re able= to articulate the tradeoffs required to take on this new work, is a PM sup= erpower. It=E2=80=99s one that can save you and your team from unnecessary = stress while helping you do what=E2=80=99s best for the company=E2=80=99s f= uture. Newsletter Fellow [ https://substack.com/redirect/6d5462c1-93b4-4192-b985-4= 3d5b1fb1437?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0= l24U ] Tara Seshan [ https://substack.com/redirect/4a2d147d-de24-41fc-9743-= 66bfa1cc1631?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF= 0l24U ] 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 [ https://= substack.com/redirect/6ddb1562-fd9e-4db9-8128-b5dda0bb433d?j=3DeyJ1IjoiM2dm= eXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ], was Head of Product = for two years at Watershed [ https://substack.com/redirect/f5687f9f-1a07-4c= fe-ab29-61f171b91d8c?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM= 3m0rbAsF0l24U ], and founded a health-care startup as an early Thiel Fellow= [ https://substack.com/redirect/f20327d2-bad6-450c-850a-037f056d7175?j=3De= yJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ].=C2=A0 Below, she shares her hard-earned playbook for making tradeoffs crystal cle= ar to even the busiest leaders. I wish I=E2=80=99d had this guide when I wa= s a PM. Tara is currently working on a new startup in the creative-tools space with= in Sutter Hill Ventures [ https://substack.com/redirect/536f3d1c-f6c5-4f36-= beda-97d613d69d31?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0= rbAsF0l24U ], co-hosts a podcast called The Red Queen [ https://substack.co= m/redirect/e3edc455-e690-4f7c-9e63-762b94a7606b?j=3DeyJ1IjoiM2dmeXZtIn0.xu7= 6uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ], and writes about the friction b= etween our private and working selves at Working Assumptions [ https://subs= tack.com/redirect/0fc5eef1-a4eb-43c8-8014-f5b2e7141fd3?j=3DeyJ1IjoiM2dmeXZt= In0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ]. Follow her on LinkedIn [= https://substack.com/redirect/4a2d147d-de24-41fc-9743-66bfa1cc1631?j=3DeyJ= 1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ] and X [ http= s://substack.com/redirect/fcd99ef5-4b4d-46e2-b283-0e60a51c048b?j=3DeyJ1Ijoi= M2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ]. For years, communicating tradeoffs to senior leaders was one of my biggest = challenges. While presenting the pros and cons between two priorities, I=E2= =80=99d somehow always end up committing to doing both, and in less time th= an I had planned. As you=E2=80=99d expect, this usually went =E2=80=A6 badl= y. I=E2=80=99d burn myself out or, worse, burn out my team.=C2=A0 But when I started managing, I finally understood why I had been so ineffec= tive at it. Sitting on the other side of the table, I watched others make t= he same mistakes I had. I realized I hadn=E2=80=99t been framing tradeoffs = correctly.=C2=A0 For example, in an attempt to force a choice, I used to say things like:=C2= =A0 =E2=80=9CWe are thin on resources.=E2=80=9D=C2=A0 =E2=80=9CAll of the engineers on the team are working on this other feature= =2E Maybe we can sneak your thing in=20= if they can do it in spare cycles.=E2=80= =9D =E2=80=9CI=E2=80=99m not sure if this is really high-priority.=E2=80=9D =E2=80=9CI have many things higher in my stack rank [shows list].=E2=80=9D =E2=80=9CYes, we could deprioritize our new dashboard rehaul [or insert cur= rent project here]=E2=80=94what do you think?=E2=80=9D It turns out that statements like these are counterproductive. They actuall= y invite leadership teams to avoid the choice you=E2=80=99re presenting. It= =E2=80=99s clear to me now why the answer to my tradeoff presentations was = always to =E2=80=9Cdo both.=E2=80=9D=C2=A0 When I learned how to frame choices correctly, I was finally able to convin= ce company leadership to make real, painful decisions. The first time I pus= hed 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. Thes= e days, it=E2=80=99s a skill I apply in every tough product roadmap convers= ation.=C2=A0 How to frame tradeoffs effectively=C2=A0 1. Repetition doesn=E2=80=99t spoil the prayer=C2=A0 If company leaders haven=E2=80=99t heard of or don=E2=80=99t care about you= r existing priorities, it=E2=80=99ll be inherently challenging to preserve = them when an urgent request comes along. The more work that your team has d= one up front to bring leadership into the story of your priorities and stra= tegy 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 yo= ur strategy (in that order). As Eric Schmidt, the former Google CEO, used t= o say, =E2=80=9Crepetition doesn=E2=80=99t spoil the prayer.=E2=80=9D=C2=A0 There are many ways to do this up-front planning and evangelism, but my fav= orite 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 =E2=80=9Cabove=E2=80=9D or =E2=80=9Cbelow=E2=80=9D t= he resourcing cutline. Here=E2=80=99s a template [ https://substack.com/red= irect/b30cf673-7e89-400e-939e-500cf0ce770e?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFOb= qArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ] for an OSR (remixed from one created = by my friend Brie Wolfson [ https://substack.com/redirect/baa93581-8334-409= 2-ba95-d06996ea3d37?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3= m0rbAsF0l24U ]). The OSR takes a common PM statement like =E2=80=9CI don=E2=80=99t think thi= s new request is a high priority=E2=80=9D and puts it in the context of eve= rything that is and isn=E2=80=99t a priority for your team. It changes the = conversation with other teams from =E2=80=9CWhy can=E2=80=99t we do this on= e extra thing?=E2=80=9D into =E2=80=9CDo you agree that X is more important= than Y?=E2=80=9D 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 executi= ve presentations (right up front!), and email a set of short summary statem= ents in our weekly team progress updates. I try to become the =E2=80=9Crepe= ater-in-chief,=E2=80=9D as Jeff Bezos called himself.=C2=A0 On one memorable occasion, I mapped the top 10 features on our OSR to the B= illboard Top 10 and turned the features into specific song lyrics (=E2=80= =9CMetered billing-oh-na-na=E2=80=9D to the tune of Camila Cabello=E2=80=99= s =E2=80=9CHavana,=E2=80=9D anyone?). I will note that it was unbelievably = cringe and that I still hate myself for doing this, but it was effective. E= very single person on our broader cross-functional team remembered our 10 m= ost important features.=C2=A0 2. =E2=80=9CSteelman the request=E2=80=9D to find your blind spots Imagine you=E2=80=99re in a big meeting with your company=E2=80=99s leaders= hip team, arguing that the company should not do the new large user request= =2E We should stick to existing roadmap= item X, you say. But the CRO pipes up= , =E2=80=9CWait. 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.=E2=80=9D =E2= =80=9COoh, those are great logos,=E2=80=9D the CPO says. After some discuss= ion, the group concludes that you should really do this new request=E2=80= =94your case folds. And, of course, it=E2=80=99s expected that you should h= it your team goals too. You trudge off to inform your team that you=E2=80= =99re doing double the work.=C2=A0=C2=A0 This hypothetical situation could=E2=80=99ve been avoided if you=E2=80=99d = =E2=80=9Csteelmanned=E2=80=9D the new request before the meeting. Steelmann= ing is a technique used in debate where you present the strongest possible = version of your opponent=E2=80=99s argument before countering it. It makes = you much more persuasive, and minimizes the chance that you get surprised b= y new information with the executive team. Because you=E2=80=99ve already t= hought through every angle, it positions you as the expert in the room and = gives you the opportunity to explore counterarguments on your own terms.=C2= =A0 In order to steelman a request, you have to collaborate closely with the re= quester. Faire CPO Ami Vora, in this clip from her podcast episode with Len= ny [ https://substack.com/redirect/514a3614-eab0-46c9-b18b-e65677039a2e?j= =3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ], sugge= sts approaching requests with curiosity, and assuming the requester has ins= ight and information that you do not have. It=E2=80=99s really hard to do t= his when you=E2=80=99re feeling defensive! In the moment, I remind myself t= hat the most important first reaction is to pause, think, and then ask clar= ifying questions instead of reacting defensively. I might say something lik= e =E2=80=9CThat=E2=80=99s interesting and new to me! Let=E2=80=99s find the= customer call recording and then watch it together; I want to hear what yo= u think.=E2=80=9D If the communication is over email or chat, I=E2=80=99ve = 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 res= pond with curiosity.=C2=A0 When you steelman a request, you=E2=80=99re 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 [ https://substack.com/= redirect/cd82117e-c86d-43a7-9e65-ef3131f764c0?j=3DeyJ1IjoiM2dmeXZtIn0.xu76u= FObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ] who once received the dreaded =E2= =80=9C?=E2=80=9D email from Jeff Bezos, in reference to why screws were so = hard to find in Amazon search. (Bezos was famous for forwarding customer re= quests sent to jeff@amazon.com with simply a =E2=80=9C?=E2=80=9D to the uns= uspecting Amazon employee.) In this situation, most PMs would think, =E2=80=9CHow can I explain to the = CEO why finding screws on Amazon.com is a low-priority, low-impact issue?= =E2=80=9D Instead, the PM steelmanned the request. He looked into the data and investigated the issue deeply, even though it s= eemed trivial. After he spent days digging into the data and talking to cus= tomers, he realized that the concern wasn=E2=80=99t just about screws. Scre= ws were a representative problem. It turned out that anything on Amazon tha= t was unbranded and =E2=80=9Cspecification-driven=E2=80=9D rather than =E2= =80=9Cbrand-driven=E2=80=9D was very hard to find. Bezos=E2=80=99s instinct= s were right on this one, likely because he had expertise=E2=80=94or a very= well-informed hunch=E2=80=94that the PM didn=E2=80=99t. By steelmanning th= e ask, the PM was able to discover a really important and widespread custom= er experience issue behind the seemingly trivial problem.=C2=A0 Fixing this class of issue, rather than the specific issue of just screws, = required a meaningful amount of engineering and product work. It likely der= ailed the existing roadmap to make that possible. But the PM now knew it wa= s a problem worth solving.=C2=A0 3. Company first, team second Even though you really care about your team=E2=80=99s goals, leadership is = always thinking about the company=E2=80=99s goals first. They will always r= espond better to a =E2=80=9Ccompany-first=E2=80=9D framing of any decision.= As a PM, you might assume that relating the tradeoff to your team goals wo= uld reassure leadership=E2=80=94after all, they might have explicitly appro= ved of these goals during your planning season. But the company goals are m= ore top-of-mind and important to them. Framing your tradeoff in terms of co= mpany goals means that they won=E2=80=99t have to do that same thing in the= ir own heads. It reassures them that you=E2=80=99re making the best global = prioritization decision for the company instead of a locally optimal decisi= on for your team. And it means they=E2=80=99re more likely to side with you= r 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 ar= gued my case. Stripe had been focused on global expansion. As a result, the= payments leadership team would deny requests that distracted them from tho= se goals. My team goals around adding subscriptions features weren=E2=80=99= t going to directly and obviously support global expansion, so I was reject= ed in favor of other teams=E2=80=99 requests at every turn.=C2=A0 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 compl= etely missing the relationship between my team goals and the company goals = in my communication. No wonder these teams didn=E2=80=99t think the tradeof= f 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.=C2=A0 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 signific= ant impact on the company goals than the alternative, it provides a very st= rong case for prioritizing your solution over others=E2=80=99.=C2=A0 4. Predict the future, just a little bit Most 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 fo= rtune-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 an= d weekends for another quarter? Another two quarters? You should explicitly= lay out these prioritization considerations to the leadership team. It=E2=80=99s doubly important to think this way while considering go-to-mar= ket requests. Revenue teams are often incentivized around a quarter, but pr= oduct teams should think beyond that time period. Thinking and communicatin= g about the long term will help you be more persuasive with leadership (who= are usually desperately trying to balance =E2=80=9Cdelivering quarterly re= sults=E2=80=9D with a big-picture vision). It can also help identify gaps i= n the plan that the revenue teams may have missed.=C2=A0 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 [ http= s://substack.com/redirect/d11686bf-11c6-4304-919a-d52c01afff15?j=3DeyJ1Ijoi= M2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ] was frustrated th= at measuring a carbon footprint involved so much manual intervention. But t= he company wasn=E2=80=99t 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 ma= nually, and have the engineering team build features to increase analyst ef= ficacy. This approach was guaranteed to help the company meet the demand su= rge, but it would come at great cost to the long-term unit economics and pr= oduct-building.=20 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=E2=80=99s measuremen= t 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 comp= any. A more automated solution would dramatically lower marginal operating = cost. It meant that the company would truly build toward becoming a softwar= e-driven solution, instead of a hybrid between software and services.=C2=A0 To persuade leadership, Steve communicated two things:=C2=A0 A deeply detailed picture of what the 3- and 15-month outlook might look li= ke if the company followed his automated-future vision A roadmap of specific features that made the long-term path come alive, dem= onstrating how this path required a more minimal short-term tradeoff than e= veryone had assumed Steve=E2=80=99s argument was excellent because it soothed the leadership te= am=E2=80=99s core fear: that the upcoming demand surge would go badly if we= didn=E2=80=99t take the manual approach. He was able to tell the leadershi= p team, thanks to all his detailed work, that the tradeoff was less dramati= c than they had assumed. He made it obvious that investing in =E2=80=9Clong= -term automation=E2=80=9D had just enough overlap with the short-term need = to mitigate fears about the surge. Ultimately, company leadership decided t= o make the automation path the top companywide priority for the year. To pu= t the cherry on top, Steve gave the new priority a catchy, memeable name (= =E2=80=9CTransform Measurement!=E2=80=9D) that spread like wildfire through= out the organization.=C2=A0 Next time you get a request to prioritize something that will hurt the comp= any in the long term, challenge it! Leadership teams want to do the right l= ong-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 fe= ar behind the short-term thinking, your vision becomes the obvious best cho= ice.=20 5. Always communicate an opinionated decision You have mastered the details, you=E2=80=99ve thought through the problem, = and you=E2=80=99ve talked to a ton of stakeholders. But equally important i= s that you make an opinionated proposal for the solution. Teams often shy away from having a POV, deferring to leadership to choose b= etween 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 t= o endorse a team=E2=80=99s specific opinion. As a PM, you have ownership ov= er execution, but you should also be invested in the decision itself. Presenting an opinionated decision can sometimes be tricky. In order to per= suade leadership, I like to hammer home my point with a dedicated document = and a meeting. I frame it using =E2=80=9CSCQA [ https://substack.com/redire= ct/8114191a-2289-486f-8427-a51202b2efdf?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqAr= DfP822j-jnN48_jCfgM3m0rbAsF0l24U ]=E2=80=9D to focus the discussion on the = single request at hand.=C2=A0 Here=E2=80=99s how I approach making a document like that: As part of writing the document, I always put the decision right at the top= =E2=80=94the =E2=80=9Cbottom line up front=E2=80=9D (BLUF).=C2=A0 In the =E2=80=9CSituation=E2=80=9D section, I elaborate on the context of m= y roadmap and priorities. Make sure to frame the company priorities in this= section and how they relate to my priorities. I highlight the part of the = roadmap that is to be traded off against the new request. This should feel = like common knowledge already, but remember, repetition doesn=E2=80=99t spo= il the prayer! In the =E2=80=9CComplication=E2=80=9D section of the document, I outline th= e request that my team received. I steelman the request and outline any dat= a I might have collected. I use qualitative data heavily as part of my narr= ative because it makes the issue come alive for readers. I include any risk= s associated with not taking action.=C2=A0 In the =E2=80=9CQuestion=E2=80=9D section, I directly present the key decis= ion as a succinct tradeoff to leadership: =E2=80=9CWe must choose between [= X, new request] or [Y, existing item on OSR]. Should we do X or Y?=E2=80=9D= I then explain why it=E2=80=99s a tradeoff between those specific items.= =C2=A0=C2=A0 In the final =E2=80=9CAnswer=E2=80=9D section, I conclude with a more thoro= ugh explanation of my decision. I project the outcome of making this decisi= on. I also try to answer any big open questions with a hypothesized outcome= (indicating my level of certainty!).=C2=A0 Here=E2=80=99s a template [ https://substack.com/redirect/9dc90200-162e-49f= 2-8c87-0749dd8de905?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3= m0rbAsF0l24U ] you can use for that tradeoff document, heavily based on SCQ= A.=C2=A0 If I=E2=80=99m verbally discussing this document in a meeting, I=E2=80=99ll= start the meeting with a quick orientation of why we=E2=80=99re there. Sin= ce I=E2=80=99m usually talking to busy executives who don=E2=80=99t do pre-= reads, I=E2=80=99ll kick off with a silent reading period (about 8 minutes,= depending on the length of the document). I=E2=80=99ll begin the discussio= n by restating my recommendation and outlining the decision-making period (= =E2=80=9CI=E2=80=99d like to gavel on this decision at the end of the meeti= ng=E2=80=94the default is that we=E2=80=99ll move forward with this approac= h=E2=80=9D) and then open the floor for new information. =E2=80=9CAnything = we didn=E2=80=99t account for in this document?=E2=80=9D I might ask. If th= ere is new data from the group, we=E2=80=99ll talk about it. Ideally, thank= s to steelmanning the argument prior, there isn=E2=80=99t anything new!=C2= =A0 Three-quarters of the way through the meeting, I=E2=80=99ll know if it=E2= =80=99s converging or diverging=E2=80=94that is, if it=E2=80=99s to end in = a decision or if it will need further investigation. If the meeting went we= ll, we=E2=80=99ll conclude with the decision and the next steps that I outl= ined. If the meeting introduces a lot of new information or seems like it i= sn=E2=80=99t driving consensus, I=E2=80=99ll try to flag that as soon as po= ssible. I still try to end with some very specific actions, such as followi= ng 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 =E2=80=9Cbad=E2=80=9D meeting in this = context is one that ends without clear next steps and a timeline to get to = a decision!=C2=A0 Tradeoff traps Now that you=E2=80=99re armed with the tools to communicate tradeoffs and t= he 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.=C2=A0=C2=A0 1. The =E2=80=9Cpeanut butter=E2=80=9D trap Imagine an executive asks you to build this very exciting feature=E2=80=94i= t shouldn=E2=80=99t take the team more than a couple days to make, and it s= eems 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=E2=80=99s easy to understand why the team wants to do these things: = They bring delight to customers! Your team is staffed with optimists! But t= he insidious thing about these types of asks is that they aren=E2=80=99t qu= ite big enough for you to say, =E2=80=9CYou need to pick between our top pr= iority and this small ask=E2=80=9D or =E2=80=9CThis small ask will delay ou= r top priority by one quarter.=E2=80=9D The team becomes =E2=80=9Cpeanut bu= ttered [ https://substack.com/redirect/d7b2e97d-cbdb-465b-8992-d3c7beccf437= ?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ]=E2= =80=9D=E2=80=94spread too thin=E2=80=94over a list of tiny requests. They f= ind that their roadmap is suddenly made up of many cute features, leaving n= o capacity for the big and important work they need to do.=C2=A0 By treating all of these small requests as real tradeoffs, you can keep the= team on task.=C2=A0 2. The =E2=80=9Cjust one more engineer=E2=80=9D trap When Jeff Huber, a former Google SVP, asked product leader Peter Chane if G= oogle should acquire YouTube, Chane balked at the prospect. He said, basica= lly, =E2=80=9CI think we just need one more good Java/UI engineer and we=E2= =80=99d be kicking butt vs. YouTube.=E2=80=9D=C2=A0 It=E2=80=99s funny to think about this request for one =E2=80=9CJava/UI eng= ineer=E2=80=9D making Google Video competitive with YouTube, but this minds= et is actually more common than you=E2=80=99d think.=C2=A0 Every product team will always need =E2=80=9Cone more engineer.=E2=80=9D Ho= wever, adding more engineers to the team is not a good solution to a proble= m that requires a tradeoff. Productive team leaders often focus on adding m= ore 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 th= at would eliminate the need to prioritize new requests. Planning will alway= s scale to match capacity, and you=E2=80=99ll still always have more incomi= ng requests than you can satisfy.=C2=A0 Instead, you should prioritize requests based on their importance to the bu= siness first. Once you agree on priorities and tradeoffs, you should then a= sk for the capacity to execute on those specific priorities. A better answe= r with regard to YouTube might have been something like (based off Chris Sa= cca=E2=80=99s response [ https://substack.com/redirect/741c6c20-2cb8-4a7f-8= 884-6af90573dcf1?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0r= bAsF0l24U ] here):=C2=A0 =E2=80=9CPositionally, Google is focused on trying to get all the world=E2= =80=99s video on our platform, while YouTube is specifically focused on cre= ating and hosting user-generated video content. Unlike YouTube, we, Google,= have to play nice with the media and ISPs, while they=E2=80=99re making me= dia companies mad by catering to users. The real question here isn=E2=80=99= t about tech, or specific resources, it=E2=80=99s about position. We have a= tradeoff to make: (1) we can buy them, once we have enough leverage to con= front media companies directly, (2) we can take the same strategy, but we h= ave to prepare the rest of Google for the fallout, or (3) we can pursue our= existing strategy and lean into the advantages we have, like the recent de= al we did at the Olympics in Torino. I think we should do 3. And if we do 3= , we=E2=80=99re not staffed to do it well. I need [X] people to do it right= =2E=E2=80=9D=C2=A0 3. The =E2=80=9Cbut we have a framework=E2=80=9D trap PMs love frameworks, which can indeed be helpful in making decisions. Frame= works help you order by relative priority, but you=E2=80=99ll still always = be evaluating line items on the margin. Also, frameworks tend to be abstrac= t. They can only be put into practice and adjusted through individual cases= =2E Most importantly, business frame= works aren=E2=80=99t laws of physics. The= y may turn out to be wrong when new data comes to light.=C2=A0 In the case of a contentious tradeoff, it can make sense to reference the e= xisting framework as a start. But don=E2=80=99t stop there! Elaborate on th= e problem by raising details that don=E2=80=99t quite fit the framework. As= part of steelmanning the argument, think about where the framework might b= e wrong. If it doesn=E2=80=99t make sense with new data, mention that and t= hrow it out. A framework doesn=E2=80=99t excuse you from diving into the sp= ecifics on an important decision.=C2=A0 Trap examples Now that we know the right way to communicate about priorities and understa= nd what traps are out there, why were those initial examples wrong? Here=E2= =80=99s my review.=C2=A0 =E2=80=9CWe are thin on resources=E2=80=9D: This presents no options, with = no context on existing priorities. The =E2=80=9Cjust one more engineer=E2= =80=9D trap! =E2=80=9CAll of the engineers on the team are working on this other feature= =2E Maybe we can sneak it in if they= can do it in spare cycles=E2=80=9D: No o= ptions presented, and no context on the existing priorities. The peanut but= ter trap! =E2=80=9CI=E2=80=99m not sure if this is really high-priority=E2=80=9D: It = doesn=E2=80=99t provide details into what is a priority. The framework trap= ! =E2=80=9CI have many things higher in my OSR=E2=80=9D: Closer, but doesn=E2= =80=99t yet present a specific option of what might be cut. It=E2=80=99s th= e framework trap!=C2=A0=C2=A0 =E2=80=9CYes, we could deprioritize our new list page=E2=80=9D: An option, = but how is leadership supposed to know the value of the list page? Do they = care? It=E2=80=99s the framework trap yet again! =E2=80=9CNo=E2=80=94to build the feature, which might help a sales demo wit= h one big client, we=E2=80=99d have to push out support for single sign-on = for enterprises for a quarter, which means these 10 clients won=E2=80=99t b= e onboarded in that time. I don=E2=80=99t think it=E2=80=99s worth it for t= he company; we won=E2=80=99t hit our usage and revenue goals=E2=80=9D: The = exact right framing! A little OSR reference couldn=E2=80=99t hurt, but this= is great.=C2=A0 Ultimately, the best way to frame a tradeoff is to put yourself into the CE= O role: If you were responsible for the overall success of the business ove= r the long term, what would you want to know about a prioritization decisio= n? 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.=C2=A0 =F0=9F=93=9A Further study Harrison Metal: Executive Communication [ https://substack.com/redirect/335= a3b29-970e-45e9-a650-b9d11244ab17?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822= j-jnN48_jCfgM3m0rbAsF0l24U ] Lucy Spence: A Devilish Approach to Tradeoffs [ https://substack.com/redire= ct/7c3295f8-1308-4b9e-a2ea-77d9fbfd9df0?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqAr= DfP822j-jnN48_jCfgM3m0rbAsF0l24U ] Thanks, Tara! For more from Tara, check out her newsletter, Working Assumpt= ions [ https://substack.com/redirect/0fc5eef1-a4eb-43c8-8014-f5b2e7141fd3?j= =3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ], and f= ollow her on LinkedIn [ https://substack.com/redirect/4a2d147d-de24-41fc-97= 43-66bfa1cc1631?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rb= AsF0l24U ] and X [ https://substack.com/redirect/fcd99ef5-4b4d-46e2-b283-0e= 60a51c048b?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l= 24U ]. Have a fulfilling and productive week =F0=9F=99=8F =F0=9F=91=80 Hiring? Or looking for a new job? I=E2=80=99ve got a white-glove recruiting service for senior product roles,= working with a few select companies at a time. If you=E2=80=99re hiring, a= pply below. If you=E2=80=99re exploring new opportunities yourself, use the same button= above to sign up. We=E2=80=99ll send over personalized opportunities from = hand-selected companies if we think there=E2=80=99s a fit. If you=E2=80=99re finding this newsletter valuable, share it with a friend,= and consider subscribing if you haven=E2=80=99t already. There are group d= iscounts [ https://substack.com/redirect/6e133fa2-4895-461d-904c-5caf5215b5= 8d?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ], g= ift options [ https://substack.com/redirect/9752d6f5-bfe9-4572-b1df-f5bd4ee= 2dbee?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0rbAsF0l24U ]= , and referral bonuses [ https://substack.com/redirect/043634a2-bb6d-4b59-9= eff-b609c0c2f116?j=3DeyJ1IjoiM2dmeXZtIn0.xu76uFObqArDfP822j-jnN48_jCfgM3m0r= bAsF0l24U ] available. Sincerely, Lenny =F0=9F=91=8B Unsubscribe https://substack.com/redirect/2/eyJlIjoiaHR0cHM6Ly93d3cubGVubnl= zbmV3c2xldHRlci5jb20vYWN0aW9uL2Rpc2FibGVfZW1haWw_dG9rZW49ZXlKMWMyVnlYMmxrSW= pveU1Ea3dNVGMwTWpZc0luQnZjM1JmYVdRaU9qRTBPREkzTXpneU15d2lhV0YwSWpveE56STFPV= Gt5TVRrekxDSmxlSEFpT2pFM05UYzFNamd4T1RNc0ltbHpjeUk2SW5CMVlpMHhNRGcwTlNJc0lu= TjFZaUk2SW1ScGMyRmliR1ZmWlcxaGFXd2lmUS51NXRlREVoQndYR01COTZKYTRfcVpOZkRpUWN= wVjJrbTc0N0xJaHFyaEowIiwicCI6MTQ4MjczODIzLCJzIjoxMDg0NSwiZiI6dHJ1ZSwidSI6Mj= A5MDE3NDI2LCJpYXQiOjE3MjU5OTIxOTMsImV4cCI6MTcyODU4NDE5MywiaXNzIjoicHViLTAiL= CJzdWIiOiJsaW5rLXJlZGlyZWN0In0.wDYWvm5l4YIZLCxkrys2Iy-bE3vUS9VRaemO5IkZ6Vg? --65e763ba9ec42d7f0377b908a7fb10bcb3217234047516df305e7055353e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable How to communicate tradeoffs so = leaders will listen
Tactical tips for teeing = up critical decisions without pissing leaders off
͏     &s= hy;͏     ­͏     ­͏   Q= 99; ­͏     ­͏     ­͏  = ;   ­͏     ­͏     ­͏=     ­͏     ­͏     ­= ͏     ­͏     ­͏    = ­͏     ­͏     ­͏   &= #8199; ­͏     ­͏     ­͏ &n= bsp;   ­͏     ­͏     ­= 47;     ­͏     ­͏     &s= hy;͏     ­͏     ­͏   Q= 99; ­͏     ­͏     ­͏  = ;   ­͏     ­͏     ­͏=     ­͏     ­͏     ­= ͏     ­͏     ­͏    = ­͏     ­͏     ­͏   &= #8199; ­͏     ­͏     ­͏ &n= bsp;   ­͏     ­͏     ­= 47;     ­͏     ­͏     &s= hy;͏     ­͏     ­͏   Q= 99; ­͏     ­͏     ­͏  = ;   ­͏     ­͏     ­͏=     ­͏     ­͏     ­= ͏     ­͏     ­͏    = ­͏     ­͏     ­͏   &= #8199; ­͏     ­͏     ­͏ &n= bsp;   ­͏     ­͏     ­= 47;     ­͏     ­͏     &s= hy;͏     ­͏     ­͏   Q= 99; ­͏     ­͏     ­͏  = ;   ­͏     ­͏     ­͏=     ­͏     ­͏     ­= ͏     ­͏     ­͏    = ­͏     ­͏     ­͏   &= #8199; ­͏     ­͏     ­͏ &n= bsp;   ­͏     ­͏     ­= 47;     ­͏     ­͏     &s= hy;͏     ­͏     ­͏   Q= 99; ­͏     ­͏     ­͏  = ;   ­͏     ­͏     ­͏=     ­͏     ­͏     ­= ͏     ­͏     ­͏    = ­͏     ­͏     ­͏   &= #8199; ­͏     ­͏     ­͏ &n= bsp;   ­͏     ­͏     ­= 47;     ­͏     ­͏     &s= hy;͏     ­͏     ­͏   Q= 99; ­͏     ­͏     ­͏  = ;   ­͏     ­͏     ­͏=     ­͏     ­͏     ­= ͏     ­͏     ­͏    = ­͏     ­͏     ­͏   &= #8199; ­͏     ­͏     ­͏ &n= bsp;   ­͏     ­͏     ­= 47;     ­͏     ­͏     &s= hy;͏     ­͏     ­͏   Q= 99; ­͏     ­͏     ­͏  = ;   ­͏     ­͏     ­͏=     ­͏     ­͏     ­= ͏     ­͏     ­͏    = ­͏     ­͏     ­͏   &= #8199; ­͏     ­͏     ­͏ &n= bsp;   ­͏     ­͏     ­= 47;     ­͏     ­͏     &s= hy;͏     ­͏     ­͏   Q= 99; ­͏     ­͏     ­͏  = ;   ­͏     ­͏     ­͏=     ­͏     ­͏     ­= ͏     ­͏     ­͏    = ­͏     ­͏     ­͏   &= #8199; ­͏     ­͏     ­͏ &n= bsp;   ­͏     ­͏     ­= 47;     ­͏     ­
<= td align=3D"left" class=3D"content" width=3D"698" style=3D"text-align: cent= er;">=
<= td align=3D"left" class=3D"content" width=3D"562" style=3D"text-align: cent= er;">
<= /table>
Forwarded this email? Subscribe here for more
=

How to co= mmunicate tradeoffs so leaders will listen

Tactical tips f= or teeing up critical decisions without pissing leaders off

Tara Seshan
∙
Guest post
<= td height=3D"16" style=3D"font-size: 0px; line-height: 0;"> =
READ IN APP
=
 
<= /div>

👋 Hey, I’m Lenny, and welcome t= o a 🔒 subscriber-only edition 🔒 of my weekly newsletter. Each week I tackle reader questions a= bout building product, driving growth, and accelerating your career. For mo= re: Best of Lenny’s Newsletter | Hire your n= ext product leader | Podcast = | Len= nybot | Swag.

Upgrade to paid

✨ Updates from Lenny and Friends Summit ✨

We’re excited to announce two new speakers who&= #8217;ll be joining our legendary lineup:

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

  2. Jiaona Zhang (JZ)&#= 8212;CPO of Linktree. Formerly, SVP at Webflow, Head of Product for Homes P= latform at Airbnb, Senior Director of PM at WeWork, and PM at Dropbox

Some of the speakers who’ll be joinin= g us

Apply now

Applications are still open, and approvals are going out w= eekly. 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 r= equest on your team. How you handle that ask, and how well you’re abl= e to articulate the tradeoffs required to take on this new work, is a PM su= perpower. It’s one that can save you and your team from unnecessary s= tress while helping you do what’s best for the company’s future= =2E

Newsletter Fellow Tara Seshan kn= ows 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 Pr= oduct for two years at Watershed, and founded a health-care startup as= an early Thiel Fellow. 

Below, she s= hares her hard-earned playbook for making tradeoffs crystal clear to even t= he 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 c= alled The Red Queen, and writes about the friction between our private= and working selves at Working Assumptions. Follow her on LinkedIn and

For years, communicating tradeoffs to senior leaders was one of = my biggest challenges. While presenting the pros and cons between two prior= ities, I’d somehow always end up committing to doing both<= /em>, and in less time than I had planned. As you’d expect, thi= s 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 othe= r side of the table, I watched others make the same mistakes I had. I reali= zed I hadn’t been framing tradeoffs correctly. 

For example, in an attempt to force a choice, I used to say things lik= e: 

It turns out that statements like these are counterprodu= ctive. They actually invite leadership teams to avoid= the choice you’re presenting. It’s clear to me now why the ans= wer 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 de= cisions. 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 to= ugh product roadmap conversation. 

How t= o frame tradeoffs effectively 

= 1. Repetition doesn’t spoil the prayer 

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

This in= volves a lot of repetition of your priorities, your projects, and your stra= tegy (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 thi= s up-front planning and evangelism, but my favorite way is to create a publ= ic and ongoing stack rank (OSR) of projects:

Here’s an example = (and template)

= 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 resou= rcing cutline. Here’s a template for an OSR (remixed from one cr= eated by my friend Brie Wolfson).

Th= e 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 prior= ity for your team. It changes the conversation with other teams from “= ;Why can’t we do this one extra thing?” into “Do you agre= e that X is more important than Y?”

I lik= e to make the OSR document extremely accessible to everyone around the comp= any. I present it at the smallest provocation. I always share it with the t= eam during fortnightly GTM catch-ups, embed a slide version in executive pr= esentations (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. 

=
An example of what I might present at a fortnightly sales = and product sync—repetition doesn’t spoil the prayer!

On one memorable occasion, I mappe= d the top 10 features on our OSR to the Billboard Top 10 and turned the fea= tures into specific song lyrics (“Metered billing-oh-na-na” to = the tune of Camila Cabello’s “Havana,” anyone?). I will n= ote 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-functi= onal team remembered our 10 most important features. 

Can you believe I used to send this type of thing in Slack to m= y team? This will haunt me till my dying day. = But 2019 was a different time. 

2. “Steelman the r= equest” to find your blind spots

Imagi= ne 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 shou= ld 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 larg= e 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 con= cludes that you should really do this new request—your case folds. An= d, 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’v= e been avoided if you’d “steelmanned” the new request bef= ore the meeting. Steelmanning is a technique used in debate where you prese= nt 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 e= xpert 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, ¹ and asked it to advise me as if it were my career coach. It doe= s a surprisingly great job at helping me respond with curiosity. 

When you steelman a request, you’re not neces= sarily 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 m= ore 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 w= as famous for forwarding customer requests sent to jeff@amazon.com with sim= ply a “?” to the unsuspecting Amazon employee.)

In this situation,= most PMs would think, “How can I explain to the CEO why finding scre= ws on Amazon.com is a low-priority, low-impact issue?” Instead, the P= M steelmanned the request.

He looked into the da= ta and investigated the issue deeply, even though it seemed trivial. After = he spent days digging into the data and talking to customers, he realized t= hat the concern wasn’t just about screws. Screws were a representativ= e problem. It turned out that anything on Amazon that= was unbranded and “specification-driven” rather than “br= and-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 issu= e behind the seemingly trivial problem. 

F= ixing this class of issue, rather than the specific issue of just screws, r= equired a meaningful amount of engineering and product work. It likely dera= iled the existing roadmap to make that possible. But the PM now knew it was= a problem worth solving. 

3. Company first, team second

Even 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 o= f these goals during your planning season. But the company goals are more t= op-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 prioritiz= ation decision for the company instead of a locally optimal decision for yo= ur 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, n= o matter how well I argued my case. Stripe had been focused on global expan= sion. As a result, the payments leadership team would deny requests that di= stracted them from those goals. My team goals around adding subscriptions f= eatures weren’t going to directly and obviously support global expans= ion, so I was rejected in favor of other teams’ requests at every tur= n. 

At the time, I was incredibly frustrate= d. I had faithfully communicated my team goals and how these features achie= ved them, I thought. But I was completely missing the relationship between = my team goals and the company goals in my communication. No wonder these te= ams didn’t think the tradeoff was worth it! Since my product really <= /span>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 everyon= e in the room orient around what really matters. And if you = can show a more significant impact on the company goals than the alternativ= e, it provides a very strong case for prioritizing your solution over other= s’. 

4. Predict the= future, just a little bit

Most incoming req= uests are framed in the context of a short-term goal. But as a leader on th= e 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? W= hat will happen to team morale if the team works nights and weekends for an= other quarter? Another two quarters? You should explicitly lay out these pr= ioritization 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 produc= t teams should think beyond that time period. Thinking and communicating ab= out the long term will help you be more persuasive with leadership (who are= usually desperately trying to balance “delivering quarterly results&= #8221; with a big-picture vision). It can also help identify gaps in the pl= an 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 in= tervention. But the company wasn’t ready to solve that problem. Leade= rship 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 incr= ease analyst efficacy. This approach was guaranteed to help the company mee= t the demand surge, but it would come at great cost to the long-term unit e= conomics and product-building.

Steve believed = that we were making the wrong tradeoff, especially in light of technology d= evelopments 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 exper= ience and impact analyst throughput. But in the long term, this reprioritiz= ation of efforts would be meaningfully better for the company. A more autom= ated solution would dramatically lower marginal operating cost. It meant th= at 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: 

  1. A deeply = detailed picture of what the 3- and 15-month outlook might look like if the= company followed his automated-future vision

  2. A roadmap of specific features that made the long-term path come = alive, demonstrating how this path required a more minimal short-term trade= off than everyone had assumed

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 al= l his detailed work, that the tradeoff was less dramatic than they had assu= med. 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 pa= th the top companywide priority for the year. To put the cherry on top, Ste= ve gave the new priority a catchy, memeable name (“Transform Measurem= ent!”) that spread like wildfire throughout the organization. 

Next time you get a request to prioritize something tha= t will hurt the company in the long term, challenge it! Leadership teams wa= nt to do the right long-term thing, but there might be a short-term-oriente= d fear holding them back. If you can lay out the long-term vision while str= iking at the core fear behind the short-term thinking, your vision becomes = the obvious best choice.

5. Always c= ommunicate an opinionated decision

You have = mastered the details, you’ve thought through the problem, and youR= 17;ve talked to a ton of stakeholders. But equally important is that you ma= ke an opinionated proposal for the solution.

Teams oft= en shy away from having a POV, deferring to leadership to choose between tw= o unbiased options. But people forget that they have more context on the is= sue 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 executio= n, but you should also be invested in the decision itself.

Presenting an opinionated decision can sometimes be tricky. In o= rder to persuade leadership, I like to hammer home my point with a dedicate= d 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:

  1. As part of w= riting the document, I always put the decision right at the top—the &= #8220;bottom line up front” (BLUF). 

  2. In the “Situation” section, I elaborate on the cont= ext of my roadmap and priorities. Make sure to frame the company priorities= in this section and how they relate to my priorities. I highlight the part= of the roadmap that is to be traded off against the new request. This shou= ld feel like common knowledge already, but remember, repetition doesn’= ;t spoil the prayer!

  3. In the “= ;Complication” section of the document, I outline the request that my= team received. I steelman the request and outline any data I might have co= llected. I use qualitative data heavily as part of my narrative because it = makes the issue come alive for readers. I include any risks associated with= not taking action. 

  4. In the = 220;Question” section, I directly present the key decision as a succi= nct tradeoff to leadership: “We must choose between [X, new request] = or [Y, existing item on OSR]. Should we do X or Y?” I then explain wh= y it’s a tradeoff between those specific items.  

    5. <= li style=3D"margin: 8px 0 0 32px;">

    In the final “Answer” section, I = conclude with a more thorough explanation of my decision. I project the out= come of making this decision. I also try to answer any big open questions w= ith a hypothesized outcome (indicating my level of certainty!). 

Here’s a template you can use for that tradeo= ff document, heavily based on SCQA. 

If I&= #8217;m verbally discussing this document in a meeting, I’ll start th= e 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 r= ecommendation and outlining the decision-making period (“I’d li= ke 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&= #8217;ll talk about it. Ideally, thanks to steelmanning the argument prior,= there isn’t anything new! 

Three-qua= rters of the way through the meeting, I’ll know if it’s converg= ing 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 con= clude 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 co= nsensus, I’ll try to flag that as soon as possible. I still try to en= d with some very specific actions, such as following up with the decision m= aker 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 cours= e, the only “bad” meeting in this context is one that ends without clear next steps and a timeline to get to a decis= ion! 

Tradeoff traps

Now that you’re armed with the tools to communicate tradeof= fs and the terms of a decision, what could possibly go wrong? Unfortunately= , there are a few tradeoff traps that are perfectly positioned to lure opti= mistic, productive, and structured product leaders.  

1. The “peanut butter” trap

Imagine an executive asks you to build this very exciting featu= re—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 reque= st adds up. It’s easy to understand why the team wants to do these th= ings: 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. Th= ey find that their roadmap is suddenly made up of many cute features, leavi= ng no capacity for the big and important work they need to do. =

By treating all of these small requests as real trade= offs, you can keep the team on task. 

2.= The “just one more engineer” trap

When J= eff Huber, a former Google SVP, asked product leader Peter Chane if Google = should acquire YouTube, Chane balked at the prospect. He said, basically, &= #8220;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 produ= ct team will always need “one more engineer.” However, adding m= ore 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 elimin= ate the need to prioritize new requests. Planning will always scale to matc= h capacity, and you’ll still always have more incoming requests than = you can satisfy. 

Instead, you should prior= itize requests based on their importance to the business first. Once you ag= ree on priorities and tradeoffs, you should then ask for the capacity to ex= ecute on those specific priorities. A better answer with regard to YouTube = might have been something like (based off Chris Sacca’s response² here): 

“Positionally, Goog= le is focused on trying to get all the world’s video on our platform,= while YouTube is specifically focused on creating and hosting user-generat= ed video content. Unlike YouTube, we, Google, have to play nice with the me= dia and ISPs, while they’re making media companies mad by catering to= users. The real question here isn’t about tech, or specific resource= s, it’s about position. We have a tradeoff to make: (1) we can buy th= em, once we have enough leverage to confront media companies directly, (2) = we can take the same strategy, but we have to prepare the rest of Google fo= r the fallout, or (3) we can pursue our existing strategy and lean into the= advantages we have, like the recent deal we did at the Olympics in Torino.= I think we should do 3. And if we do 3, we’re not staffed to do it w= ell. I need [X] people to do it right.” 

3. The “but we have a framework” trap<= /h3>

PMs love frameworks, which can indeed be helpful in m= aking decisions. Frameworks help you order by relative priority, but you= 217;ll still always be evaluating line items on the margin. Also, framework= s tend to be abstract. They can only be put into practice and adjusted thro= ugh individual cases. Most importantly, business frameworks aren’t la= ws of physics. They may turn out to be wrong when new data comes to light.&= #160;

In the case of a contentious tradeoff, it can ma= ke sense to reference the existing framework as a start. But don’t st= op there! Elaborate on the problem by raising details that don’t quit= e fit the framework. As part of steelmanning the argument, think about wher= e the framework might be wrong. If it doesn’t make sense with new dat= a, mention that and throw it out. A framework doesn’t excuse you from= diving into the specifics on an important decision. 

Trap examples

Now 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. 

  • “We are thin on resour= ces”: This presents no options, with no context on existin= g priorities. The “just one more engineer” trap!

  • “Al= l of the engineers on the team are working on this other feature. Maybe we = can sneak it in if they can do it in spare cycles”: No opt= ions presented, and no context on the existing priorities. The peanut butte= r trap!

  • “I’m not sure if this is really high-priority”= : It doesn’t provide details into what is a priority. The = framework trap!

  • “I have many things higher in my OSR”: Closer, but doesn’t yet present a specific option of what might= be cut. It’s the framework trap!  

  • “Yes, we could= deprioritize our new list page”: An option, but how is le= adership supposed to know the value of the list page? Do they care? It̵= 7;s the framework trap yet again!

  • “No—to build = the feature, which might help a sales demo with one big client, we’d = have to push out support for single sign-on for enterprises for a quarter, = which means these 10 clients won’t be onboarded in that time. I don&#= 8217;t think it’s worth it for the company; we won’t hit our us= age and revenue goals”: The exact right framing! A little = OSR reference couldn’t hurt, but this is great. 

    • =

Ultimately, the best way to frame a tradeoff is to p= ut yourself into the CEO role: If you were responsible for the overall succ= ess of the business over the long term, what would you want to know about a= prioritization decision? What information or arguments would help you choo= se? 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 study

Thanks, Tara! For more from Tara, check out her ne= wsletter, Working Assumptions, and follow her on LinkedIn and X.

Have a fulfilling and productive = week 🙏

<= hr style=3D"background: #e6e6e6; border: none; height: 1px; margin: 32px 0;= padding: 0;">

👀 Hiring? Or looking= for a new job?

I’ve got a white-glove recruiti= ng service for senior product roles, working with a few select companies at= a time. If you’re hiring, apply below.

Sincerely,

Lenny 👋

1<= div class=3D"footnote-content" style=3D"display: block; font-size: 16px; li= ne-height: 26px;">

Prompt: Imagine you= 217;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 t= o ensure that I have the most information to make the right decision instea= d 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 reque= st 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:

A guest post by
<= tr class=3D"post-contributor-bio-body-table-row">
Tara Seshan
Hip hop enthusiast m= asquerading as a San Francisco technologist. I write about building great s= oftware and the future of work. I make pancakes for my neighbors and dispen= se unsolicited fashion advice.=20
S= ubscribe to Tara
=

You're currently a free subscriber to Lenny's Newsletter.= For the full experience, upgrade your subs= cription.

= Upgrade to paid

=
 
=
<= tr>
Like
= Comment=
=
Restack
 

© 2024
2443 Fillmore St.,= #380-8231, San Francisco, CA 94115
Unsubscribe

3D"Get3D"Start

3D"" --65e763ba9ec42d7f0377b908a7fb10bcb3217234047516df305e7055353e--