Lenny's Podcast: Product | Career | Growth
00:16:19 · Jessica Fain
[00:16:19] S0: One assumption I have of how folks may misunderstand this skill is that they have to be a yes man. They have to take everything that the leader said and do exactly that. That is absolutely wrong. You get paid to have an opinion, you get paid to be a domain expert. And in a lot of ways, your executive is looking for you to be the deepest person in the room, especially if they're good at their job, right? They're looking for you to be the expert. And so, bringing your expertise to bear is absolutely crucial. Ilan Frank, who was my boss at Slack as well, is now CPO of Checkr, he always had a customer anecdote in his back pocket. I can hear him in my head saying, "I was just on site last week with so-and-so and they said blah, blah, blah." He always brought his expertise to bear, and many of the executives at Slack were not from a strong enterprise background, so he could bring that to the forefront. I think that has to be married again with that curiosity and empathy. If you hear something that you don't agree with, this is something that a guy my team does super, super well right now. He'll hear something that flies in the face of the data he's seeing, the insights he's gotten, his experience in his domain expertise, and he'll say, "That's so interesting. What led you to believe that?" That kind of question is actually curious, about this person said something that I think is dumb, but there must be something behind it. And so if I actually care what's behind it, and what you end up doing in that question is co-creating with the person who offered the opinion in the first place. You're able to say to them, "I'm interested in what led you to that belief, your experience. Did you have a meeting last week? Are you getting pressure from the board right now in a certain way? What is leading you to that belief?" I think one thing that really trips people up is execs are so good at seeming certain. They say things in an authoritative way with confidence, with surety, because so much of their work is having to make those ultra-fast decisions with little information. But if this is someone who is also a learner, who also has a growth mindset, then if you are able to help them unpack why they believe something and then respond with your own domain expertise, you are able to get to a better solution together.
00:18:50 · Lenny Rachitsky
[00:18:50] S1: I love these very tactical phrases and tips for how to deal with someone, say a leader. Let's just say this is like they're a director of product, VP of product, CEO that you're trying to convince to agree to plan. So the phrase you're suggesting here is, "That's so interesting. What led you to believe that?" Anything else along these lines, say you're pitching a product or an idea to say a VP of product and they're just like, "Hmm. What else works?"
00:19:17 · Jessica Fain
[00:19:17] S0: The earlier that you can understand the belief system and the things that are important to them, the better off you're going to be. So very, very early on in this process, what is top of mind for them? I can count on one hand when I was chief of staff, how many people asked me for advice before going into a product review with our CPO or our other executive team to say, "What do you think is most important to them right now?" Use the people around them, their EA, their chief of staff, the people who have successfully pitched ideas in the past and say, "What worked? What do you think they're worried about? What are the risks?" And in an age of the tools of AI that we have, this is so much easier than it's ever been, right? You can ask Slackbot, "What has Rachel been posting about lately? What do you think is most important to her?" A colleague of mine, a peer on our product leadership team, trained at GPT on a bunch of transcripts from past product reviews that are all publicly available, and we expect that our PMs are running their PRDs or their pitches through that, to say, "What's Rachel going to push back on? Where are their weaknesses in these ideas?" You can also train things on, "Where are your own weaknesses? I know I've gotten feedback in the past that my data is a little thin or that this kind of UX thinking is thin. Give me feedback on that." Claude's amazing for this. And so, I think that the first step is actually just saying, what's important to them? What do they want to hear and anchor on that? I think the second piece is going in to learn not to convince. And the earlier on you do that, the better. So we have something at Webflow called Office Hours. As early as you can, you are having these conversations to align on strategic direction, maybe even before you have a one-pager. We implemented something at Slack with Stewart Butterfield, because we realized we were coming to him with done designs and he was like, "What the fuck is this? This is completely different than how I had this in my mind." So Ali Rayl, early Slack employee implemented something called, "Hey, Stewart Butterfield, what do you think?" And we would just sit with him for half an hour and say, "What do you think on this topic? What's your belief system? What's your past experience?" And we started with a user interview, right?
00:21:31 · Jessica Fain, Lenny Rachitsky
We started with, "We actually want to download your expertise here." And I think that when you engage execs in that way, it's really, really valuable. One of the things I see people do poorly is, they don't ask for the time. This is sort of in counterpoint to what we were talking about before with how busy their calendars are, but they're afraid to ask for more time to get that insight. But sometimes if you don't, you miss the point. [00:21:57] S1: Something that we hear a lot on this podcast, is as a product leader, as a leader of any kind, you want to have a point of view, you want to come into a discussion with, "Here's our options, here's what I think is the right solution." And then at the same time, as you're describing, you want to come across as, I want to learn. I'm not here to convince you. I'm here to just help understand your worldview and where you think the right path is. How do you think about just those two, that balance of, I have something I believe is right and, okay, but I'm here to learn and get your feedback and see what you think makes sense.
00:22:30 · Jessica Fain
[00:22:30] S0: Okay. So my advice on this may be a little paradoxical, because I think people make mistakes in both directions on the polls here. On the one hand, I think there's an error people make of trying to show too much work, trying to tell too much upfront proof point. We talked to 16 participants from these 15 GOs and this is the statistically significant and the exec is like, "I'm so bored, I'm going to die." I remember I did this in a review once and literally the person I was most trying to convince glazed over, got on their phone and I totally blew the meeting because I was trying to prove that I had done my homework. Put it in the appendix, right? They don't need to know every single detail. The baseline expectation is that you did your job, and that this is built on a solid foundation of your domain expertise. On the flip side, I think there's some balance of showing your work, that helps elucidate why your solution is best. So one of the mistakes I see people is doing is giving only one option. I think that people, if you say, I mean, this is also like classic pricing and packaging strategy, give three options and the Goldilocks in the middle is the perfect one, right? But I think that what that actually allows you to do is say, "Hey, we considered. We are not dumb. We did not miss something. You think we missed something, but no, no, no, we actually considered this." So we had a recent product review with my manager, Rachel Wolan, she was a recent guest on How I AI, and- ... she was a recent guest on How I AI, and we brought a doc, a sort of reasonable approach to what we thought was the sort of problem and strategic space we were going after. It didn't go well. It really didn't match her expectations. And the feedback she gave us, which was really, really the right feedback, was I don't understand how you're thinking about the permutations if possible here because we had only given one option set. And so what we did following that review is we said, "Hey, we really want to sort this out. We want to get moving. We want to show that we can really get building on this product. And alignment is the next stepping stone for that. Can you meet in two days?" And we turned around a new doc in two days that actually showed all of the options we had considered, but hadn't brought to that first review.
00:24:53 · Jessica Fain
And once we elucidated all the things we considered, and why we thought they would or wouldn't serve the outcomes we were driving and the technical complexity behind them, she was like, "Oh yeah, okay. I see why the solution that you're proposing makes the most sense for what we're trying to accomplish." But in the first version, in the first meeting, we hadn't shown that and we hadn't workshopped it through her. And so sometimes really tactically you want to have that available to you. It's not necessary to put all 15 options you considered, but at least be ready to show them. Have them in an appendix, have them in a draft Figma file, whatever it is. We used to have this rule after a design review with Stewart Butterfield. We'd go through the design review and he'd say, "No, do it exactly like this. I want the button here and the interaction to be this." And frankly, he always had better ideas than we did, but we would come back and we called it Stewart Butterfield plus two more. So we did exactly what he asked for and then two other versions that we felt good about. And then it gave us a forum for conversation to debate the merits of each type of approach.