What it takes to become a top 1% PM | Ian McAllister (Uber, Amazon, Airbnb)

If you forget about everything else, forget about politics, forget about promotion or having more, a bigger org or whatever, if you simply wake up every day trying to have the biggest impact you can, or if you're a leader trying to use your team to have the biggest impact you can in the company, how you do every part of your day, that's a really good guiding light.

Welcome to Lenny's podcast. I'm Lenny and my goal here is to help you get better at the craft of building and growing products. Today, my guest is Ian McAllister. Ian is the author of one of the most classic posts on product management, what Separates a Top 1% PM from a Top 10% PM, amongst many other pieces of writing that he shared online. Ian has managed over 100 product managers in his career. He spent 12 years at Amazon, where he built Amazon Smile and led the team responsible for growing Alexa internationally. He also worked at Airbnb with me. And now he's at Uber, leading global product for the vehicles platform, which includes making Uber's fleet increasingly electric and Autonomous. In our conversation, we focus primarily on two topics: what separates a top 1% PM from everyone else, specifically for new PMs and also for senior PMs, and we also dig deep into the working backwards process we get into how you can implement the process on your team and how you might be doing it wrong. There's also a bunch of links to templates and guides in the show notes, so if you want to follow along, definitely check those out. With that, I bring you Ian McAllister. This episode is brought to you by Mixpanel, offering powerful self-serve product analytics. If you listen to this podcast, you know that it's really hard to build great product without making compromises. And when it comes to using data, a lot of teams think that they only have two choices: make quick decisions based on gut feelings or make data-driven decisions at a snail's pace. But that's a false choice. You shouldn't have to compromise on speed to get product answers that you can trust. With Mixpanel, there are no trade-offs. Get deep insights at the speed of thought at a fair price that scales as you grow. Mixpanel builds powerful and intuitive product analytics that everyone can trust, use, and afford. Explore plans for teams of every size and see what Mixpanel can do for you at mixpanel.com and while you're at it, they're hiring. Check out mixpanel.com to learn more. This episode is brought to you by Athletic Greens. I've been hearing about AG1 on basically every podcast that I listen to. like Tim Ferriss and Alex Friedman. And so I finally gave it a shot earlier this year, and it has quickly become a core part of my morning routine, especially on days that I need to go deep on writing or record a podcast like this. Here's three things that I love about AG1. One with a small scoop that dissolves in water, you're absorbing 75 vitamins, minerals, probiotics and adaptogens. I kind of like to think of it as a little safety net for my nutrition in case I've missed something in my diet. Two, They treat AG1 like a software product. Apparently they're on their 52nd iteration and they're constantly evolving it based on the latest science, research studies and internal testing that they do. And three, it's just one easy thing that I can do every single day to take care of myself. Right now it's time to reclaim your health and arm your immune system with convenient daily nutrition. It's just one scoop in a cup of water every day and that's it. There's no need for a million different pills and supplements to look out for your health. To make it easy, Athletic Greens is going to give you a free one-year supply of immune supporting vitamin D and five free travel packs with your first purchase. All you have to do is visit athleticgreens.com/lenny. Again, that's athleticgreens.com/lenny to take ownership over your health and pick up the ultimate daily nutritional insurance. Ian, welcome to the podcast.

Thanks for having me, Lenny. I've been looking forward to this.

Me too. I'm sure you hear this a lot, but when I was a new product manager, very noob PM, the post that you wrote on what makes a top 1% product manager was really influential and really helped me figure out what to focus on and what skills are really important. And I find that it continues to live on as this very legendary post for product managers who are trying to figure out what to do. And I just reread it in prep for this post and I was just like, wow, this is like now that I'm on the other side, I'm like, this is so right. And so I'm really excited to dig into a lot of these things in person, sort of virtually in person and yeah, with you. So thank you again for doing this.

Yeah, man, it's awesome. I'm excited just to spend some time talking with you about product and we'll see what happens.

Did you expect the impact that this post had when you were writing it, when you're just putting this together, the impact that the post had in your career or just the PM industry?

Definitely not. I mean, I said lurk on Quora at the time and then I was, just kind of having fun reading things and answering some questions. And I used to, like, look for questions in the sort of Goldilocks Zone. They weren't, like, too high level of distract, like, how do you be a good PM? But they weren't, like, too, like, super specific. And this one was kind of right in the middle. And so I'd pluck off a couple of those. And I think more is a way to structure my own thoughts. You know, that was kind of what was interesting and fun for me to do that, not because I thought I'd have any kind of real reach, but obviously it's been cool to see that.

People reference it pretty often, and that's been. That's been pretty fun. We'll link to this in the show notes. If folks that are listening don't know what we're talking about, we'll link to it and you can check it all out and we're going to be talking about a lot of this stuff in the actual chat. But there's a couple of things there that are worth maybe drilling in on a little bit. One is just the impact that writing on the internet can have on someone's career. Like this one post I imagine had.

A lot of impact on the trajectory of your career. Is there something you could share there? Is that true? Yeah, it did. And there's another post, I think it was before this one, someone just asked about Amazon's product development process. And so I wrote about the working backwards process, which which isn't my process, I just used it and just described it and just kind of caught on a little bit there as well. I think those two, and then I started to kind of write more about people management and product management. And I think the value for me was so awesome just to like make connections with people in the industry. And it felt like this is, I guess, the 2010 or something like this, where a lot of Amazon people I sort of felt were just like so 100% heads down. It was a little bit of a secretive culture, not maybe like Apple, but it was pretty private. But I was kind of interested in the startup community and product in general. And so I think I spent a little time trying to engage with folks and I just made so many kind of great connections and relationships from this. I remember interacting with you and getting to know Jobot and other folks at Airbnb early on even before I joined. But obviously I'd credit this work and those relationships for me ultimately going there and so many great relationships and people I've met because of it. aside from just the little positive feedback. I mean, people tweet at me periodically, be like, Hey, by the way, just love this post and whatever. And so it's super gratifying.

You mentioned a little bit about your background, then we're about to get into that. And I want you to share all the things you've done. But the other piece there that I think is interesting that comes up again and again in the power of writing is it often just starts with you trying to collect your thoughts and putting it out there and then ends up, Wow, so many people find that valuable and it spreads. And so that's just like a really simple way of thinking about if you're starting to write online, just like summarize something that you've been thinking about that you want to just crystallize in your own head. There's this quote that is probably falsely attributed to Mark Twain and Hemingway often of just like, I don't know what I've thought until I've written it down. And that's super true with these things. And so that was a really good.

That'S a good example of this. Yeah. And I think with any kind of writing, it was probably less structured initially, but I would partially because I was trying to share something for an external audience, try to just organize it and make it compact and not too wordy or rambling. And I think business writing, I spent a lot of that time doing that at Amazon is so valuable because you've got to be a clear thinker to be a clear communicator. And so it's kind of, there's two tests in, in, in writing well or communicating well. It's both those things. So I found it's, it's pretty valuable and kind of sharpening your axe.

So these are the two things we're gonna focus our chat on is what makes a top 1% product manager and then the Amazon way of working and especially working backwards. So these are all good cues for where we're going. But before we get there, can you just spend just like a minute giving us a sense of some of the wonderful things you've done in your career and what you're up to now?

Well, I can tell you what I have done. I'll let others decide what's wonderful or not. So after doing like finance and economics in school, I made the logical choice and I got a job doing marketing in the beer industry. and then the next logical choice, I moved to Tokyo and sort of bootstrapped my way into software development without knowing Japanese or software development. Did that for a few years, came back to the States, working as a developer and a startup and then kind of a mid-sized company, and then moved to Microsoft as a program manager, or pretty much a product manager, the same thing there in that role. Learned some good stuff and then made a connection with Amazon and moved there 2006. and that was really the start of when I think about building my product toolbox and kind of leadership toolbox. So few different things I did over 12 years, a few years in retail and conversion. I then moved in sort of traffic and direct traffic loyalty when I created Amazon Smile. The role in Alexa, I led Alexa International, so sort of scaling Alexa and Echo to six more countries. And the last role in delivery experience and operations. So I led a number of different programs there and then recently UbeR, we're a senior director of product and tech for vehicles. So that means everything, all the tools that help fleets and rental companies make their vehicles accessible to Uber drivers so they can earn sustainability tech and electrification, our vehicle platform, and then creating a path for autonomous vehicles to come onto the platform. That's it.

Amazing. I just realized there's one thread through your career. is like autonomy and AI a little bit, right? With Alexa and then with Uber, with these autonomous car stuff you're working on now, is that something realized or is that accident?

Well, I mean, I guess you could connect those things. Obviously, both are, you know, machine learning, AI. I think the way I think about it is that I've done a whole bunch of different lifetimes, especially around e-commerce. And so it kind of allows me to cover the gamut. Plus, I guess I forgot to mention the time at Airbnb, you know, working with Jobot and you and Vlad and Dan and Shirley and there was focused on kind of building out the customer support technology platform. So that's another part of the sort of e-commerce platform covers the gamut.

Right. I forgot to bring that up too. I'm glad you touched on that.

I guess I skipped past that with the end.

The most transformative time, getting to work together.

That was awesome. That was awesome. I learned a lot from you too during that time.

What a time. This is a good time to chat about, speaking of Airbnb and all that, to chat about what makes a top 1% product manager. So, I know your post was really titled like, what separates a 1% PM from a 10% PM? But it feels like it's even broader, just like, how do you become a top 1% product manager? And I thought maybe a good way to start here is just, maybe just like run through the attributes that you've kind of found over the years, or like, here's the things that a top 1% PM needs to get great at. Maybe just run through 'em and then.

We'Ll talk through them in a little more detail. Yeah, I was gonna pull up my post here so I could actually refer to it. Do you want me to go through.

All of 'em or just kind of pick out a couple to touch on? Let's maybe just go through them quickly just to put them out there, and then I'll have some follow-up questions to dig into a few of them.

All right, sounds good. Well, the way I listed it at the time, think big, always want to be hunting for bigger impact, communicate. I think we'll probably touch on that a little bit. It's a super important for PMs as a test of their thinking and their communication. Simplify, how you can do more with less and have more impact is simplifying is a great way to do that. Prioritize, that's sort of, I think, the core skill after communication of a PM. And there's so many different lenses to view that. Let's see here, forecasting and measuring. I think that it's really important, you know, what separates product managers from consultants sometimes is you forecast and then you execute and then you measure and validate and that helps you build your instincts. Just obviously the core execution of just shipping and doing what you said you do, understanding technical trade-offs is that you don't have to be a software engineer to be a great PM. But the more you learn about technical tradeoffs, not just product and customer tradeoffs, that will help you simplify and get more yield out of your resources. Understanding good design, if you're working on anything customer focused, that's always going to help you think in the mind of a customer or a user. You don't need to design, but the more you understand helps. Writing effective copy, this goes a long way. Not to get close and not to sub out the copy to somebody else, but to get good at communicating with a couple words to your customers. That's a great skill. Those were the ones that I wrote at the time, you know, I guess 10 years ago. And then I refreshed the, the posts recently in my newsletter, and I added a couple new ones, honestly, because as I reflected back, there was a few that, that I think a lot about these days that I missed the first time around. Earn trust with others. That's so important as a PM, but especially if you're going to grow as a product leader. becomes even more important. And I think trust is the currency of a product manager and a product leader, especially if you're going to grow in your career. Digging for data, it's out there and you got to develop the tools to go find it, not to depend on your analyst or what's in the reports today. So that's a really important skill for anyone in product. And probably the more junior you are, the more important it is as you're really in the weeds there building product. pushing back effectively. This is an art and a skill, but I think your ability to do this is pretty correlated with your ability to grow and succeed as a leader. Because if you say yes to everything, you're gonna go nowhere. Adapting to change, how you react to change will obviously impact one, your mood and your morale, as well as how effectively you can kind of rally yourself or your team. And then driven by impact, not promotion. ultimately that's what you want to wake up every day thinking about how to have an impact for your business. And that will be an indicator on your likelihood of promotion. So do that instead of just focusing on how to get promoted and having that guide your day.

Awesome. So it's a long list. There's a lot that a PM needs to be good at, which I think if you're a PM, you already know it's like a wild, crazy, impossible job to have everything nailed down. And at the end of this post, even mentioned, like you've never met a 1% PM that does all these things. and I think that's important. Like no one's gonna be the best at all these things. And so just to drill down a little bit and get a little more focused, say you're a new product manager of these, I forget how many there are, maybe 10, 12. What are like the top three that you think new PMs should get most good at and focus on?

Probably communicate, you know, prioritize and execute. I think those are just the core building blocks. Other ones will be more important as you grow and become more senior, but those ones, no matter where you are in your product career, I think are super important. Being a better communicator is something I've been working on my entire product career and I'll be working on until the day I stop. I remember years ago I was at Microsoft, I first kind of effectively product manager role and my product unit manager Thomas came by the office and I think he asked me like, When is this gonna ship? And I was like, well, this thing is taking a little bit longer here and this other thing and yada yada. and it sort of gave a bunch of background, but I didn't really answer the question. And I got a little feedback from him, like that's not really the, you know, ultimately he's like, he's waiting for a date. And so that, you know, I just sort of reflected on that. And that was kind of, as I remember, my, my journey to try to be a better communicator over time. And I'm still on it. When I went to Amazon, I worked for Kim Rackmiller, who is our, I think at the time, SVP for worldwide discovery. And I think she was Amazon's first TPM and and she was tough, but super smart. And so that was also kind of an early experience to kind of learn from her. And sometimes you get some feedback when you didn't really answer the question. And my first boss, Russell, I kind of organized and started to gather this thing called the Book of Kim. And so we would, we would gather these best practices that we learned from her elsewhere, you know, avoid weasel words, answer first and then explain, own your problems, and started building this. And then I sort of extended that over time and added a bunch and wrote a post called the Operator's Manual. I sort of tried to gather all these things together. But it's such an important thing and the stakes get higher as you work with more and more senior people. But if you can get in the habit early of, you know, answering a when question with a date, knowing how to use numbers to answer questions, and honestly just learning from feedback and kind of grade yourself after you get feedback on a dock or after a meeting or after answering a question in an elevator. And if you try to say, gosh, how could I have done that better? and then try to get better, you can. And you can go far if you just focus on that and all the other 150 skills of a product manager. But if you don't have that, it's unlikely that you're going to really go too far in your product career. So that was communicate, I guess, prioritize is the next one. And so I think this is like the number one key tool of a product manager is prioritization, because so many things come from, from, you know, being a good at prioritizing. And it's not just like what what project do you do next or do you do this project or that project? There's so many different dimensions to prioritization. There's sort of which themes are you going to prioritize in a roadmap and which projects within a theme and how are you going to sequence those projects, how much of a project you're going to build, and also just time management is also a prioritization function. It's like what are you going to choose to spend your time on? You know, which things are you going to really go all out to make great and which things are you going to kind of starve for attention or just not do? given the same amount of skill, intelligence and resources, a product manager with a great innate ability to prioritize is going to generate 5x the impact of someone without that skill. My early, if you could call it success at Amazon, I think was like completely dependent. It wasn't because I worked smarter or was, I was smarter, I worked longer hours, or I was more technical than other people. I think it was just because I was like one super hungry for impact. you know, and if there was a number or a metric that measured success at the business I was running, I wanted that to go up into the right, not to hit a goal, but just to go as far and as fast up to the right as possible. And, and I said, I think it was just like working with the team to hone in on the projects that would do that with the greatest leverage and just marshaling all the team's resources. So that was a good start. That was a fit with Amazon in terms of working backwards from a fitness function or a metric. And so did that with the first team I was there and then again later managed the gifting business. And so it just was one skill that I think helped me as well as make up for maybe some deficiencies I had. I don't have the biggest brain in the world and I don't have the biggest working memory and I wasn't the most technical, but by trying to really get good at that prioritization, I think that's helped me and it still does. I think execute is the third one, which is no surprise that like every PM has to execute. and I think it's, you know, assuming you prioritize well, then execution means sort of molding what you want to build into a simple, compact package that has the highest impact possible. And then you also, it's execution is a big function of the team you're working with. So it's your designers and your data science folks and especially your engineers. So anything to do with how well they're doing their jobs or how well they're resourced or whether they're getting better and better at every Sprint, like you have some amount of ownership in helping make that happen because that directly impacts your team's ability to execute and ultimately your reputation as well for being able to execute. You know, sort of the drive that goes into execution, product managers are the motive power behind execution and impact. And if you stall out or you don't do your job, the project's probably going to stall out as well. And so you're the ones like with especially with a TPM, if you're lucky enough to have one in the back of the ship, kind of beating the drum and driving everyone Again, lots of people have written a lot of stuff about execution and there's a lot to it, but I think those are probably the three I'd focus on.

Awesome. And what's interesting about these three is if you look at the rest of the list, like think big, understand technical trade-offs, understand good design. I think what I would take away from this is those are the things you don't need to focus on that much when you're in EPM. Focus on, as you said, communication, prioritizing, executing. Focus less on these other things because later, they'll become more and more important and obviously, you know, learn as much as you can. But it's almost easier to think about the things you don't need to stress about when you're starting out.

Yeah, I think that makes sense if there's a core, right? Or like think about a year one as a PM, focusing on those things and you can develop other skills over time. But yeah, I think you're spot on there.

If we were to go back through these three, just maybe as a last question, and you may not have an answer to this, But if you think about communicating, prioritizing and executing, is there like one tactical thing you could suggest that a PM listening to this can do to get better at one of these things? Is there like a trick you've learned of like, wow, this is one way you could level up communicating, executing, prioritizing or not?

The closest thing to like a checklist, right? The post I mentioned, the operator's manual, that was the closest thing to like, if you do these things, these specific actions, I think it'll go a long way because a lot of them are guided around not doing the easy pitfalls and communication mistakes like rambling. If you're asked a question and you explain and then maybe you get to the answer, it's if you just think answer and then explain or sometimes answer and then shut up, that actually is a tactical thing you can do to get better at communicating. And there's some other tips in there as well. So that's, that was my attempt to try to encode to to take some of the ones that we gathered early at Amazon, add some more. The others are, yeah, there's no just simple trick, unfortunately, to prioritize other than, I mean, I think working backwards is a good technique to have impact, to guide your prioritization. And that is something where it's not a simple tip, but there's a set of practices and behaviors that you can do that will ultimately lead you to prioritize better. Awesome.

We'll talk about all that.

And then I think communication, the simple tip was just like, grade yourself after you communicate and try to just take a moment and after a while you'll just do it naturally to think about, gosh, how would I have answered that question better? And so the next time you could try to answer that question better and it's just a continuous improvement process. Or maybe even ask your manager, Hey.

What could I have done better in terms of how I communicated in that last meeting or that last email? Yeah, absolutely.

Absolutely.

Okay, so then coming at it from the other direction, say you're a senior PM, what are three of these attributes that you would suggest folks focus on to get better and level up in their career?

Gosh, it's still communicate, to be honest. Like, I think that's the one at every level of product. It just, the stakes are higher. I think think big is one for sure. There was a phrase, I think Warren Buffett in the Berkshire Hathaway letter used at some point was like, at our scale, we got to hunt for bigger elephants. And so I think at any scale as a PM, whatever your idea is or whatever your solution or the problem you're solving, take a minute at the beginning to say, could this be bigger? Could this be a bigger thing and more impactful than the initial idea, even if the initial idea sounds big? So that's a sort of a tool to, and that's often where I'd start when my PMs were sort of sharing an idea is I try to expand it to the degree it might be expanded. Think about it from that perspective. And then maybe you want to still start small, but with a bigger vision in mind. Earned trust is a huge one, and that's kind of why I added it more recently. And it becomes even more important as you get into senior roles because that's I think it's truly like the currency of a product leader or probably any leader in any function. Because if you want to ask for more resources to do something bigger, if your leadership doesn't trust you to use those resources well or do what you said you're going to do, you're probably not going to get them. But if you've built trust that you're a good steward of resources and you make a lot of impact with a given team, that's directly going to correlate with your ability to gain more resources. Trust is just built by repeatedly setting and meeting expectations. and I think that's a good kind of mantra to think about as a PM. Like, you know, my meeting the expectations that I set and not just doing good things, but like calling your shots, forecasting, setting a goal and then hitting it. And if you do that repeatedly, you're going to be in pretty good shape. And there's like so many practices as a product manager or product leader that build trust. You know, you tell the truth without fail and you launch when you say you'd launch and you launch what you said you launch and you own your mistakes. And then the other practices just lose trust. If you lie, if you're evasive, if you don't ship what you said you're gonna do, if you ignore your mistakes or you repeat them. And so I think just simply having high standards for yourself and think of trust as that like currency, that's gonna correlate well as a PM, as a GPM or director of product in any level, that's the thing that you wanna build.

So thinking big, building trust. Was there a third?

I think maybe the last one, which is, is, is certainly relevant for a PM, but is really true as well, is like driven by impact. And that if you, if you forget about everything else, forget about politics, forget about promotion or having more, a bigger org or whatever, if you simply wake up every day trying to have the biggest impact you can, or if you're a leader trying to use your team to have the biggest impact you can in the company, which will influence how you build your roadmap and how you do every part of your day. That's a really good guiding light. And I remember my first 10 years at Amazon, just naturally, not because I thought about it, I was just hungry to have an impact, take my business, grow it as fast as possible. I wasn't maybe loosely thinking about promotion, but I wasn't thinking about it. I didn't ever talk to my manager about it and I wasn't bringing it up. I was just focused on taking my book of business and making it bigger. And then the net result was I was promoted Several times and I did grow in my role, but that wasn't what drove me. It was just the impact.

Would you say that driving impact is more important for new PM or senior PM? Like it feels like impact is like the soup within which all PMs swim and that's like constantly important. But it's interesting that you mostly put that into the latter part of a career. Do you feel like with new PMs in your team, you're less expecting them to think about impact and focus on impact?

Well, I think for junior PMs, if you're a brand new PM, then yeah, you want to have an impact, but you're really just like you have a project or a feature to ship or something like that. And you're often not necessarily told what to, given a lot of latitude to build your own roadmap, but you're asked to ship this. Do you want to spec it? You want to execute and do it? But increasingly as you grow, There are opportunities to sense out and try to have a bigger impact, maybe, and then start to influence prioritization or roadmaps. It's just that the expectations, it goes from being a nice to have as a junior or first time PM to as you get a little more senior, hopefully if things work the way they should work, that's really how you're evaluated. Yes, you want to treat your team well and you want to do a whole bunch of other things, but take two people, one has a massive impact on the business and one who doesn't, then the right way to work should be that first person should be the one that grows and develops and is tasked and with bigger challenges just because if you're impactful at a bigger challenge, that's even more important for the business. So I think that's a good kind of way to think about the flywheel of product leadership. Yeah, it feels like a lot of.

Times you get lucky as an UPM, you work on a project that ends up having a lot of impact that you didn't necessarily drive. You just happened to work on something that, wow, this was a huge deal and that feels like an important thing to optimize for a little bit in your early careers, like work on something that's likely to have a lot of impact, even if you're not responsible for.

Setting the strategy and prioritizing. Well, I think that's true if you have a choice in where you work in product. If you, you know, if you have a choice to work on something that's part of like offense, you know, something that drives the business and like, you know, it's true that executives wake up if something drives dollars or customers or offense things and, you know, it just maybe shouldn't be this way, but a little less interested in things that may be less than a risk that just the risk never happens. It comes to pass or a cost center that operates a little more efficiently. So that it's one lens where that might relate to your success. I think also who you work for, you know, and I think most of us don't get to choose that, especially early in our career, and either works out in your favor, which is great. And that was the case for me, especially at Amazon, some of the leaders I work with, but sometimes it doesn't. But I think the more that you can suss out who you work for because then the better they are at these skills and prioritizing one, they're just going to be a better teacher and a better role model to learn from. So I think that's an important thing to think about in any kind of job change.

To close the loop on this piece of, for more senior PMs, the skills to focus on, you said thinking big, building trust, and driving impact. I'll put you on the spot and give you two options, two directions to go with this. One is if you want to get better at each of these three things, do you have any one thing someone could do? Or what does great look like for thinking big or building trust or driving impact? Those are two options.

That was like six questions there, Lenny. Let me see here what I'm answering. Well, I think the think big one is interesting. And one way to think about thinking big, especially as you grow in your career, is is most people are like operate within a box. You know, there's a box of there's product management and there's these are the things that product managers do. And you basically have build a roadmap and you prioritize features and you work with Eng. And so that might be the typical kind of product scope in tech. Most of my roles were ones where I was kind of a GM, but a really product focused GM. And so I naturally found myself taking a much wider view of what product Across disciplines. And I was lucky enough that I had engineering teams and marketers and, you know, analysts and other folks. And so that helped me. But I think as a PM, you can still do that, even if those functions don't report to you, is take that really wide view of what success for your product is and not have the blinders on its product or tech. It's anything. It's anything that influences the success and your, your, your customer success or anything else. And it just means you know, you don't own marketing or you don't own this other function, but you own it until you find somebody else to own it. And so that's not necessarily thinking big in terms of scale or whatever, but in terms of how you think about your role as a PM and what your ownership responsibility is. And so I think just the more that you, you know, you don't want to get over your skis as a PM, and then you're trying to like change your CFO's mind about something necessarily, but the more you grow, that you have to increasingly do that and find the constraints or barriers to your success or your product success and knock them down no matter what they are.

Yeah, it makes me think about just the advice of like, think like an owner. Think beyond just like your one little bubble. Think about the broader business outside of the one little product you might be working on. So that's great advice. This episode is brought to you by Assembly AI. If you're looking to build the powerful AI-powered features in your audio or video products than you need to know about Assembly AI. Assembly AI is the API platform for state-of-the-art AI models that thousands of product-led growth companies like Spotify, Loom, and Calm are using to infuse AI into their products. With simple APIs, developers and PMs can get access to powerful AI models for transcription, summarization, and dozens of other tasks that are fast, secure, and production-ready. All of their models are researched and trained in-house and continuously updated by their team of AI experts, which for PM makes it easy to build and ship new AI-powered features. Product teams at startups and enterprises are using Assembly AI to automatically transcribe and summarize phone calls and virtual meetings, detect topics in podcasts, pinpoint when sensitive content is spoken, redact PII from audio videos, and way more. Visit assemblyai.com to try Assembly AI's API for free and start testing their models in their no code playground. That's assemblyai.com Before we move on to the working backwards piece, which I'm excited to get into, is there anything else you want to share on this thread?

I might just talk about earned trust because this is one that I don't think I really, I didn't put in there initially. and I honestly don't think that I recognize the importance of it early on in my career or even in the middle of my career. And it's been in the last couple of years that I really understood the importance of it. You know, my wife Sarah is a product manager in AWS. And so I've kind of, as I've mentored her a little bit in her career and I've seen how this is really a superpower for her, it really made me reflect. I'm like, what are the things I could have done better in different roles to earn trust more? and it's not just the basic things, like to be honest and tell two different people the same thing versus different things. I think it's trying to really understand, work backwards from that person and what are their goals and what are their organization's goals and honestly spend the time and the energy to try to get to alignment in the same place and be willing not just bullheaded, which I might have been earlier in my career, maybe still to many people, but charging forth what do I think is right, but taking some more time to try to forge an alliance with someone because if you do that, you're ultimately going to be more successful. So that was just one that I was probably slow to recognize the importance of, and I'm trying to catch up now.

Is there a story that comes to mind where you look back and I should have earned trust there or I broke some trust here that you'd be willing to share?

You know, when I was working with you and the team at Airbnb, I think this is one where Jobot brought me on to help sort of build out the customer support technology platform, maybe more how Amazon would do it, like to maintain a high level of quality, but to become like more efficient as well and to reduce the cost so that Airbnb and me wouldn't have to scale customer support to the same degree the business was scaling. And so, you know, coming kind of trying to build a new team and develop and I was pretty heads down doing it the way I thought it should be done and like working with the team there in terms of like, let's get strong analytics framework. Anyway, let's measure all these things and really understand what's going on at the data level. And then let's use the same prioritization muscles that had kind of made me successful at Amazon to prioritize things that were best, work backwards. And I think that what I didn't do as much as I should have is obviously really partnering with the customer support and leadership team as well. Is that was something where, I think in some ways it felt like we were in alignment and getting on stage together and stuff, but it turned out I maybe hadn't spent as much time and effort in that as I thought to get that to build that true support there such that that leader would rally the organization around it as well. And we'd be marching in the same beat. And so that was something that I would reflect. Now, I think the team did amazing things and, you know, Shirley really carrying the torch there and the entire team and so accomplished a lot. But that was a learning about like, going back, I probably would have spent more time and really tried to do even more on that.

Thanks for sharing that. I never knew that story. And it sounds like the takeaway there is maybe don't take for granted the leadership team, the team that'll actually be using the product. Is that kind of roughly the way to think about it?

Well, I would say that if you have a certain approach, now you may believe it's the right one, and it may be the right one, but if you don't build the support and the relationships, you know, that they're going to help carry that out and execute on that strategy, it may not It may not get executed as well as you think it should be. And so that's an important part of success. It's a risk that you have to kind of mitigate and trying to earn trust and to do it that way as a way to mitigate that risk that the right product and the right direction and the right strategy may not land if you don't have that support that you need. And so that I think was my learning.

What better way to learn a lesson than get some wrong and then you never forget it? Again, you could call it getting wrong.

Just think of something I could have done better. And just that same continuous improvement mindset. It's to everything, every role, every experience, every project, every communication. And if you build that muscle to try to do it better the next time, and also just try to be a little self-aware about what could have gone better, then I think it's a really good muscle to build.

So this is a good segue to the second area of where our chat is going to go, which is Amazon and things you've learned about just the working backwards process. How many years did you say you worked at Amazon total?

12 years.

12 years. It feels like everyone that worked at Amazon is like 10 years or more. It's these like large numbers. So they must be doing something right. And I don't know, what do you think that is actually? Why do people stay there so long? It's amazing.

What's interesting about Amazon and it's changed over time is that I think you know pretty quickly whether you're a fit for it or not. You know, and it can be kind of a crucible and, you know, a little Spartan. and it just clicked with me though, because I'm kind of a structured thinker and right brain. And so this idea that like, hey, I could have this business and then figure out one metric or fitness function that determines success. And then my job is to make that number go up and to the right. That kind of fit with me. And then, you know, I rewired my brain probably over the first 10 years around this concept. And I just, I just felt like I was learning. I was not only working with smart people that were driven, which was true at Microsoft as well, but there was kind of this DNA in the organization and this wiring that I thought was really effective and it just kind of clicked with me. And so I kind of molded myself to the environment and at every step of the way I felt like I was learning and growing and I was, you know, one of the benefits for me is you get a chance to learn from so many other people in these different settings. You get a chance to read documents that make you learn more so than probably a slide deck. You get a chance to be in weekly business reviews with really smart people and learn from that, not just learn from your own experience, but from everyone else in that room. So I was just a sponge and so much learning happening that I think propelled my career. And so that was why, especially the first 10 years, that it was so fantastic of just like growing and feeling yourself kind of build these new muscles and develop these new tools. And I loved it. So that was why why I stayed so long. And obviously Airbnb then, it was the time to try something new, which was a great experience. And, you know, kind of a test. You know, I was in Seattle and the company was in San Francisco and spending three days on a road each week was a good learning and ultimately, you know, reason to come back and be Seattle based. But then I chose Amazon again because it was still a great place and then I thought I could continue to learn.

So awesome. I was going to mention they drew you back in. So, yeah, that's pretty rare. What did you learn from folks like Jeff Bezos and Jeff Wilke about Building product, leadership, company building, what's kind of stuck with you working with folks like that?

Obviously two very different people, but like complemented themselves so well. You know, I didn't have, you know, hundreds of meetings with Jeff Bezos while I was there, but I did have a chance, especially in kind of the development of Amazon Smile. And then early when I started the social team to have some, some of those meetings where I wrote the doc and it was Jeff and, you know, 10 other people reviewing the, the process of kind of doing even before hitting on Amazon smile, it was really kind of a innovation process, I guess you could call it, where we had a goal in mind to increase customers kind of loyalty to Amazon, their direct traffic loyalty, not in the way Prime did, which is a paid program, but to try to come up with another program or way in which customers might start their shopping on Amazon instead of elsewhere. And so I kind of, I was running the gifting business. I just moved over to the traffic org to try to come up with a new program with no team or anything. And then I would meet with Jeff and Bezos and Wilke and others every couple months and just kind of, I would profile a couple different options and use the working backwards process and we'd review some facts. And so there was a bunch of kind of learnings throughout that process. One, I found Jeff to be super encouraging. And each time we leave one of those meetings, we maybe didn't find the thing in that meeting. We talk about it and brainstorm a little bit, but he would always leave and be encouraging. and, you know, with a quote, you know, one time he was like, you know, remember, this process doesn't have to be efficient because the prerequisite for efficiency is knowing where you're going. And then he'd leave the room and whatever. So I just, I found, like, the, the rhetoric around Jeff or blowing up or whatever, I didn't find any of that. And I found him to be super encouraging. And he found all these times to sort of help train me in the working backwards process. Like, there was a time. when I came with a press release for a concept and it didn't have a problem paragraph, I'd skip that. And, you know, we reviewed it and so forth, and he was like, you know what? Maybe if you don't have a problem paragraph, there's not really a problem. And so it was kind of a little lesson to me, like, yeah, maybe that is why I did it. I wasn't really working backwards. I kind of had the solution in mind. And so I'd skipped over that part. So that was one just very specific learning about the process from Jeff. So Jeff Wilke, I probably learned more from Wilke just because I had more exposure over my time there. you know, at one point he was my skip level. And I have such tremendous respect for, for Wilkie or Jaw, as he was called internally, because he was sort of the consummate like operator, this muscle that I think you learn working at Amazon about being an operator, whether you're, you're not in operations, but any part of the business that I think came from him. And I think it was due to him that Amazon developed that muscle. And I think it's one way that separates some Amazon PMs for people who haven't worked there and that , and that continuous improvement mindset that's like so important. And, you know, one of the forums that was a great learning was sort of the WBR weekly business review or later called consumer business review. So this was a forum where Jeff would lead the meeting. It would be a series of metrics for different parts of the business, everywhere from fulfillment to customer support to traffic to category teams to programs. And I would present on Amazon smile there. and the way he would run that meeting and kind of enable you to get through a metrics meeting for the entire North American retail business in one hour. And it, the way he ran that meeting would lead all those leaders to build these muscles because you wanted to be prepared to speak to the variances or trends in your business and a key metric and know your business and know what you were doing based on that thing. And so just this hour a week of probing and asking questions and everyone, there might be a hundred people in that room prepared to answer questions about your business. And it had this cascading effect that not only was I or other leaders there, you know, on the spot having to answer a question and being prepared, but then I would do the same thing with my team, et cetera. So I was trying to build those muscles in my team such that they could bring their insights and understanding and actions on things in this cascading effect. So that was a mechanism, which is another really big thing at Amazon that led to all these like amazing behaviors. And I think a lot of those mechanisms, you know, came from Jeff Wilke or he created an environment where they would be developed throughout the organization and then propagated. And so that was one thing, just that operational mindset and rigor that is, you know, being a product leader is not just about building new things, it's about, you know, how well you run what you've already built. And if you're really paying attention to the product that you operate, it will give you ideas for things you could do to double down on something that's happening well or to prevent something bad happening. And I think that's been a very key reason for Amazon's scale. Another thing I really respect about Jeff Wilke, and I think Doug Harrington has some of this as well, is that the notion of kind of a little bit of tough love, you know, and like, I think that's important. And that neither were, you know, assholes, but sometimes, and especially, you know, Wilke, like, you need to get that look, kind of like your dad might, you know, look over his glasses at you and be like, hey, and so I think that was kind of the vibe that you would get. It was professional, it was respectful, but sometimes everyone needs a little kick in the ass. And I think that was something. But it was, you know, it almost builds more respect from him and just incredible leaderly behavior, which I really respect. And I try to model and I try to try to do the same because I respected it so much. And then the last, I guess the last attribute of of Wilkie, which I really saw was, was like teaching. And it wasn't just saying, this is the right thing, or this is the, this is the what, what my decision is in a meeting, but teaching the why and why the pattern, the mental model that informs him to think this is the right thing. And so I think he was just great at, at kind of teaching, taking a moment. It might just take 10 seconds in a meeting to teach. And that's something that I've forgotten in different parts of my career, especially as you get more to experienced and you, you know the right decision to do and you know what you want, see whatever that that may be the right thing. But I think you'll have a lot more lasting effect if you could kind of abstract it to a degree and teach the lesson, because then that person will hopefully learn the lesson and can apply it to a bunch of future situations and also understand the why more. And it helps them kind of sometimes disagree and commit more so than just being kind of given prescriptive advice.

Sounds like it must have been an incredible experience learning from these two. Thanks for sharing all that. I want to get to the working backwards stuff. I feel like we've talked about this a lot. We've talked about this on other podcasts with other guests. I feel like people understand the general idea. Yeah, Amazon works backwards. They write a PR. Maybe there's a six pager thing they do, but I feel like there's not a lot of, here's how you actually do this thing. And so just to spend a little time on this, when you see teams trying to work backwards and be like, let's work backwards, we're going to be like Amazon, what do you find they do wrong when they're actually trying to implement this idea of working backwards? What's the most common mistake do you find?

Yeah, well, working backwards is all about the problem and kind of starting there and obsessing about the problem and being guided by it to then go into the solution. So when teams that do it wrong is they don't do that. They don't work backwards. They start, they have something they want to build. We've got these these things look similar, these two technologies or whatever, we could combine them and then do this. And if you say we could and it's not grounded in a customer or customer's problem, you're not working backwards. And then you may use sort of quote unquote the working backwards process, but you already have the solution. And so you're adding the problem after the solution. You're kind of retrofitting the problem, retrofitting the customer. And so that I think is the number one thing is that it's they don't get the importance of truly starting with the problem that you're trying to solve and being faithful to that working backwards from the problem. When I first started Amazon and community, we had sort of this, this business of automated merchandising using community content. And that was kind of the core thing we were doing is to grow that. But there was this Jeff idea that the team was super excited about because I think in some meeting he'd kind of sketched it out or whatever. and so that there was already all this momentum to like build this thing. It was actually a Jeff, a Jeff project, but I should have known at the time, in hindsight, I do, because the name they had for this project was ASIN to ASIN linking. And, you know, ASIN was kind of the identifier for a product on Amazon. And so it was kind of this not working backwards idea ultimately of like, if you could link to products by a subjective attributes, and then you could build a feature around it that allowed customers to vote on these things, and then it would be kind of a so it was not in spirit, it really wasn't working backwards, but the team was all excited. And so we, we kind of eventually wrote the press release and we kind of did it. And you know what? It turned out it wasn't successful. We ended up shutting it down later. And so I learned a lot. This was like the first year or two at Amazon about using the working backwards process, but not really working backwards. And so that's literally, if I'm reviewing a working backwards press release or FAQ or even talking with someone about a new initiative, my brain is kind of wired down to not be able to process any information until I focus on the problem and the customer. And then once we start talking about that, then I can engage and kind of literally work backwards to say, okay, how do we solve that problem? And what's the most elegant way to solve it? Or if there's three problems, what's number one or two or three? So it's probably a gap in me that I can't like process information without working backwards from the problem. But I find it to be helpful when people do that.

So when people talk about working backwards, the way you're describing it is interesting where it's focused on start with the problem, which I think generally product teams try to do. Like their one-pagers, their PRDs often have like, here's the problem we're solving, here's why it's a problem, here's how we think about it. Is that the core of working backwards? I always imagine it was like the launch release and the PR thing and maybe the FAQ. Do you actually do working backwards at like Uber and Airbnb? Do you actually do that for every project yourself at this point?

There's two parts of it. One, there's the concept of working backwards from what you're trying to accomplish. And I still absolutely do that with my teams as well. What are we trying to accomplish for the business or accomplish for a customer? And let's start there. And if they have a problem that is interfering with their ability to be profitable, for their ability, you know, if it's a business customer or it's a customer trying to accomplish a goal, starting with that problem. That's different from the working backwards mechanism, which is the press release and the FAQ, which was the mechanism that Amazon used to enforce working backwards, which I think is effective. And I've tried to sort of teach that and write some posts about with templates and things like that, because it's a great way to start of like the press release has a paragraph about the problem. That's what you write. And then you write the solution paragraph and then the customer quote. and then the FAC, which is like, is there a legitimate plan to succeed? So if you don't have that muscle to work backwards already in your team, it's a great thing to try, but that's not the only mechanism that can do it. And eventually, if you do it enough and you build that muscle to work backwards, you can do it in any number of formats, whether it's something in a PRD or some other way. But the key is that you don't think what we could build. you think about the problem and then the solution that solves that problem.

Got it. Okay, so the press release is not core to it. It's like a trick to get you to think about the problem you're solving. It's not like how you plant an announcement. Yeah, interesting. I never thought about it that way. So when you're doing this process at other places outside Amazon, say you're a product leader that's trying to like, I want to do this. I want to improve the way we think about product. What is it that you suggest they do specifically? Is it writeouts? Here's the problem we're solving. Is there more to it? What would you suggest there?

If it's a blank slate, truly, you could certainly use the working backwards process like Amazon does with the internal press release and then the FAQ and so forth. So that's fine, but a lot of companies have a different way they go about it. Some companies are very much, it's slide culture and presentations and so forth. And so as a product leader, you can think about what you do with your team and what you do upwards or across. And so you may have a latitude to use any process with your team. And I've done that at some companies where using documents and if they're supportive of the team and they recognize the value of that, like, oh, actually this is good and this is a great way to write things down on paper and to have better information content and richer discussion that oftentimes I think people will find that versus a slide with a couple bullets. is not great, then you can kind of build that muscle. And I found it's a great way to kind of teach and use those to dive deeper into the product. But depending on the organization you're at, that may not wash to sort of train your senior leadership to use the process you want to use. And so then it might be a matter of finding the opportunities to try something and saying, you know, are you open to doing something this way, a review of a doc, instead of a review of a whatever. So that's, it's a little separate than just working backwards, but I think you just have to acknowledge the environment you're in. And also like, unless the organization has a specific format to do this, if it does, you probably just need to use it. Different leaders process information different ways. You may find one format's effective with your leader, but another one to sort of educate a broader organization, but it's very kind of company specific. So despite what I might want to do, I just got to recognize that I have more leverage down with my team versus up or across. Right.

Is there a template that you use consistently? Is that something that you've published of just like how to frame the problem, how to frame all these other elements? I have shared posts on I know.

For sure LinkedIn and I probably should put it on the newsletter, on my newsletter, that sort of a working backwards template and some posts about how to do the process or, you know, tips on, on how the Amazon does the process. And so I'll make sure to put those up on my newsletter as well. And the template's free.

Obviously anyone can just copy it and grab it. Awesome. We'll link to that in the show notes. Definitely send that to me after we wrap this thing. And I was gonna ask, does Amazon work backwards on every product they work on slash do you suggest working backwards in every feature and product?

I think there's some scale below which it doesn't probably make sense to do this process cuz there's a little bit of overhead to it. But I think if it's a significant, if it's a new product, absolutely. And I think there, I'm sure there's some at Amazon that don't use the process, but in general that was the way and often enforced that you need to, you know, you need a working backwards review. Ideally that would happen kind of at the outset, but sometimes it would be added later. And yeah, I think it's a great thing whether you use the mechanism. Again, it's a great template to start with and use if you have the flexibility to, but I think It's also possible just to have the spirit and to try to be true to the spirit of working backwards from what you're trying to do for customers and what problem. That's the most important thing. The template is just a mechanism to help ensure that happens. Got it.

You mentioned this review. What is that? Working backwards review? Well, that would just be a meeting.

With leadership or other folks to kind of review the concept, review the press release, review the FAQ, and ask questions. And in some cases, that would be the gate to like approving it. That was the case with me and Bezos before we went off and built the team and launched Amazon Smile is I would do these reviews about different concepts and that was the one that we greenlit. I mean, that's often the case. It's also just a great way to educate other people about what you're trying to accomplish, ground them in the customer problem and solution and the FAQ is a whole other concept. It's about the legitimate plan to succeed. One other, you know, thing that I use. I got a chance to have lunch with, with Jeff Bezos, who's probably back in 2008 or something like this. And I sort of asked him, like, what's your criteria for sort of investing in something new? And he said, well, it's like three things. One, is it a big idea? And then second, is it something we should be doing? So if maybe you have an idea, if you have this new way to extract oil from shale, is it a big idea? Yeah, probably could be a big idea. Is it something Amazon should be doing? Probably not. And the third test is there a legitimate plan to succeed? And you gotta have all three of those things. And I think the fact part of the working backwards process is that early stage legitimate test of whether this thing has a plan. Because you could have a this internal press release or big idea or big idea for solution, but the fact basically says, okay, I've thought through the internal components or the finances or the key technical hurdles or whatever. And so that's one that's not written about as much how to do the FAC, but I think it's another way to kind of build trust that you've been thoughtful enough, given the stage of the product, to deserve the resources or.

Deserve to kind of move forward with it. That's awesome. I feel like most PMs listening to this are going to be like, I always start with the problem. I'm always problem focused, so I'm working backwards. So I'm good. Are there signs of just like, no, you're not. You think you are, but you're probably not doing this well. Is there like a symptom of like, you don't actually know you're not actually doing this correctly.

The most common thing that I see that kind of tips me off is that when they talk about something, there's different pieces in the pantry, right? And they're like, we have these ingredients, we could put them together. We could add these two things together and make a meal out of it, right? And so it might be a technology, it might be a service, it might be two different things or the building blocks are there and what's enabled if you add these two building blocks together is something, but that's not really working backwards. It may be true that there's some leverage or some benefit from the company having these technologies or assets, but that to me is often the first step that these two things look similar, we combine them and it's all goodness and this new thing. So, if you start talking about those things or the technology, I think that's the likely case that you're not really working backwards as opposed to the opposite is that there's a customer problem that feels compelling even before you know the solution. Like, yeah, that does feel compelling. And just like with every startup out there, probably a lot of the pitches are like, there's a big audience and a painful problem and it's kind of the painkiller versus the vitamin thing. and then we have a novel way to solve that. That's kind of working backwards, but the more often, especially in a big company, you'll have all these ideas because you have more ingredients in the pantry of ways you could combine them and try to feed it to someone, but may not be working backwards.

Awesome. We're reaching about an hour of chatting, and so I want to let you go. Before we get to our very exciting lightning round, is there anything else you want to share on anything we've chatted about.

Let's see. No, I mean, I think we covered a bunch of good grounds. It's been fun, but nothing, nothing particular.

Okay, great. Well, then we've reached our very exciting lightning round. We've got six questions here. They'll be pretty quick and easy. Whatever comes to mind, share, and we'll go through them relatively quickly. Sound good. All right, let's do it. Let's do it. What are two or three books that.

You'Ve most recommended to other people? I said Getting Real by 37 Signals. and it's specifically the chapter on epicenter design. I've shared that many, many times. You can link to it. That's definitely the most thing I've shared. For Fun, the Wool Trilogy by Hugh Howey. He's probably my favorite author and a great series. And then for learning, just a recent one that I thought would be super fascinating was Energy and Civilization by Vaclav Smil. So it might not be on the.

Bestseller list, but I thought it was interesting. What's another favorite podcast of yours other than this one possibly.

I think how I built this is really interesting just to kind of decompose how interesting businesses and products came about. And then just because of my work, EV News Daily is kind of a daily digest of what's going on in the electric vehicle space. So that's a very good use of my time, five minutes a day to get up to speed.

Very niche. I love it. What's a favorite movie or TV show you've recently seen?

Yellowstone, that's definitely my favorite. Can't wait for the next season. Montana is my happy place, although I'm probably the kind of person that they rail about in the show, so it's kind of ironic. And I think the movie, that was Everything Everywhere All at Once.

I love movies that are not predictable, and I thought that was just very creative. I'm shocked by how many people on Yellowstone die. That show is just murder left and right.

I was not expecting that on a ranch-oriented show. It's a harsh environment.

Quite harsh, turns out, especially if you mess with the Duttons. Next question, favorite interview question that you like to ask?

When I'm coming out of left field, I ask people like, At this stage in your career, what have you learned about yourself? How are you different from other people?

No one's prepared for that.

What do you look for in their answers? I don't know. I mean, there's not one specific thing and there's no right answer, which maybe makes it unfair, but just maybe a little self-reflection and maybe they will have understanding their strengths, and that might be a good bit of self-awareness about what makes them different, where they can harness that, and that makes them a better PM or engineer or something. And so that's kind of what I'm looking for, but there's no set answer. It's more just a throw them off balance.

Interesting. Favorite app right now?

It's probably not too interesting, but to be honest, YouTube, it's like the, you know, eighth wonder of the world. Just every day, I'm amazed if I want to learn about something new. A couple summers ago, I had some time off and so I basically taught myself how to do woodworking and built a kitchen and other stuff. And so it's just like it continues to be this resource and this jewel that helps me kind of grow and learn about anything.

I imagine some people are watching this on YouTube right now. All right. I just read a story about an Olympic javelin thrower who learned how to do this watching YouTube. was somewhere in, I think maybe Africa. He had no coaches around and he just watched this one other Javelin guy that just shared lessons on how to do this and became incredibly good.

It's insane. And I didn't, I mean, I'm old, so I didn't have this when I was growing up. Like, I remember going to the library and like sending away for a brochure in the back of a magazine and things like you, like learning was not so easy back then. The internet obviously was, was a huge resource and is. but then YouTube as well to see somebody do it. It's also interesting to see somebody live. So anyway, I'm a fan.

Final question, who else in the industry do you most respect as a thought leader, someone you look up to?

I'd say Gibson Biddle. I think that he is one just tremendous amount of product experience that I think is valuable. I respect the fact that he takes the time to share it. He doesn't have to, but he does. And he's also a great communicator and he invests in being, you can tell like You know, he measures cease out of his talks and things like this. Like he's invested over his career to be a great communicator. So I think he's a good, a good kind of role model for me and I think for others out there.

That guy is a force. I'm happy that we've had him on this podcast. I'm hoping that everyone eventually that people mentioned in this question we end up having on this podcast. So that's great to check. I also love Gibson. He's got a great newsletter. AskGibbs.substack.com, I think. Ian, thank you so much for being here. This was amazing. I really appreciate you sharing all this wisdom with us. Two final questions. Where can folks find you online if they want to reach out, learn more? And how can listeners be useful to you?

Yeah, I guess Twitter is a great place. Ian Macalister, I-A-N-M-C-A-L-L is my handle. And then, you know, I've started a newsletter. I'm not that frequent, to be honest. I have a lot of good intentions and a bunch of ideas. Ian.Macalister.substack.com and so that's something to kind of connect and feel free to subscribe and if hit me up on Twitter if you have ideas for posts or questions. And if I can answer in a tweet, I will. If not, I might put it on the queue of things to write about. And yeah, thanks for having me on Lenny. It's like I was, we were talking earlier about like writing or doing other things and like the value of that is just like making connections with people. And so that was what I was one, just to reconnect with you is awesome. And to whatever extent I get a chance to make new connections in the.

World, that's a good thing. Amazing. Yeah, and we originally connected over that piece that you wrote. So it all circles back 10 years later, maybe. Thanks, Ian.

All right. Thanks, Lenny.

Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com See you in the next episode.