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

Ian McAllister (00:00:00):
If you forget about everything else, forget about politics, forget about promotion, or having 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.

Lenny (00:00:22):
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.

Lenny (00:01:32):
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.

Lenny (00:02:24):
This episode is brought to you by Athletic Greens. I've been hearing about AG1 on basically every podcast that I listened to, like Tim Ferris and Lex 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 are 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.

Lenny (00:03:13):
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 and 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.

Lenny (00:03:55):
Ian, welcome to the podcast.

Ian McAllister (00:03:57):
Thanks for having me, Lenny. I've been looking forward to this.

Lenny (00:03:59):
Me too. I'm sure you hear this a lot, but when I was a new product manager, a very new 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 ... 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, virtually in person, and with you. So thank you again for doing this.

Ian McAllister (00:04:35):
Yeah. Man, it's awesome. I'm excited just to spend some time talking with you about product and we'll see what happens.

Lenny (00:04:42):
Did you expect the impact that this post had when you were writing it, when you were just putting this together, the impact that the post had in your career or just the PM industry?

Ian McAllister (00:04:51):
Definitely not. I used to lurk on Quora at the time and then I was just having fun reading things and answering some questions and I used to look for questions in the Goldilocks zone. They weren't too high level of abstract like how do you be a good problem, but they weren't too 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 as a way to structure my own thoughts, that was what was interesting and fun for me to do that. Not because I thought it'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 pretty fun.

Lenny (00:05:23):
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 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. 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?

Ian McAllister (00:05:45):
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 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 write more about people management and product management. And I think the value for me was so awesome just to 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 of thought were just 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 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 great connections and relationships from this.

Ian McAllister (00:06:39):
I remember interacting with you and getting to know Joebot 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. And 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.

Lenny (00:07:03):
You mentioned a little bit about your background and 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 ends up, wow, so many people find that valuable and it spreads. And so that's just a really simple way of thinking about if you're starting to write online, just summarize something that you've been thinking about that you want to just crystallize in your own head. There's this quote that's 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's a good example of this.

Ian McAllister (00:07:42):
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 there's two tests in writing well or communicating well. It's both those things. So I found it's pretty valuable in kind of sharpening your ax.

Lenny (00:08:15):
So these are the two things we're going to 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 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?

Ian McAllister (00:08:31):
Well, I can tell you what I have done. I'll let others decide what's wonderful or not. So after doing 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 I 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 at a startup and then kind of a midsize company and then moved to Microsoft as a program manager, 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 leadership toolbox. So few different things I did over 12 years, a few years in retail and conversion.

Ian McAllister (00:09:22):
I then moved in traffic and direct traffic loyalty when I created Amazon Smile. The role in Alexa. I led Alexa International, so 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 joined Uber where I'm 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. And that's it.

Lenny (00:10:03):
Amazing. I just realized this one thread through your career is autonomy and AI a little bit, right? With Alexa and then with Uber, with these autonomous cars stuff you're working on now. Is that something realized or is that an accident?

Ian McAllister (00:10:18):
Well, I mean I guess you could connect those things. Obviously both are machine learning, AI. The way I think about it is that I've done a whole bunch of different lifetimes, especially around eCommerce, and so it allows me to cover the gamut. Plus, I guess I forgot to mention the time at Airbnb working with Joebot and you and Vlad and Dan and Shirley and there was focused on building out the customer support technology platform. So that's another part of the eCommerce platform. Covers the gamut.

Lenny (00:10:45):
I forgot to bring that up too. I'm glad you touched on that.

Ian McAllister (00:10:48):
I don't know how I missed that. I guess I skipped past that with the Amazon stuff.

Lenny (00:10:50):
The most transformative time getting to work together.

Ian McAllister (00:10:53):
That was awesome. That was awesome. I learned a lot from you too during that time.

Lenny (00:10:56):
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 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 maybe just run through the attributes that you've found over the years or here's the things that a top 1% PM needs to get great at. Maybe just run through them and then we'll talk through them in a little more detail.

Ian McAllister (00:11:28):
Yeah, I was going to pull up my post here so I could actually refer to it. Do you want me to go through all of them or just pick out a couple to touch on?

Lenny (00:11:33):
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.

Ian McAllister (00:11:40):
All right, sounds good. Well, the way I listed it at the time, think big. Always want to hunt for bigger impact. Communicate, I think we'll probably touch on that a little bit. It's 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. Simplifying is a great way to do that. Prioritize. That's 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. 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 trade offs, not just product and customer trade offs, that will help you simplify and get more yield out of your resources.

Ian McAllister (00:12:40):
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 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, I guess 10 years ago, and then I refreshed the post recently in my newsletter. And I added a couple new ones honestly, because as I reflected back, there was a few 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.

Ian McAllister (00:13:29):
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 going to 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 rally yourself, 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.

Lenny (00:14:33):
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 a wild, crazy, impossible job to have everything nailed down. And at the end of this post even mention you've never met a 1% PM that does all these things. And I think that's important. No one's going to 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, maybe 10, 12, what are the top three that you think new PMs should get most good at and focus on?

Ian McAllister (00:15:06):
Probably communicate, 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. And I remember years ago I was at Microsoft, my first effectively product manager role and my product unit manager, Thomas, came by the office and I think he asked me, "When is this going to ship?" And I was like, "Well, this thing is taking a little bit longer here and this other thing and yada yada." And I 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 ... Ultimately he's waiting for a date.

Ian McAllister (00:15:53):
And so I just reflected on that and that was, as I remember, 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 was our, I think at the time, SVP for Worldwide Discovery. And I think she was Amazon's first TPM. And she was tough but super smart. And so that was also an early experience to learn from her. And sometimes you get some feedback when you didn't really answer the question. And my first boss, Russell and I organized and started to gather this thing called the Book of Kim. And so we would gather these best practices that we learned from her elsewhere. Avoid weasel words, answer first and then explain, own your problems. And started building this.

Ian McAllister (00:16:36):
And then I extended that over time and added a bunch more and wrote a post called the Operators Manual. I 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 answering a when question with a date, knowing how to use numbers to answer questions and honestly just learning from feedback and grade yourself after you get feedback on a doc 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.

Ian McAllister (00:17:24):
So that was communicate. I guess prioritize as the next one. And so I think this is the number one key tool of a product manager is prioritization. Because so many things come from being good at prioritizing. And it's not just 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 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. Like what are you going to choose to spend your time on? Which things are you going to really go all out to make great and which things are you going to 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.

Ian McAllister (00:18:18):
My early, if you could call it success at Amazon, I think was completely dependent. It wasn't because I worked smarter or I was smarter, I worked longer hours or I was more technical than other people. I think it was just because I was one, super hungry for impact. And if there was a number or a metric that measured success at the business I was running, I wanted that to go up and to the right. Not to hit a goal, but just to go as far and as fast up to the right as possible. And if anything, it was just working with a 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.

Ian McAllister (00:19:01):
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'd 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.

Ian McAllister (00:19:23):
I think execute is the third one, which is no surprise that every PM has to execute. And I think 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 also execution's a big function of the team you're working with. So it's your designers and your data science folks, and especially your engineers.

Ian McAllister (00:19:47):
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, 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. The drive that goes into execution, product managers are the mode of 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, 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 forward. But 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.

Lenny (00:20:32):
Awesome. And what's interesting about these three is if you look at the rest of the list, 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 a new PM. 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 learn as much as you can, but it's almost bit easier to think about the things you don't need to stress about when you're starting out.

Ian McAllister (00:21:02):
Yeah, I think that makes sense. If there's a core or think about in 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.

Lenny (00:21:14):
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 one tactical thing you could suggest that a PM listening to this can do to get better at one of these things? Is there a trick you've learned of, wow, this is one way you could level up communicating, executing, prioritizing or not?

Ian McAllister (00:21:37):
The closest thing to a checklist, the post I mentioned, the Operator's Manual, that was the closest thing to, 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, 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 was my attempt to try to encode, 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.

Lenny (00:22:39):
Awesome. We'll talk about all that.

Ian McAllister (00:22:40):
And then I think communication, the simple tip was just 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.

Lenny (00:22:58):
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?"

Ian McAllister (00:23:04):
Yeah, absolutely. Absolutely.

Lenny (00:23:06):
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?

Ian McAllister (00:23:17):
Gosh, it's still communicate, to be honest. I think that's the one at every level of product, 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 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 tool and that's often where I'd start when my PMs were sharing an idea is I'd 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.

Ian McAllister (00:24:04):
Earn 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 I think it's truly 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 mantra to think about as a FM. Am I meeting the expectations that I set? And not just doing good things, but calling your shots, forecasting, setting a goal, and then hitting it.

Ian McAllister (00:24:54):
And if you do that repeatedly, you're going to be in pretty good shape. And there's so many practices as a product manager or product leader that build trust. You tell the truth without fail. And you launch when you say you'd launch and you launch what you said you'd launch and you own your mistakes. And then the other practices just lose trust. If you lie or if you're evasive, if you don't ship what you said you're going to 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 currency, that's going to correlate well as a PM, as a GPM or director of product in any level, that's the thing that you want to build.

Lenny (00:25:34):
So thinking big, building trust. Was there a third?

Ian McAllister (00:25:37):
I think maybe the last one, which is certainly relevant for a PM but is really true as well, is driven by impact. And if you forget about everything else, forget about politics, forget about promotion or having 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 in 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 never talked 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.

Lenny (00:26:38):
Would you say that driving impact is more important for a new PM or senior PM? It feels like impact is the soup within which all PMs swim and that's 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 on your team you're less expecting them to think about impact and focus on impact?

Ian McAllister (00:27:01):
Well, I mean 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 ... You have a project or a feature to ship or something like that and you're often not necessarily given a lot of latitude to build your own roadmap. But you're asked to ship this. So 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 way to think about the flywheel of product leadership.

Lenny (00:28:11):
It feels like a lot of times you get lucky as a new PM. You work on a project that ends up having a lot of impact that you didn't necessarily drive. You just happen to work on something that, wow, this was a huge deal and that feels like an important thing to optimize for a little in your early career is work on something that's likely to have a lot of impact even if you're not responsible for setting the strategy and prioritizing.

Ian McAllister (00:28:29):
Well, I think that's true if you have a choice in where you work in product. If you have a choice to work on something that's part of offense, something that drives the business. And it's true that executives wake up if something drives dollars or customers or offense things and it just maybe shouldn't be this way, but a little less interested in things that maybe 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. And I think most of us don't get to choose that especially early in our career. It either works out in your favor and which is great and that was the case for me, especially at Amazon, some of the leaders I worked 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.

Lenny (00:29:30):
To close the loop on this piece 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. I'll 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.

Ian McAllister (00:29:58):
That was 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 most people operate within a box. There's a box of there's product management and these are the things that product managers do. And you basically build a roadmap and you prioritize features and you work with eng. And so that might be the typical kind of product scope and 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 is across disciplines. And I was lucky enough that I had engineering teams and marketers and 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.

Ian McAllister (00:30:58):
It's anything. It's anything that influences the success and your customers' success or anything else. And it just means, 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 don't want to get over your skis as a PM and then you're trying to 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.

Lenny (00:31:43):
Yeah. It makes me think about just the advice of think like an owner, think beyond just 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.

Lenny (00:31:55):
This episode is brought to you by Assembly AI. If you're looking to build powerful AI powered features in your audio or video products, then 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 CallRail 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 a 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 and 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.

Lenny (00:33:08):
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?

Ian McAllister (00:33:15):
I might just talk about earn trust because this is one that I didn't put in there initially and I honestly don't think that I recognized 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 years that I really understood the importance of it. My wife Sarah is a product manager in AWS and so 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 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.

Ian McAllister (00:34:09):
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's 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.

Lenny (00:34:30):
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?

Ian McAllister (00:34:39):
When I was working with you and the team at Airbnb, I think this is one where Joebot brought me on to help build out the customer support technology platform maybe more how Amazon would do it. To maintain a high level of quality but to become more efficient as well and to reduce the cost so that Airbnb wouldn't have to scale customer support this to the same degree the business was scaling. And so 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 working with the team there in terms of let's get a strong analytics framework. 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 made me successful at Amazon to prioritize things that were best worked backwards.

Ian McAllister (00:35:26):
And I think that what I didn't do as much as I should have is obviously really partnering with the customer support leadership team as well. 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 on that as I thought 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 Shirley really carrying the torch there in the entire team and so accomplished a lot. But that was a learning about ... Going back, I probably would've spent more time and really tried to do even more on that.

Lenny (00:36:12):
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 a roughly way to think about it?

Ian McAllister (00:36:23):
Well I would say that if you have a certain approach you may be believe it's the right one and it may be the right one, but if you don't build the support and the relationships that they're going to help carry that out and execute on that strategy, 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 mitigate. And trying to earn trust and to do it that way is a way to mitigate that risk that the right product and the right direction and the right strategy, it may not land if you don't have that support that you need. And so that I think was my learning.

Lenny (00:37:00):
What better way to learn a lesson than get some wrong and then you never forget it again.

Ian McAllister (00:37:06):
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 the try to be a little self aware about what could have gone better, then I think it's a really good muscle to build.

Lenny (00:37:27):
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?

Ian McAllister (00:37:38):
12 years.

Lenny (00:37:39):
12 years. It feels like everyone that worked at Amazon is 10 years or more. It's these 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.

Ian McAllister (00:37:52):
What's interesting about Amazon, and it's changed over time, is that I think pretty quickly whether you're a fit for it or not. And it can be kind of a crucible and 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 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 I rewired my brain probably over the first 10 years around this concept and 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.

Ian McAllister (00:38:44):
And so I molded myself to the environment and at every step of the way I felt like I was learning and growing and one of the benefits for me is you get a chance to learn from so many other people in these different settings. You get the 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 growing and feeling yourself build these new muscles and develop these new tools and I loved it. So that was why I stayed so long and obviously Airbnb then, it was the time to try something new, which was a great experience and kind of a test. 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 a reason to come back and be Seattle based. But then I chose Amazon again because it was still a great place and I thought I could continue to learn.

Lenny (00:39:52):
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 stuck with you working with folks like?

Ian McAllister (00:40:04):
I would say two very different people but complimented themselves so well. I didn't have hundreds of meetings with Jeff Bezos while I was there, but I did have a chance, especially in the development of Amazon Smile and then early when I started the social team to have some of those meetings where I wrote the doc and it was Jeff and 10 other people reviewing. The process 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' 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 was running the gifting business. I moved over to the traffic org to try to come up with a new program with no team or anything.

Ian McAllister (00:40:58):
And then I would meet with Jeff Bezos and Wilke and others every couple months and 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 learnings throughout that process. One, I found Jeff to be super encouraging. And each time we'd leave one of those meetings, we maybe didn't find the thing in that meeting. We'd talk about it and brainstorm a little bit, but he would always leave and be encouraging and with a quote. One time he was like, "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 found 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 help train me in the working backwards process.

Ian McAllister (00:41:52):
There was a time when I came with a press release for a concept and it didn't have a problem paragraph. I'd skipped that. And he 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. At one point he was my skip level. And I have such tremendous respect for Wilke or Jaw as he was called internally because he was sort of the consummate operator.

Ian McAllister (00:42:34):
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 from people who haven't worked there in that environment and that continuous improvement mindset. That's so important. And one of the forums that was a great learning was the WBR or 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 enable you to get through a metrics meeting for the entire North American retail business in one hour.

Ian McAllister (00:43:27):
And 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 in 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 the leaders there on the spot having to answer a question and being prepared, but then I would do the same thing with my team, et cetera. And 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 amazing behaviors.

Ian McAllister (00:44:17):
And I think a lot of those mechanisms 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 being a product leader is not just about building new things, it's about 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 the notion of a little bit of tough love. And I think that's important and that neither were assholes, but sometimes, and especially Wilke, you need to get that look kind of like your dad might look over his glasses at you and be like, "Hey."

Ian McAllister (00:45:15):
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 almost builds more respect from him and just incredible leaderly behavior, which I really respect and I try to model and I try to do the same because I respected it so much. And then I guess the last attribute of Wilke, which I really saw was teaching. And it wasn't just saying this is the right thing or this is what my decision is in a meeting, but teaching the why and the pattern, the mental model that informs him to think this is the right thing. And so I think he was just great at teaching, taking a moment. It might just take 10 seconds in a meeting to teach.

Ian McAllister (00:46:01):
And that's something that I've forgotten at different parts of my career, especially as you get more experienced and you know the right decision to do and you know what you want, whatever, that may be the right thing, but I think you'll have a lot more lasting effect if you could 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 sometimes disagree and commit more so than just being given prescriptive advice.

Lenny (00:46:33):
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 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?

Ian McAllister (00:47:11):
Well, working backwards is all about the problem and 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 have something they want to build. 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 "the working backwards process", but you already have the solution. And so you're adding the problem after the solution. You're retrofitting the problem, retrofitting the customer. And so that I think is the number one thing is that 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.

Ian McAllister (00:48:03):
When I first started at Amazon and community, we had this business of automated merchandising using community content, and that was the core thing we were doing is to grow that. But there was this Jeff idea that a 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 build this thing that was actually 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 ASIN was the identifier for a product on Amazon. And so it was kind of this not working backwards idea ultimately of if you could link to products by a subjected 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 ...

Ian McAllister (00:48:50):
So in spirit, it really wasn't working backwards. But the team was all excited and so we eventually wrote the press release and we did it. And it turned out, it wasn't successful. We ended up shutting it down later. And so I learned a lot, this was 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 fact, or even talking with someone about a new initiative, my brain is wired now 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 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 process information without working backwards from the problem, but I find it to be helpful when people do that.

Lenny (00:49:47):
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. Their one pagers their PRDs often have, here's the problem we're solving, here's why it's a problem, here's how we think about ... Is that the core of working backwards? I always imagined it was the launch release and the PR thing and maybe the FAQ. Working backwards at Uber and other and Airbnb, do you actually do that for every project yourself at this point?

Ian McAllister (00:50:17):
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, 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 teach that and write some posts about with templates and things like that because it's a great way to start of the press release has a paragraph about the problem. That's what you write.

Ian McAllister (00:51:00):
And then you write the solution paragraph and then the customer quote. And then the fact which is is there a legitimate plan to succeed? So if you don't have that muscle to work backwards already and 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.

Lenny (00:51:35):
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 how you plant announce it.

Ian McAllister (00:51:42):
Yeah.

Lenny (00:51:43):
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 ... I want to improve the way we think about product. What is it that you suggest they do specifically? Is it write out, here's the problem we're solving? Is there more to it? What would you suggest there?

Ian McAllister (00:52:02):
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 fact 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 could think about what you do with your team and what you do upwards or across. And so you may have the 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 build that muscle.

Ian McAllister (00:52:54):
And I've found it's a great way to teach and use those to dive deeper into product. But depending on the organization you're at, that may not wash to 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, "Are you open to doing something this way?" A review of a doc instead of a review of a whatever. So that's a little separate than just working backwards, but I think you just have to acknowledge the environment you're in. And also, 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 educate a broader organization. But it's very company specific. So despite what I might want to do, I've just got to recognize that I have more leverage down with my team versus up or across.

Lenny (00:53:51):
Is there a template that you use consistently? Is that something that you've published of how to frame the problem, how to frame all these other elements?

Ian McAllister (00:54:00):
I have shared posts on, I know for sure LinkedIn and I probably should put it on the newsletter, on my newsletter, that's a working backwards template and some posts about how to do the process or tips on how 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 could just copy it and grab it.

Lenny (00:54:19):
Awesome. We'll link to that in show notes. Definitely send that to me after we wrap this thing. And I was going to ask, does Amazon work backwards on every product they work on/do you suggest working backwards in every feature and product?

Ian McAllister (00:54:33):
I think there's some scale below which it doesn't probably make sense to do this process because there's a little bit of overhead to it. But I think if it's a new product, absolutely. And 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 a working backwards review. Ideally that would happen 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.

Lenny (00:55:18):
Got it. You mentioned a review. What is that? Working backwards review?

Ian McAllister (00:55:22):
Well that would just be a meeting with leadership or other folks to review the concept, review the press release, review the FAQ and ask questions. And in some cases that would be the gate to 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 green lit. 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 nother concept. It's about the legitimate plan to succeed. One other thing that I use, I got a chance to have lunch with Jeff Bezos. It was probably back in 2008 or something like this. And I asked him, "What's your criteria for investing in something new?"

Ian McAllister (00:56:09):
And he said, "Well it's 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 got to have all three of those things. And I think the FAQ part of the working backwards process is that early stage legitimate test of whether this thing has a plan. Because you could have this internal press release or big idea or big idea for a solution, but the FAQ 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 FAQ, but I think it's another way to build trust that you've been thoughtful enough given the stage of the product to deserve the resources or deserve to move forward with it.

Lenny (00:57:03):
That's awesome. I feel like most PMs listening to this are going to be like, "I always start with a problem. I'm always problem focused so I'm working backwards. So I'm good." Other signs of just like, no, you're not. You think you are but you're probably not doing this well. Is there a symptom of you're not actually doing this correctly?

Ian McAllister (00:57:23):
The most common thing that I see that tips me off is when they talk about something, there's different pieces in the pantry and we have these ingredients, we could put them together, we could add these two things together and make a meal out of it. 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 in this new thing.

Ian McAllister (00:58:09):
So if you start talking about those things or the technology, I think that's a likely case that you're not really working backwards as opposed to the opposite is if there's a customer problem that feels compelling even before the solution, yeah, that does feel compelling. And just like with every startup out there, probably a lot of the pitches are there's a big audience and a painful problem and it's the painkiller versus the vitamin thing. And then we have a novel way to solve that. That's kind of working backwards. But 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.

Lenny (00:58:56):
Awesome. We're reaching about an hour 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?

Ian McAllister (00:59:06):
Let's see. No. I mean I think we covered a bunch of good ground. It's been fun, but nothing particular.

Lenny (00:59:11):
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?

Ian McAllister (00:59:22):
All right. Let's do it.

Lenny (00:59:23):
Let's do it. What are two or three books that you've most recommended to other people?

Ian McAllister (00:59:28):
I say 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 best seller list, but I thought it was interesting.

Lenny (00:59:55):
What's another favorite podcast of yours other than this one possibly?

Ian McAllister (00:59:59):
I think How I Built This is really interesting just to decompose how interesting businesses and products came about. And then just because of my work, EV News Daily is 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.

Lenny (01:00:18):
Very niche. I love it. What's a favorite movie or a TV show you've recently seen?

Ian McAllister (01:00:24):
Yellowstone. That's definitely my favorite. Can't wait for the next season. Montana's 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 was Everything Everywhere All At Once. I love movies that are not predictable and I thought that was just very creative.

Lenny (01:00:40):
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.

Ian McAllister (01:00:50):
It's a harsh environment.

Lenny (01:00:51):
Quite harsh, turns out. Especially if you mess with the Duttons. Next question. Favorite interview question that you like to ask.

Ian McAllister (01:00:58):
When I'm coming out of left field, I ask people 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.

Lenny (01:01:06):
What do you look for in their answers?

Ian McAllister (01:01:08):
I don't know. 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 to throw them off balance.

Lenny (01:01:32):
Interesting. Favorite app right now.

Ian McAllister (01:01:35):
It's probably not too interesting, but to be honest, YouTube. It's like the eighth wander of the world and 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 grow and learn about anything.

Lenny (01:01:58):
I imagine some people are watching this on YouTube right now.

Ian McAllister (01:02:01):
All right.

Lenny (01:02:02):
I just read a story about an Olympic javelin thrower who learned how to do this watching YouTube. He 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.

Ian McAllister (01:02:18):
And I mean, I'm old, so I didn't have this when I was growing up. I remember going to the library and sending away for a brochure in the back of a magazine and things. Learning was not so easy back then. The internet obviously 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.

Lenny (01:02:40):
Final question. Who else in the industry do you most respect as a thought leader, someone you look up to?

Ian McAllister (01:02:46):
I 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 he measures [inaudible 01:03:02] of his talks and things like this. He's invested over his career to be a great communicator. So I think he's a good role model for me and I think for others out there.

Lenny (01:03:11):
That guy's a force. I'm happy that we've had him on this podcast. I'm hoping that everyone eventually, that people mention 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?

Ian McAllister (01:03:38):
Yeah, I guess Twitter's a great place. So IanMcAll, I-A-N-M-C-A-L-L, is my handle. And then 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. Ianmcallister.substack.com. And that's something to connect and feel free to subscribe and 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. We were talking earlier about writing or doing other things and the value of that is just 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.

Lenny (01:04:25):
Amazing. And we originally connected over that piece that you wrote, so it all circles back 10 years later maybe. Thanks, Ian.

Ian McAllister (01:04:32):
All right. Thanks Lenny.

Lenny (01:04:34):
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.