成为前 1% 产品经理需要什么 | Ian McAllister (Uber, Amazon, Airbnb)
What it takes to become a top 1% PM | Ian McAllister (Uber, Amazon, Airbnb)
Ian McAllister: 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: 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.
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.
Ian, welcome to the podcast.
Ian McAllister: Thanks for having me, Lenny. I’ve been looking forward to this.
Lenny: 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: 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: 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: 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: 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: 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.
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: 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: 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: 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: 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.
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: 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: 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: I forgot to bring that up too. I’m glad you touched on that.
Ian McAllister: I don’t know how I missed that. I guess I skipped past that with the Amazon stuff.
Lenny: The most transformative time getting to work together.
Ian McAllister: That was awesome. That was awesome. I learned a lot from you too during that time.
Lenny: 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: 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: 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: 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.
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: 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: 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: 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.
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.
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.
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.
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.
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.
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.
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: 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: 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: 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: 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: Awesome. We’ll talk about all that.
Ian McAllister: 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: 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: Yeah, absolutely. Absolutely.
Lenny: 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: 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.
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.
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: So thinking big, building trust. Was there a third?
Ian McAllister: 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: 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: 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: 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: 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: 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: 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.
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: 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.
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: 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: 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: 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: 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.
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: 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: 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: What better way to learn a lesson than get some wrong and then you never forget it again.
Ian McAllister: 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: 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: 12 years.
Lenny: 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: 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.
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: 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: 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: 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.
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.
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.
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.
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.”
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.
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: 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: 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: 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 …
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: 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: 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.
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: 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: Yeah.
Lenny: 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: 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.
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: 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: 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: 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: 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: Got it. You mentioned a review. What is that? Working backwards review?
Ian McAllister: 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?”
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: 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: 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.
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: 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: Let’s see. No. I mean I think we covered a bunch of good ground. It’s been fun, but nothing particular.
Lenny: 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: All right. Let’s do it.
Lenny: Let’s do it. What are two or three books that you’ve most recommended to other people?
Ian McAllister: 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: What’s another favorite podcast of yours other than this one possibly?
Ian McAllister: 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: Very niche. I love it. What’s a favorite movie or a TV show you’ve recently seen?
Ian McAllister: 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: 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: It’s a harsh environment.
Lenny: Quite harsh, turns out. Especially if you mess with the Duttons. Next question. Favorite interview question that you like to ask.
Ian McAllister: 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: What do you look for in their answers?
Ian McAllister: 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: Interesting. Favorite app right now.
Ian McAllister: 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: I imagine some people are watching this on YouTube right now.
Ian McAllister: All right.
Lenny: 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: 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: Final question. Who else in the industry do you most respect as a thought leader, someone you look up to?
Ian McAllister: 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: 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: 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: Amazing. And we originally connected over that piece that you wrote, so it all circles back 10 years later maybe. Thanks, Ian.
Ian McAllister: All right. Thanks Lenny.
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.
Glossary
| English | 中文 |
|---|---|
| Amazon Smile | Amazon Smile(Amazon 的公益购物项目) |
| ASIN | ASIN(Amazon Standard Identification Number,Amazon 产品标识符) |
| Berkshire Hathaway | Berkshire Hathaway |
| book of business | 业务簿 |
| cascading effect | 级联效应 |
| Consumer Business Review | 消费者业务评审 |
| copy | 文案 |
| disagree and commit | 反对并承诺(Amazon 领导力原则之一) |
| Doug Herrington | Doug Herrington(Amazon 消费者业务负责人) |
| driven by impact | driven by impact(以影响力驱动) |
| earn trust | earn trust(Amazon 领导力原则之一) |
| fitness function | 适应度函数 |
| Gibson Biddle | Gibson Biddle(曾任 Netflix/Chegg 产品副总裁,产品领域知名博主) |
| gifting business | 礼品业务 |
| GM | GM(General Manager,总经理) |
| Goldilocks zone | 金发姑娘区间 |
| GPM | GPM(Group Product Manager,高级产品经理) |
| intentions | intentions(此处 Ian 口语中夹杂使用,指”好的出发点/计划”) |
| Kim Rackmiller | Kim Rackmiller(Ian 在 Amazon 的上级,全球发现业务 SVP) |
| mechanism | 机制 |
| newsletter | newsletter(通讯/邮件订阅刊物) |
| one pager | 一页纸 |
| Operator’s Manual | Operator’s Manual(Ian 写的一篇产品经理操作指南帖) |
| PM | 产品经理 |
| PRD | PRD(Product Requirements Document,产品需求文档) |
| press release | 新闻稿 |
| program manager | 项目管理(微软岗位,近似产品经理角色) |
| roadmap | 路线图 |
| Russell | Russell(Ian 的第一任老板) |
| Sarah | Sarah(Ian 的妻子,AWS 产品经理) |
| six pager | 六页文档 |
| skip level | 隔级上级 |
| think big | think big(Amazon 领导力原则之一) |
| Thomas | Thomas(Ian 在微软的产品单元经理) |
| trade-offs | 权衡 |
| Warren Buffett | Warren Buffett |
| WBR (Weekly Business Review) | 每周业务评审 |
| weasel words | 模糊措辞 |
| working backwards | backward working(流程) |
Reformatted by reformat_english.py
成为前 1% 产品经理需要什么 | Ian McAllister (Uber, Amazon, Airbnb)
文字记录
Ian McAllister (00:00:00): 如果你忘掉其他一切,忘掉政治、忘掉晋升、忘掉拥有更大的团队或别的什么,如果你每天醒来只是想尽可能产生最大的影响力,或者如果你是一个领导者,试图带领你的团队在公司中产生尽可能大的影响力,你如何度过一天中的每一部分,那就是一盏非常好的指路明灯。
Lenny (00:00:22): 欢迎收听 Lenny’s podcast。我是 Lenny,我这里的目标是帮助你在构建和增长产品的手艺上变得更好。今天的嘉宾是 Ian McAllister。Ian 撰写了产品管理领域最经典的帖子之一——《Top 1% 的产品经理和 Top 10% 的产品经理有何不同》,此外他还在线分享了许多其他文章。Ian 在职业生涯中管理过 100 多位产品经理。他在 Amazon 工作了 12 年,创建了 Amazon Smile,并领导负责 Alexa 国际化扩展的团队。他还在 Airbnb 和我共事过,现在他在 Uber 负责车辆平台的全球产品,包括推动 Uber 车队日益电动化和自动化。在我们的对话中,主要聚焦两个话题。Top 1% 的产品经理和其他人的区别是什么,分别针对新任产品经理和资深产品经理来讨论。我们还深入探讨了 backward working 流程。我们会谈到如何在你自己的团队中实施这个流程,以及你可能哪里做错了。节目说明中还有一堆模板和指南的链接,如果你想跟着操作,一定要去看看。那么,我请出 Ian McAllister。
Mixpanel 赞助
Lenny (00:01:32): 本期节目由 Mixpanel 赞助。提供强大的自助式产品分析。如果你听这个播客,你就知道在构建优秀产品时很难不做妥协。而在使用数据方面,很多团队认为他们只有两个选择:要么凭直觉快速决策,要么以蜗牛般的速度做数据驱动的决策。但这是一种虚假的二选一。你不必为了获得可信的产品洞察而牺牲速度。使用 Mixpanel,不存在取舍。以思维的速度获得深度洞察,价格公平,随你的成长而扩展。Mixpanel 构建强大且直观的产品分析工具,让所有人都能信任、使用、负担得起。探索适合各种规模团队的方案,看看 Mixpanel 能为你做什么,请访问 mixpanel.com。顺便说一下,他们也在招人,去看看 mixpanel.com 了解更多。
Athletic Greens 赞助
Lenny (00:02:24): 本期节目由 Athletic Greens 赞助。我在几乎所有我听的播客上都能听到 AG1,比如 Tim Ferris 和 Lex Friedman 的节目,所以今年早些时候我终于试了一下,它很快就成为我早晨习惯的核心部分,尤其是在需要深度写作或录制像这样的播客的日子里。我喜欢 AG1 的三点。第一,一小勺溶解在水中,你就能吸收 75 种维生素、矿物质、益生菌和适应原。我有点把它看作我营养的一个小安全网,以防饮食中遗漏了什么。第二,他们把 AG1 当作一个软件产品来对待。据说他们已经迭代到第 52 版了,而且不断根据最新的科学、研究进展和他们的内部测试来改进它。
Lenny (00:03:13): 第三,这是每天我可以做的一件简单的事来照顾自己。现在是时候重新掌控你的健康,用方便的日常营养来武装你的免疫系统了。每天只需一勺加一杯水,就这样。不需要一堆乱七八糟的药片和补剂来关照你的健康。为了让你更方便,Athletic Greens 将赠送你一年的免费免疫支持维生素 D 供应,加上五份免费旅行装,随你的首次购买一起附送。你只需访问 athleticgreens.com/lenny。再说一遍,athleticgreens.com/lenny。掌控你的健康,获取终极的日常营养保障。
对话开始
Lenny (00:03:55): Ian,欢迎来到播客。
Ian McAllister (00:03:57): 谢谢你邀请我,Lenny。我一直在期待这次对话。
Lenny (00:03:59): 我也是。我相信你经常听到这句话,但当我是一个很新的产品经理的时候,你写的关于什么造就了 Top 1% 产品经理的那篇文章非常有影响力,真的帮助我弄清楚该专注于什么,哪些技能真正重要。而且我发现它一直是产品经理们在试图弄清楚自己该做什么时的一个传奇帖子。我在为这次采访做准备时又重读了一遍,我就想,哇,这个……现在我站在另一边了,我觉得这说得真对。所以我非常兴奋能和你当面深入讨论这些问题,虚拟的当面。所以再次感谢你来做这个。
Ian McAllister (00:04:35): 是啊。太棒了。我也很兴奋能花些时间和你聊聊产品,看看会聊出什么。
关于那篇经典帖子的影响
Lenny (00:04:42): 你在写那篇文章、把它整理出来的时候,有没有预料到它对你职业生涯或整个产品经理行业的影响?
Ian McAllister (00:04:51): 绝对没有。那时候我经常在 Quora 上潜水,就是随便看看,回答一些问题,我会寻找处于”金发姑娘区间”的问题——不会太抽象太宏观,比如”如何成为一个好的产品经理”,也不会太具体。这个题目刚好在中间。于是我挑了几个这样的问题来回答,我觉得更多是为了整理自己的思路,那对我来说是有趣和好玩的事情。并不是因为我觉得它会有什么真正的传播力。但显然,看到人们经常引用它,这很酷,也很有趣。
Lenny (00:05:23): 我们会在节目说明中附上链接。如果听众不知道我们在说什么,我们会附上链接,你可以全部查看。我们会在实际对话中聊到很多这方面的内容,但其中有几件事值得深入聊聊。一个就是在网上写作对一个人职业生涯可能产生的影响。我猜这一篇文章对你职业发展的轨迹有很大的影响。你能分享一些吗?是这样吗?
Ian McAllister (00:05:45): 是的,确实如此。还有另一篇帖子,应该在那篇之前,有人问起 Amazon 的产品开发流程,所以我就写了 working backwards 流程。这不是我的流程,我只是使用过它,然后描述了一下,结果也引起了一些关注。我觉得这两篇帖子,加上后来我开始写更多关于人员管理和产品管理的内容,对我来说价值太棒了——仅仅是在行业中与人建立联系这件事本身。当时大概是 2010 年左右,很多 Amazon 的人我觉得都是百分之百埋头苦干。那里的文化有点保密,虽然可能不像 Apple 那样,但确实比较封闭。但我对创业社区和整个产品领域很感兴趣,所以我花了一些时间尝试与人交流,通过这些我结交了非常多很棒的人脉和关系。
Ian McAllister (00:06:39): 我记得和你互动,认识 Joebot 以及 Airbnb 其他一些早期的人,甚至在我加入之前。但显然我把这些工作成果和这些关系归功于最终去了那里,以及因为这个而结识的那么多很棒的关系和人。除了这些小小的正面反馈之外——我的意思是人们会不定期在推特上给我留言,“嘿,顺便说一下,超爱这篇文章”之类的。所以这非常令人满足。
Lenny (00:07:03): 你稍微提到了一些你的背景,我们马上就要聊到那部分,我想让你分享你做过的所有事情。但这里面还有一个我觉得很有意思的点,关于写作的力量,这个话题反复出现——它往往只是始于你试图整理自己的想法、把它写出来,结果却发现,哇,这么多人觉得它有价值,然后它就传播开了。所以这是一个非常简单的思路:如果你想在网络上开始写作,只需要总结一下你一直在思考的、想要在自己脑子里梳理清楚的东西。有一句经常被归于 Mark Twain 和 Hemingway 名下(虽然很可能是误 attribution)的话:直到我把它写下来,我才知道自己想了什么。这些事情上确实如此,所以这是一个很好的例子。
Ian McAllister (00:07:42): 而且我觉得任何类型的写作都是这样,最初可能没那么有结构,但我会——部分原因是我在为外部读者分享内容——尝试把它组织好,让它紧凑,不要太啰嗦或东拉西扯。我觉得商业写作——我在 Amazon 做了大量这方面的工作——非常有价值,因为只有清晰的思考者才能成为清晰的沟通者。写好东西或沟通好东西,有两个检验标准,就是这两件事本身。所以我发现这对于磨利你的斧头相当有价值。
聊天方向预告
Lenny (00:08:15): 所以我们今天聊天要聚焦的两件事就是:什么是前 1% 的产品经理,以及 Amazon 的工作方式,特别是 backward working 流程。这些都是很好的铺垫。不过在进入这些话题之前,你能不能花一分钟给我们讲讲你职业生涯中做过的一些了不起的事情,以及你现在在做什么?
Ian 的职业经历
Ian McAllister (00:08:31): 嗯,我可以告诉你我做过什么。至于是否了不起,就留给别人去评判吧。所以在学校学了金融和经济学之后,我做出了一个合乎逻辑的选择——去啤酒行业做市场营销,然后又做了一个合乎逻辑的选择——搬到东京,在不懂日语也不懂软件开发的情况下,白手起家进入了软件开发领域。做了几年之后,回到美国,先在一家创业公司做开发,然后去了一家中型公司,之后转到微软做项目管理(program manager),基本上就是产品经理,一样的角色。在那边学到了不少东西,然后通过一个机会联系上了 Amazon,2006 年加入。那才是我真正开始构建我的产品工具箱和领导力工具箱的时候。在 12 年间做了几件不同的事情,头几年在零售和转化率方面。
Ian McAllister (00:09:22): 然后我转到了流量和直接流量留存的领域,那时我创建了 Amazon Smile。还有在 Alexa 的角色——我领导了 Alexa 国际化,把 Alexa 和 Echo 扩展到了另外六个国家。最后一个角色是配送体验和运营。所以我在那里领导了多个不同的项目。然后最近加入了 Uber,担任车辆方向的产品和技术高级总监。也就是说,所有帮助车队和租赁公司让 Uber 司机可以使用他们的车辆来赚钱的工具。可持续性技术和电气化,我们的车辆平台,以及为自动驾驶车辆进入平台铺路。就这些。
职业线索:自治与 AI
Lenny (00:10:03): 太厉害了。我刚意识到你职业生涯中有一条线索,跟自治和 AI 有点关系,对吧?先是 Alexa,然后是 Uber,现在在做的自动驾驶相关的工作。这是你有意为之,还是巧合?
Ian McAllister (00:10:18): 嗯,我想你可以把这些联系起来。显然两者都涉及机器学习、AI。我的理解是,我经历了好几个不同的”人生”,尤其是在电商领域,所以这让我能够覆盖整个范围。另外,我好像忘了提在 Airbnb 的那段时间,和 Joebot、你、Vlad、Dan 还有 Shirley 一起工作,在那边专注于搭建客户支持技术平台。所以那是电商平台的另一个部分。覆盖面很广。
Lenny (00:10:45): 我也忘了提这个。很高兴你提到了。
Ian McAllister (00:10:48): 不知道我怎么漏掉的,大概是被 Amazon 的事情一带就跳过去了。
Lenny (00:10:50): 最 transformative 的一段共事时光。
Ian McAllister (00:10:53): 那段时间太棒了。那段时间我也从你身上学到了很多。
Lenny (00:10:56): 真是美好时光。说到 Airbnb 和这一切,现在正好可以聊聊什么造就了前 1% 的产品经理。我知道你那篇帖子的标题是”1% PM 和 10% PM 的区别”,但感觉它的范围其实更广,就是如何成为一名前 1% 的产品经理。我想也许一个好的开始方式是,先快速过一下你这些年来总结的那些特质,也就是一个前 1% 的产品经理需要精通哪些东西。先快速过一遍,然后我们再挑几个深入聊聊。
前 1% 产品经理的特质
Ian McAllister (00:11:28): 好,我正打算把我的帖子调出来,这样我才能实际对照着说。你想让我全部过一遍,还是挑几个谈谈?
Lenny (00:11:33): 我们先快速过一遍,把它们摆出来,然后我会追问几个深入聊聊。
Ian McAllister (00:11:40): 好的,听起来不错。嗯,我当时是这样列的:Think big(想得大)。总是要追求更大的影响力。Communicate(沟通)。我想我们会稍微聊到这个。这对产品经理来说超级重要,是对他们思维和沟通能力的检验。Simplify(简化)。如何用更少的资源做更多的事情、产生更大的影响。简化是实现这一点的绝佳方式。Prioritize(优先级排序)。我认为这是产品经理在沟通之后的核心技能,而且有非常多的视角来看待这件事。让我看看。Forecasting and measuring(预测与衡量)。我觉得这非常重要。把产品经理和咨询师区分开的一点是,你会预测,然后执行,然后衡量和验证,这帮助你建立直觉。显然还有核心的执行力——就是把东西做出来,说到做到。Understanding technical trade-offs(理解技术权衡)。你不需要是软件工程师才能成为优秀的产品经理,但你对技术权衡了解得越多——不仅仅是产品和客户的权衡——就越能帮助你简化并从资源中获得更高的产出。
Ian McAllister (00:12:40): Understanding good design(理解好的设计)。如果你在做任何面向客户的事情,这总是能帮助你以客户或用户的思维方式来思考。你不需要亲自做设计,但你理解得越多就越有帮助。Writing effective copy(撰写有效的文案)。这个作用很大——不是要做得差不多就行,也不是把文案外包给别人,而是擅长用寥寥几个词和你的客户沟通。这是一项很棒的技能。这些是我当时写的,大概是十年前吧,然后最近在我的 newsletter 里更新了那篇帖子。我加了几条新的,说实话,因为回顾的时候,有几个我如今经常在想的、第一次写的时候遗漏的特质。Earn trust with others(赢得他人的信任)。这对产品经理来说极其重要,尤其是如果你想在产品领导力方面继续成长,这就变得更加重要了。
赢得信任及其他关键特质
Ian McAllister (00:13:29): 我认为信任是产品经理和产品领导者的通行货币,尤其是如果你想在职场上不断成长的话。Digging for data(挖掘数据)。数据就在那里,你需要培养自己去找到它的工具和能力,而不是依赖分析师或今天的报表。所以这对任何做产品的人来说都是一项非常重要的技能。而且你越初级,这件事就越重要,因为你真正在一线搭建产品。Pushing back effectively(有效回绝)。这是一门艺术也是一项技能,但我认为你在这方面的能力与你作为领导者成长和成功的可能性高度相关。因为如果你对什么都点头,你哪儿也去不了。Adapting to change(适应变化)。你对变化的反应显然会影响——一是你的情绪和士气,二是你重新凝聚自己、凝聚团队的有效程度。然后是 Driven by impact, not promotion(以影响力驱动,而非以晋升驱动)。归根结底,你每天醒来想的是如何为你的业务创造影响力,这才是你是否可能获得晋升的真正指标。所以去做这件事,而不是仅仅盯着如何升职、让它指导你的每一天。
新 PM 应聚焦的三项核心技能
Lenny (00:14:33): 很好。所以这是一个很长的清单。产品经理需要擅长的东西很多,我觉得如果你是产品经理,你已经知道了。这是一个疯狂的、不可能把所有事情都做完美的职位。在这篇帖子的最后你甚至提到,你从未见过一个 1% 产品经理能同时做到所有这些事情。我觉得这很重要。没有人能在所有这些方面都是最好的。所以让我们稍微深入一点、更聚焦一些。假设你是一个新产品经理,在这些技能里——我忘了有多少个,大概 10 到 12 个——你认为哪三个是新手产品经理最应该擅长和聚焦的?
Ian McAllister (00:15:06): 大概是沟通、优先级排序和执行力。我认为这些就是核心的基础构件。其他技能在你成长和变得更资深时会更加重要,但这几个,无论你处于产品职业生涯的哪个阶段,都非常重要。成为一个更好的沟通者是我整个产品职业生涯都在努力的事情,而且我会一直努力到停下来的那一天。我记得很多年前我在微软,这是我第一个实质上的产品经理角色,我的产品单元经理 Thomas 来到办公室,我记得他问我:“这个什么时候能发布?“我回答:“嗯,这个东西花的时间稍微长了一点,还有那个事情……”我给了一大堆背景信息,但没有真正回答问题。我从他那里得到了一些反馈,大概意思是——这不是……归根到底他在等一个日期。
从反馈中精进沟通
Ian McAllister (00:15:53): 我反思了这件事,那是我记忆中开始努力成为一个更好的沟通者的起点,现在我仍在路上。去 Amazon 的时候,我为 Kim Rackmiller 工作,她当时是我们的——我想那时是全球发现业务 SVP(Senior Vice President,高级副总裁)。我记得她是 Amazon 的第一位 TPM。她很严厉但非常聪明。所以那也是一段早期的、向她学习的经历。有时候你会在没有真正回答问题时收到反馈。我的第一任老板 Russell 和我整理并开始收集一个叫 “Book of Kim” 的东西。我们会把从她那里学到的最佳实践收集起来:避免模糊措辞(weasel words),先回答再解释,正视自己的问题。然后开始逐步积累。
Ian McAllister (00:16:36): 后来我随着时间不断扩展,加入了更多内容,写了一篇叫 “Operators Manual” 的帖子,试图把所有这些整理到一起。但这真的非常重要,而且随着你与越来越资深的人合作,赌注也越来越高。如果你能早早就养成用日期回答”什么时候”的问题的习惯,知道如何用数字来回答问题,以及——说实话——学会从反馈中学习,在收到一份文档的反馈后、一场会议后、或者在电梯里回答完一个问题后给自己打分。如果你能试着说:“天哪,我怎么能做得更好?“然后努力改进,你是可以做到的。如果你只聚焦在这一件事上,你就能走得很远——虽然产品经理还有其他 150 项技能——但如果你没有这个,你不太可能在产品职业生涯中走得太远。
优先级排序
Ian McAllister (00:17:24): 所以那是沟通。下一个我想是优先级排序。我认为这是产品经理的头号关键工具。因为擅长优先级排序能带来非常多的好处。它不仅仅是”你接下来做哪个项目”或”你做这个项目还是那个项目”。优先级排序有很多不同的维度:你在路线图中优先哪些主题,每个主题中优先哪些项目,这些项目怎么排序,一个项目你要做到什么程度。还有时间管理也是一个优先级排序的功能——你选择把时间花在什么上?哪些事情你要全力以赴做到出色,哪些事情你要让它饿着、不给关注,或者干脆不做?在技能、智力和资源相同的情况下,一个天生擅长优先级排序的产品经理能产生 5 倍于不具备这项技能的人的影响力。
Ian McAllister (00:18:18): 我在 Amazon 早期的成功——如果你能称之为成功的话——我认为完全不是因为。不是因为我工作更聪明,也不是我更聪明,不是我工作时间更长,也不是我比别人更懂技术。我觉得只是因为,第一,我对影响力极度渴望。如果有一个数字或指标衡量我所负责的业务的成功,我就想让那条线持续往右上方走。不是为了达成一个目标,而是要尽可能远、尽可能快地往右上方走。如果说有什么秘诀的话,就是和团队一起锁定那些杠杆效应最大的项目,然后把团队所有资源都调动起来。这是一个好的起点,也和 Amazon 从适应度函数(fitness function)或指标出发进行 backward working 的做法相契合。
Ian McAllister (00:19:01): 我在那里的第一个团队这么做,后来管理礼品业务(gifting business)时又做了一次。所以这就是一项我认为帮助了我、也弥补了我可能存在的不足的技能。我没有世界上最强的大脑,也没有最大的工作记忆,我也不是最懂技术的,但通过真正努力做好优先级排序,我认为这帮了我,而且现在仍然在帮我。
执行力
Ian McAllister (00:19:23): 第三个是执行力,这也不意外——每个产品经理都必须执行。我认为,假设你优先级排序做得好,那么执行力就意味着把你想要构建的东西塑造成一个简洁紧凑的方案,产生尽可能高的影响力。执行力也在很大程度上取决于你合作的团队——你的设计师、数据科学人员,尤其是你的工程师。
Ian McAllister (00:19:47): 所以任何关于他们工作做得好不好、资源充不充足、每个冲刺是否在持续进步的事情,你都有一定程度的责任去帮助推动,因为这直接影响你团队的执行力,最终也影响你作为能够执行的人的声誉。执行力背后的驱动力——产品经理是执行力和影响力背后的动力源。如果你停滞了或者没有做好自己的工作,项目很可能也会停滞。所以你是那个驱动者——尤其是如果你幸运地有一位 TPM 在船尾帮你打鼓、驱动所有人向前推进的话。但话说回来,很多人写了很多关于执行力的内容,这里面的门道很多,但我想这三项大概就是我建议聚焦的。
Lenny (00:20:32): 太棒了。这三项有意思的地方在于,如果你看列表上其余的那些——think big、理解技术权衡、理解好的设计——我觉得我从中得到的启示是,这些东西在你还是新手产品经理时不需要花太多精力。像你说的,把精力集中在沟通、优先级排序、执行上,其他的少关注一些。因为后面它们会越来越重要,当然能学多少就学多少,但换个角度想,刚起步时哪些东西不需要焦虑,反而更容易想清楚。
Ian McAllister (00:21:02): 是的,我觉得这个思路是对的。如果要说产品经理第一年的核心,就聚焦这几件事。其他技能可以随着时间慢慢培养。不过没错,你说得很准确。
三项能力的具体提升方法
Lenny (00:21:14): 如果我们回到这三项——也许作为最后一个问题,你可能也不一定有答案——但如果你想想沟通、优先级排序和执行,有没有一件具体的事情,你能建议正在听这个节目的产品经理去做,来在其中某一项上有所提升?有没有你学到的什么窍门,比如”哇,这样做就能在沟通、执行或优先级排序上提升一个档次”?还是没有?
Ian McAllister (00:21:37): 最接近一份清单的东西,就是我之前提到的那篇帖子——Operator’s Manual。那是最接近”如果你做了这些具体的事情,我认为会很有帮助”的东西。因为里面很多内容都是围绕避免那些容易掉进去的坑和沟通中的错误,比如絮叨。如果你被问到一个问题,你先解释半天然后也许才说到答案,如果你能做到先想清楚,先给答案再解释,或者有时候给了答案就闭嘴,这其实就是一个你可以实际去做来提升沟通的具体方法。里面还有一些其他的建议。所以那是我试图把一些东西编码化的尝试——把我们早期在 Amazon 收集到的一些经验,加上更多内容整合在一起。其他的嘛……是的。很遗憾在优先级排序方面没有简单的窍门,除了……我的意思是,我认为 backward working 是一个很好的方法,能帮助你产生影响、引导你的优先级排序。这不是一个简单的技巧,而是一套实践和行为方式,你持续去做,最终会让你更好地进行优先级排序。
Lenny (00:22:39): 太好了。这些我们后面都会聊到。
Ian McAllister (00:22:40): 然后我觉得沟通方面,简单的建议就是——每次沟通之后给自己打个分,试着花一点时间反思,慢慢地这就会变成自然而然的事——想一想,“天哪,我刚才回答那个问题怎么能回答得更好?“然后下一次你就试着回答得更好,这就是一个持续改进的过程。
Lenny (00:22:58): 或者甚至可以问问你的上级,“嘿,在上次会议或那封邮件中,我在沟通方面有什么可以做得更好的?”
Ian McAllister (00:23:04): 是的,完全可以。完全可以。
高级产品经理应聚焦的能力
Lenny (00:23:06): 好,那我们换个角度来看这个问题。假设你现在是一位高级产品经理,这些属性中有哪三个你会建议大家在职业生涯中去专注提升的?
Ian McAllister (00:23:17): 天哪,说实话还是沟通。我认为在产品管理的每个层级,它都至关重要——只是赌注更高了。think big 肯定算一个。我记得 Warren Buffett 在 Berkshire Hathaway 的信里某个时候用过一句话,大意是:在咱们这个规模上,得去猎捕更大的象。所以我认为不管在任何规模,作为一名产品经理,无论你的想法是什么,无论你的方案或你要解决的问题是什么,一开始花一分钟问问自己:这件事能不能做得更大?能不能比最初的想法更有影响力,即使最初的想法听起来已经不小了?这是一个工具,也往往是我的起点——当产品经理们跟我分享一个想法时,我会试着把它扩大到可能被扩大的程度,从那个角度去思考,然后也许你仍然想从小处着手,但心中要有一个更大的愿景。
Ian McAllister (00:24:04): earn trust 是非常重要的一项,这也是我后来才加进去的原因。而且随着你进入高级角色,它变得更加重要,因为我认为它确实是一位产品领导者——或者大概任何职能领域的任何领导者——的真正通行货币。因为如果你想申请更多资源来做更大的事情,而你的领导层不信任你能用好这些资源、做到你说过要做的事,你大概率拿不到这些资源。但如果你建立了信任,证明你是资源的好管家,能用一个给定的团队创造很大的影响力,这就直接关系到你获取更多资源的能力。信任就是通过反复地设定预期并兑现预期来建立的。我认为这是一个产品经理应该牢记的准则:我是否在兑现自己设定的预期?不只是做好事情,还要说到做到——提前预告、设定目标,然后命中它。
Ian McAllister (00:24:54): 如果你反复这样做,你的处境会相当不错。作为产品经理或产品领导者,有非常多的实践可以建立信任。你永远说实话。你在说好要上线的时候上线,你上线你说好要上线的东西,你对自己的错误负责。而另一些做法则会失去信任。如果你撒谎,如果你闪躲回避,如果你没有交付你说好要做的东西,如果你无视自己的错误或者反复犯同样的错误。所以我认为,就是对自己保持高标准,把信任视为那种通行货币——这对产品经理、对 GPM 或产品总监,在任何层级都是如此——这就是你要去积累的东西。
Lenny (00:25:34): 所以是 think big、建立信任。第三个是什么?
Ian McAllister (00:25:37): 我想也许是最后一个,对产品经理来说当然相关,但其实对所有人都适用——就是 driven by impact。如果你忘掉其他一切,忘掉政治,忘掉晋升或拥有更大的团队之类的,如果你每天醒来就是想在力所能及的范围内产生最大的影响力,或者如果你是领导者,想用你的团队在公司中产生最大的影响力——这会影响你如何构建你的路线图,如何度过你一天中的每一个部分——那就是一盏非常好的指路明灯。我记得在 Amazon 的前十年,很自然地——不是因为我想过这件事——我就是渴望产生影响。把我负责的业务拿过来,尽可能快地增长它。我可能 loosely 地想过晋升的事,但我没有真正去想它。我从未跟我的上级谈过这件事,也没有主动提起过。我就是专注于把我手上的业务簿做得更大。最终的结果是,我被晋升了好几次,我的角色确实也在成长,但那不是驱动我的东西。驱动我的就是影响力本身。
Lenny (00:26:38): 你会说 driving impact 对新手产品经理更重要,还是对高级产品经理更重要?感觉影响力就像是所有产品经理畅游其中的汤,一直都重要。但有意思的是你主要把它放在了职业生涯的后半段。你是否觉得,对于团队里的新手产品经理,你不太期望他们去思考影响力、聚焦影响力?
Ian McAllister (00:27:01): 嗯,我想对于初级产品经理来说,如果你是一个全新的产品经理,那当然你想产生影响,但你其实只是……你手上有项目或功能要发布之类的,而且你往往不一定被给予多少自主权去构建自己的路线图。你的任务就是把这件事发布出去。所以你要写规格,你要去执行、把它做好。但随着你逐渐成长,机会会越来越多,你可以去感知、去尝试产生更大的影响力,然后开始影响优先级排序或路线图。只是期望值在变化——作为初级或第一次做产品经理,这算锦上添花;但当你变得更资深处,如果事情按照它应有的方式运转,这其实就是你被评估的核心标准。是的,你当然要对团队好,要做很多其他事情,但拿两个人来比较,一个人对业务产生了巨大的影响,另一个人没有——那么正确的运作方式应该是,第一个人得到成长和发展,被赋予更大的挑战,因为如果你在更大的挑战上也能产生影响,那对业务来说就更重要。所以我认为这是理解产品领导力飞轮的一个很好的思路。
Lenny (00:28:11): 感觉很多时候作为新手产品经理,运气成分很大。你做了一个项目,结果产生了很大影响力,但你不一定是驱动了它。你碰巧做了一件——哇,这件事影响巨大——感觉在职业生涯早期,有一件事值得稍微去优化,就是去做那些很可能产生很大影响力的事情,即使你并不负责制定策略和排优先级。
Ian McAllister (00:28:29): 嗯,我想如果你在选择做什么产品方面有选择权的话,确实如此。如果你能选择做一些属于进攻性的事情、驱动业务的事情。确实,如果某件事带来了收入或客户或进攻性的成果,高管们就会注意到;而反过来,可能不太关注那些——也许不该这样——降低风险但风险从未实际发生的事情,或者让成本中心运转得稍微高效一点的事情。所以这是一个与你的成功相关的视角。另外我想还有你为谁工作。我觉得我们大多数人,尤其是职业生涯早期,并没有选择权。有时候运气站在你这边,那很好——我在 Amazon 就是这种情况,我与之共事的一些领导者非常出色。但有时候并非如此。不过我觉得,你能越多地去辨明你为谁工作——因为他们在这些技能和排优先级方面越强,首先他们就越是好的老师、好的榜样让你去学习——所以我认为在任何工作变动中,这都是值得认真思考的事情。
Lenny (00:29:30): 把这条线索收个尾,关于更高级的产品经理应该聚焦的技能,你提到了 think big、建立信任和 driven by impact。我现在要给你出个难题。我给你两个方向。一个是,如果有人想在每一点上都变得更好,你有没有什么具体建议,或者 think big、earn trust、driven impact 做到优秀是什么样的?这是两个方向。
Ian McAllister (00:29:58): 这可是六个问题啊 Lenny。让我看看我要回答什么。嗯,我觉得 think big 这个挺有意思的。理解 think big 的一种方式,尤其是随着你职业发展,是——大多数人在一个框里运作。有一个框叫产品管理,这些就是产品经理做的事情。你基本上就是构建路线图、排功能优先级、和工程团队合作。这可能就是典型的产品和技术范围。我的大多数角色其实都是一种 GM(总经理)的角色,但是一个以产品为中心的 GM,所以我自然而然地对产品在跨职能领域的含义采取了更广阔的视角。我很幸运有工程团队、营销人员、分析师和其他同事,这对我很有帮助。但我觉得作为产品经理,即使这些职能不向你汇报,你仍然可以做到这一点——对你的产品成功的定义采取真正广阔的视角,不要戴着只看产品或技术的眼罩。
Ian McAllister (00:30:58): 它可以是任何东西。任何影响成功的东西、影响你客户成功的东西,或者其他任何东西。这意味着——你不拥有营销,或者你不拥有其他某个职能——但在你找到别人来负责之前,你就是它的拥有者。这不一定是规模意义上的 think big,而是在你如何看待自己作为产品经理的角色、你的所有权和责任方面。所以我认为……你当然不想作为产品经理越俎代庖,跑去试图改变你们 CFO 对某件事的看法。但随着你的成长,你必须越来越多地这样做,找到制约你或你的产品成功的那些约束或障碍,然后不管它们是什么,把它们推倒。
Lenny (00:31:43): 对。这让我想到那个建议——像所有者一样思考,不要只想着你自己的小泡泡,想想更广泛的业务,不要局限于你可能在做的那个小产品。很好的建议。
Lenny (00:31:55): 本集由 Assembly AI 赞助播出。如果你正在寻找在音频或视频产品中构建强大 AI 功能的方法,那你需要了解 Assembly AI。Assembly AI 是一个提供最先进 AI 模型的 API 平台,Spotify、Loom 和 CallRail 等数千家以产品驱动增长的公司正在使用它将 AI 融入产品。通过简洁的 API,开发者和产品经理可以获得用于转录、摘要等数十种任务的强大 AI 模型,快速、安全且可直接用于生产环境。他们所有的模型都由内部研究训练,并由 AI 专家团队持续更新,对于产品经理来说,这让构建和发布新的 AI 功能变得很容易。从初创公司到大型企业的产品团队都在使用 Assembly AI 来自动转录和总结电话及虚拟会议、检测播客中的话题、精确定位敏感内容的出现时间、从音视频中脱敏个人身份信息,以及更多功能。访问 assemblyai.com,免费试用 Assembly AI 的 API,并在他们的无代码 playground 中开始测试模型。网址是 assemblyai.com。
Lenny (00:33:08): 在我们进入 working backwards 这个话题之前——我很期待聊这个——关于这条线索你还有什么想补充的吗?
Ian McAllister (00:33:15): 我可以再谈谈 earn trust,因为这个是我最初没有放进去的。坦白说,我在职业生涯早期甚至中期都没有认识到它的重要性,直到过去几年我才真正理解了它的重要性。我的妻子 Sarah 是 AWS 的产品经理,所以当我在她的职业生涯中给她一些指导时,我看到这真的是她的超能力——这真的让我反思,在不同角色中我本可以在 earn trust 方面做得更好的是什么?它不仅仅是那些基本的事情,比如诚实,对两个不同的人说同样的话而不是说不同的话。我认为它是真正去理解——从那个人出发 backward working——他们的目标是什么,他们组织的目标是什么,然后真正花时间和精力去努力达成共识、走到同一个方向上来。
Ian McAllister (00:34:09): 而且要愿意——不是那种一头蛮干,我职业生涯早期可能就是那样,也许在很多人看来现在还是——不是一意孤行地推进我认为正确的东西,而是多花些时间去尝试和对方建立联盟,因为如果你这样做了,最终你会更成功。所以这是我可能比较晚才认识到其重要性的一项,我现在正在努力弥补。
Lenny (00:34:30): 你有没有想到一个具体的故事,回过头来看你会觉得”我当时应该在那里 earn trust”,或者”我在那里破坏了一些信任”,你愿意分享的吗?
Ian McAllister (00:34:39): 在我和你以及 Airbnb 的团队合作的时候,我想这件事是这样的——Joebot 把我招进去,帮助搭建客户支持技术平台,大概更像是按照 Amazon 的方式来做。在保持高水准质量的同时提升效率,降低成本,这样 Airbnb 就不必让客户支持的规模和业务规模同比例增长。所以我尝试组建一个新团队并推进开发,我比较埋头按照自己认为应该做的方式来做,和那里的团队一起——让我们建立一个强有力的分析框架,让我们把所有这些东西都测量起来,真正从数据层面理解发生了什么,然后让我运用在 Amazon 让我成功的那些优先级排序能力,去优先处理那些最值得 backward working 的事情。
Ian McAllister (00:35:26): 而我当时没有做到位的,显然是真正与客户支持领导团队建立深度合作关系。这件事在某种程度上感觉我们好像是在一条线上的,一起上台什么的,但结果是我可能并没有花那么多时间和精力去建立那种真正的支持,让那位领导者能够带动整个组织围绕它一起行动,让我们步调一致。所以这是我会反思的地方。现在回想,团队做了非常了不起的事情,Shirley 真正扛起了大旗,整个团队取得了很多成果。但这是一个关于……的教训。如果重来,我可能会花更多时间,真正在那方面做得更多。
Lenny (00:36:12): 谢谢你分享这些。我之前从不知道这个故事。听起来这里的教训可能就是——不要想当然地对待领导团队,也就是那些真正会使用产品的人。这样理解大致对吗?
Ian McAllister (00:36:23): 我想说的是,如果你有某种方法,你可能相信它是正确的,它也许确实是正确的,但如果你没有建立起他们的支持和关系——让他们帮你推动和执行那个策略——它可能不会像你认为的那样被很好地执行。所以这是成功的一个重要组成部分。这是一个你必须 mitigated 的风险。努力去 earn trust、用这种方式去做,是 mitigate 这个风险的一种方式——正确的产品、正确的方向、正确的策略,如果没有你需要的支持,可能就无法落地。所以那是我学到的。
Lenny (00:37:00): 再好的学习方式莫过于把事情做错过一次,然后你再也不会忘记了。
Ian McAllister (00:37:06): 你可以说是做错了。我只是把它看作我本可以做得更好的事情。就是那种持续改进的心态。它适用于一切——每个角色、每次经历、每个项目、每次沟通。如果你建立起那种下次做得更好的肌肉,同时也试着对自己的不足有一点自我觉察,那么我认为这是一块非常好的肌肉。
working backwards 流程
Lenny (00:37:27): 这是一个很好的过渡,可以聊到我们对话的第二个领域,就是 Amazon 以及你学到的关于 working backwards 流程的东西。你在 Amazon 一共待了多少年来着?
Ian McAllister (00:37:38): 12 年。
Lenny (00:37:39): 12 年。感觉在 Amazon 工作过的人都是 10 年以上。都是很大的数字。所以他们一定做对了什么,我不知道。你觉得这是为什么?为什么人们会待那么久?挺令人惊叹的。
Ian McAllister (00:37:52): Amazon 有一个有趣的地方——而且这一点也在随时间变化——就是我觉得你能比较快地判断自己是否适合它。它可能有点像炼炉,有些简朴。但它就是和我很合拍,因为我是一个偏结构化思维、右脑型的人。所以这个想法——嘿,我可以负责一项业务,然后找到一个决定成功的指标或适应度函数,然后我的工作就是让那个数字持续上升——这种模式很契合我。然后我在大概前 10 年里围绕这个概念重新连接了自己的大脑,我只是觉得自己一直在学习,不仅是在和聪明且 driven 的人一起工作——在微软也是如此——而是这个组织里有一种 DNA 和一种连接方式,我觉得非常有效,就是和我很合拍。
Ian McAllister (00:38:44): 所以我把自己塑造进了这个环境,每一步我都觉得自己在学习和成长,对我来说其中一个好处是——你可以在这些不同的场景中从非常多的其他人那里学习。你有机会阅读那些让你比看幻灯片学到更多东西的文档。你有机会和非常聪明的人一起参加每周业务评审,从中学习。不仅从自己的经验中学习,还从那个房间里所有其他人那里学习。我就像一块海绵,有那么多的学习在发生,推动了我在职业上的发展。这就是为什么,尤其是前 10 年,那段经历太棒了——不断成长,感觉自己在建立新的肌肉、开发新的工具,我非常热爱。所以这就是我待了那么久的原因。当然后来 Airbnb——那是尝试新事物的时候了,那是一段很棒的经历,也算是一次考验。我在西雅图,公司在旧金山,每周三天在路上是一个很好的学习,最终也是回到西雅图常驻的原因。但我后来又选择了 Amazon,因为它仍然是一个很棒的地方,我觉得我可以继续学习。
Lenny (00:39:52): 太好了。我正想说他们又把你吸引回去了。是的,这挺罕见的。你从 Jeff Bezos 和 Jeff Wilke 那样的人身上学到了什么关于构建产品领导力、公司建设的东西?和那些人一起工作,有什么东西一直留在了你心里?
Ian McAllister (00:40:04): 我想说这是两个非常不同的人,但他们彼此互补得极好。我在那里的时候和 Jeff Bezos 没有开过几百次会议,但我确实有机会——特别是在开发 Amazon Smile 的过程中,以及我刚开始负责社交团队的时候——参加了一些那样的会议,我写文档,然后 Jeff 和其他十个人一起评审。做的过程——甚至早在切入 Amazon Smile 之前——其实是一种创新流程,我想你可以这么叫它。我们有一个目标:提高客户对 Amazon 的忠诚度,他们的直接流量忠诚度,不是 Prime 那种付费项目的方式,而是尝试想出另一种项目或方式,让客户可能在 Amazon 而不是其他地方开始他们的购物。当时我在负责礼品业务,然后转到流量团队,尝试想出一个新项目——没有团队,什么都没有。
每隔几个月与 Jeff Bezos 评审
Ian McAllister (00:40:58): 然后我每隔几个月会和 Jeff Bezos、Wilke 以及其他人开会,我会展示几个不同的选项,运用 backward working 流程,我们一起评审一些事实。所以在这个过程中有很多收获。第一,我发现 Jeff 非常鼓励人。每次我们从那种会议离开,也许那次会议我们并没有找到答案。我们会讨论一下,头脑风暴一下,但他离开时总是带着鼓励的态度,还会留下一句引用。有一次他说,“记住,这个过程不需要高效,因为高效的前提是你知道你要去哪里。” 然后他就离开了,诸如此类。所以关于 Jeff 会发火之类的传言,我完全没有遇到,我觉得他非常鼓励人,他总是找各种机会帮助我学习 backward working 流程。
Ian McAllister (00:41:52): 有一次我带了一个概念的新闻稿去,但里面没有问题段落。我跳过了那个部分。他看了一遍之后说,“你知道吗,也许如果你没有问题段落,就说明其实没有问题。” 这对我来说是一个小小的教训,“是啊,也许我之所以跳过就是这个原因。我并不是真正在做 backward working,我心里已经有了解决方案,所以就跳过了那部分。” 这就是从 Jeff 那里学到的关于这个流程的一个非常具体的教训。至于 Jeff Wilke,我从 Wilke 那里可能学到了更多,因为我在那里期间接触他的时间更多。有一段时间他是我的隔级上级。我对 Wilke——或者说内部大家叫他 Jaw——有着极大的敬意,因为他可以说是完美的运营者。
运营者的肌肉
Ian McAllister (00:42:34): 这种在 Amazon 工作时学到的运营者的肌肉——不管你……你并不是在做运营——但我认为业务任何部分的这种能力都源自于他。而且我认为正是由于他,Amazon 才发展出了这种肌肉。我认为这也是一些 Amazon 产品经理区别于没有在那个环境工作过的人的一个方面——那种持续改进的心态。这非常重要。其中一个很好的学习场所就是 WBR,即每周业务评审。后来改名为消费者业务评审。这是一个由 Jeff 主持的会议。会上会展示不同业务板块的一系列指标。从物流到客户支持,从流量到品类团队再到项目,无所不包。我会上去汇报 Amazon Smile 的数据。他主持那场会议的方式,能让你在一个小时内完成整个北美零售业务的指标评审。
Ian McAllister (00:43:27): 他主持那场会议的方式会引导所有在场的领导者去锻炼这些肌肉,因为你要准备好对你业务中关键指标的偏差或趋势做出说明,要了解你的业务,要知道你基于这些指标正在做什么。所以每周这一小时的追问和提问——每个人……那个房间里可能有一百人,随时准备回答关于自己业务的问题。而且这会产生级联效应——不仅仅是我或者在场的领导者被当场提问并需要做好准备,之后我也会对我的团队做同样的事,以此类推。所以我也在努力在我的团队中培养这些肌肉,让他们能够带来自己的洞察、理解和行动,形成这种级联效应。所以这是一种机制,而机制是 Amazon 另一个非常重要的概念,它能引导出所有这些优秀的行为。
Ian McAllister (00:44:17): 我认为很多这样的机制都源自 Jeff Wilke,或者他创造了一种环境,让这些机制在整个组织中得以开发并传播开来。所以这是其中一点——那种运营思维和严谨性:作为产品领导者,不仅仅关乎构建新东西,还关乎你如何运营你已经构建的东西。如果你真的关注你所运营的产品,它会给你灵感——你可以加倍投入某些表现良好的方向,或者防止某些不好的事情发生。我认为这是 Amazon 能够实现如此规模的一个非常关键的原因。另一件我非常敬佩 Jeff Wilke 的地方——我觉得 Doug Herrington 也有这种特质——是那种略带严厉的爱。我认为这很重要,他们两个都不是混蛋,但有时候,尤其是 Wilke,你需要得到那种——就像你爸爸可能会隔着眼镜看你一眼的那种眼神——“嘿。”
Ian McAllister (00:45:15): 所以我觉得大概就是那种氛围。专业的、尊重的,但有时候每个人都需要一点鞭策,我觉得这就是其中之一,但这反而让你对他更加尊敬。那种非常领导者的行为方式,我非常尊敬并努力去效仿,努力做同样的事,因为我太尊敬他这种做法了。最后关于 Wilke 我想提的一个特质是教学。他不仅仅是说这是正确的事或者这是我在会议上的决定,而是教学背后的原因、模式,引导他做出判断的心智模型。我觉得他非常擅长教学,会花一个片刻。也许在会议中只需要 10 秒钟就能完成一次教学。
Ian McAllister (00:46:01): 而这在我的职业生涯中不同阶段曾被遗忘,尤其是当你经验越来越多,你知道正确的决定是什么,你知道你想要什么——那可能是对的——但我觉得如果你能把它抽象到一定程度去教授这个道理,效果会更持久。因为那样那个人就有可能学到这个教训,并把它应用到未来很多场景中,也会更理解背后的原因。而且这有时候能帮助他们更好地做到”反对并承诺”,而不只是被告知一个指令性的建议。
backward working 最常见的错误
Lenny (00:46:33): 听起来从这两位身上学习一定是一段非凡的经历。感谢分享这些。我想聊聊 backward working 的内容。我觉得我们已经谈了很多这个话题。我们在其他播客里也和其他嘉宾讨论过。我觉得大家已经理解了基本概念。对,Amazon 做 backward working。他们会写一篇新闻稿。可能还有一个六页文档什么的。但我觉得没有很多人讲”实际怎么做这件事”。所以稍微花点时间在这上面——当你看到团队尝试做 backward working,说”我们来做 backward working,我们要像 Amazon 一样”——你觉得他们在实际实施这个想法时做错了什么?你发现最常见的错误是什么?
Ian McAllister (00:47:11): backward working 的核心就是关于问题——从问题出发,对问题着迷,由问题引导你进入解决方案。所以做错的团队就是没有做到这一点。他们没有 backward working。他们有想要构建的东西。这些东西看起来很相似。这两种技术或者别的什么。我们可以把它们组合起来然后做这个。但如果你说的是”我们可以”,而且这不是基于某个客户或客户的问题,那你就不是在做 backward working。然后你可能在用”backward working 流程”,但你已经有了解决方案。所以你是在解决方案之后补充问题。你在回溯性地加上问题,回溯性地加上客户。所以我认为第一号错误就是他们没有理解真正从你要解决的问题出发并忠实于从问题 backward working 的重要性。
一个没有真正 backward working 的案例
Ian McAllister (00:48:03): 我刚加入 Amazon 社区团队的时候,我们有一块用社区内容做自动化推荐的业务,那是我们的核心工作——推动这块业务增长。但当时有一个 Jeff 的想法,团队特别兴奋。因为我觉得在某个会议上他大概画了个草图之类的。所以大家已经有了很大的势头要去建这个东西,实际上这是一个 Jeff 项目,但我当时应该意识到的,事后回顾确实如此——因为这个项目的名字叫 ASIN to ASIN linking。ASIN 是 Amazon 上产品的标识符。所以这本质上不是一个 backward working 的思路——如果你能通过主观属性把产品链接起来,然后围绕它做一个功能,让客户对这些东西投票,然后就会变成一种……
Ian McAllister (00:48:50): 所以从精神上讲,它真的不是 backward working。但团队都很兴奋,所以我们最终还是写了新闻稿,也做了这件事。结果并不成功,后来我们把它关掉了。我从中学习了很多,那是我在 Amazon 的头一两年,关于使用 backward working 流程但实际上并没有真正 backward working。所以现在,如果我在评审一份 backward working 新闻稿,或者甚至是跟人讨论一个新项目,我的大脑已经无法处理任何信息,除非我先把注意力放在问题和客户上。然后当我们开始讨论这些之后,我才能真正参与进来,切实地 backward working,说,好的,我们怎么解决这个问题?最优雅的解决方式是什么?或者如果有三个问题,第一、第二、第三分别是什么?所以这可能是我的一种缺陷——我没有办法不先从问题 backward working 就处理信息。但我发现当人们这样做的时候,确实很有帮助。
backward working 的核心不是新闻稿
Lenny (00:49:47): 当人们谈论 backward working 的时候,你描述的方式很有意思——重点是先从问题出发,我觉得一般产品团队也会试图这样做。他们的一页纸、PRD 里面通常都有,这是我们正在解决的问题,这是为什么它是个问题,这是我们怎么考虑……这是 backward working 的核心吗?我一直以为核心是发布声明和新闻稿那套东西,也许还有 FAQ。在 Uber 和其他公司、Airbnb,你现在每个项目都真的会那样做吗?
Ian McAllister (00:50:17): 它包含两个部分。一个是 backward working 的概念——从你想要达成的目标反向推导。我和我的团队现在依然绝对在做这件事。我们要为业务达成什么,或者为客户达成什么,我们就从这里开始。如果他们有一个问题正在影响他们的盈利能力——如果是企业客户的话——或者一个客户试图达成某个目标,那就从那个问题出发。这不同于 backward working 机制,也就是新闻稿和 FAQ,那是 Amazon 用来强制执行 backward working 的机制,我认为它是有效的。我尝试教授过它,也写过一些帖子,附带模板之类的东西,因为它是一个很好的起点——新闻稿里有一段专门讲问题,这就是你要写的部分。
Ian McAllister (00:51:00): 然后你写解决方案段落,然后是客户引言。然后是事实判断(fact)——是否存在一个合理的成功计划?所以如果你和你的团队还没有 backward working 的肌肉记忆,那这是一个很好的尝试方式。但它不是唯一能做到这一点的机制。最终,如果你做得足够多,建立起 backward working 的肌肉记忆,你就可以用任何形式来做,不管是 PRD 里的某些内容还是其他方式。但关键是你不要想”我们能建什么”,而是想问题是什么,然后想解决那个问题的方案。
Lenny (00:51:35): 明白了。所以新闻稿不是核心。它更像是一个技巧,引导你去思考你要解决的问题。而不是你怎么发布它。
Ian McAllister (00:51:42): 对。
在不同公司推行 backward working
Lenny (00:51:43): 有意思。我从来没有这样想过。所以当你在 Amazon 以外的地方做这个过程,比如你是一个产品负责人,想要改善团队思考产品的方式——你具体建议他们怎么做?是写下来”这是我们要解决的问题”吗?还有更多的吗?你会怎么建议?
Ian McAllister (00:52:02): 如果真的是一张白纸,你当然可以像 Amazon 那样使用 backward working 流程,写内部新闻稿,然后是事实判断等等。这没问题。但很多公司有不同的做事方式。有些公司是典型的幻灯片文化,做演示文稿之类的。所以作为产品负责人,你可以考虑你怎么和你的团队做,怎么向上或跨部门做。你可能有权在你的团队里使用任何流程。我在一些公司这样做过——使用文档,如果团队支持,并且他们认识到其中的价值,比如”哦,这个确实好,这是一种很好的把事情写下来的方式,能有更好的信息内容和更深入的讨论”——人们往往会发现,相比一张只有几个要点 bullet 的幻灯片,这种方式好得多。然后你就可以培养那块肌肉记忆。
Ian McAllister (00:52:54): 我发现这是一个很好的教学方式,可以用它来更深入地探讨产品。但取决于你所在的组织,去训练你的高层领导使用你想要用的流程,可能行不通。所以那就变成寻找机会去尝试一些东西,说”你愿意试试这种方式吗?“用文档评审代替其他的评审方式。这跟 backward working 本身有点分开,但我觉得你就是要承认你所处的环境。而且,除非组织有一个特定的格式来做这件事——如果有的话,你可能就需要用它。不同的领导处理信息的方式不同。你可能发现一种格式对你的领导有效,但另一种格式对更广泛地教育组织更有效。但这非常因公司而异。所以不管我可能想怎么做,我得认识到我对团队的影响力更大,而向上或跨部门的影响力更小。
Lenny (00:53:51): 你有没有一个持续使用的模板?就是如何定义问题、如何定义所有其他要素的那种——你有没有发布过?
Ian McAllister (00:54:00): 我分享过一些帖子,肯定是在 LinkedIn 上,也许也应该放到 newsletter 上——我的 newsletter 上有一个 backward working 模板,还有一些关于如何做这个流程的帖子,或者关于 Amazon 如何做这个流程的技巧。所以我会确保把这些也放到我的 newsletter 上。模板是免费的。显然任何人都可以复制和拿走使用。
Lenny (00:54:19): 太好了。我们会在节目备注里附上链接。这次录完之后一定要发给我。我还想问,Amazon 是不是在每个产品上都做 backward working?你是否建议在每个功能和产品上都做 backward working?
Ian McAllister (00:54:33): 我觉得在某个规模以下,做这个流程可能没什么意义,因为它有一点额外开销。但如果是一个新产品,那绝对要做。我确信 Amazon 内部也有一些没有使用这个流程的情况,但总体来说这就是标准做法,而且通常会强制要求你必须做一次 backward working 评审。理想情况下,这应该在项目启动时进行,但有时也会后来才补上。我认为不管你用不用这个机制,这都是一件好事。再说一次,这是一个很好的模板,如果你有灵活性,可以以此为起点来用。但我觉得你也可以只是秉持这个精神,努力忠实于 backward working 的核心——从你为客户做什么、解决什么问题出发去倒推。这才是最重要的。模板只是一个帮助确保这件事发生的机制。
Lenny (00:55:18): 明白了。你刚才提到了评审,那是什么?backward working 评审?
Ian McAllister (00:55:22): 那就是一个和领导层或其他同事开会的评审,审视概念、审视新闻稿、审视 FAQ 并提问。在某些情况下,这就是批准项目的关卡。我和 Bezos 之间就是这样——在我们去组建团队、启动 Amazon Smile 之前,我会就不同概念做这些评审,而那一个是我们亮了绿灯的。这往往是常态。同时这也是一种很好的方式,让其他人了解你想要达成什么,让他们理解客户问题和解决方案。FAQ 则是一个完全不同的概念——它关乎的是一个可行的成功计划。还有一件事,我有一次机会和 Jeff Bezos 一起吃午饭,大概是在 2008 年左右。我问他:“你投资新事物的标准是什么?”
Ian McAllister (00:56:09): 他说:“三件事。第一,是不是一个大创意?第二,是不是我们应该做的事?“所以假设你有一个想法,比如你有一种从页岩中提取石油的新方法,是不是大创意?是的,可能是一个大创意。但 Amazon 应该做这件事吗?可能不应该。第三个检验,有没有一个可行的成功计划?三件事缺一不可。我认为 backward working 流程中的 FAQ 部分,就是早期阶段对这个项目是否有计划的一个可行性检验。因为你可以有一份内部新闻稿或大创意,或一个关于解决方案的大创意,但 FAQ 基本上是在说:好吧,我已经考虑过内部组件、财务、关键技术障碍等等了。所以这部分不太被写到,就是怎么做 FAQ,但我认为这是另一种建立信任的方式——表明你在产品当前阶段已经想得足够周全,值得获得资源或值得继续推进。
Lenny (00:57:03): 太棒了。我觉得听这个节目的大多数产品经理会说:“我一直从问题出发,我一直是问题导向的,所以我就是在 backward working。我没问题。“那些表明”不,你并没有”的信号呢?你以为自己在做,但可能做得不好。有没有什么迹象说明你其实没有正确地做这件事?
Ian McAllister (00:57:23): 我看到的最常见的一个信号是,当他们谈论某个东西时,说的是——食橱里有不同的食材,我们有这些原料,可以把它们组合起来,把这两样东西加在一起就能做出一道菜。所以可能是一项技术,可能是一个服务,可能是两样不同的东西,或者积木块就在那里,如果你把这两个积木块组合起来,就能产生某个东西。但这不真的是 backward working。公司拥有这些技术或资产确实可能带来一些杠杆效应或好处,但对我来说,这往往是第一步——这两样东西看起来很相似,我们把它们组合在一起,新东西一切都很好。
Ian McAllister (00:58:09): 所以如果你开始谈论这些东西或技术,我认为这很可能说明你并没有真正在做 backward working。相反的情况是,如果有一个客户问题,即使在解决方案出现之前就让人觉得很有说服力——是的,那确实很有说服力。就像每一个创业公司一样,可能很多路演都是这样的:有一个庞大的受众群体和一个令人痛苦的问题,这就是止痛药和维生素的区别,然后我们有一种新颖的方式来解决这个问题。这才是 backward working 的样子。但更常见的是,尤其是在大公司里,你会有各种各样的想法,因为你食橱里有更多的食材,可以用各种方式组合它们并试图喂给某个人,但这可能不是 backward working。
Lenny (00:58:56): 很好。我们聊了差不多一个小时了,我想放你走了。在我们进入非常令人兴奋的快问快答环节之前,关于我们聊过的内容,你还有什么想补充的吗?
Ian McAllister (00:59:06): 让我想想。没有了。我觉得我们涵盖了很多好的内容。很有趣,但没有什么特别要补充的。
Lenny (00:59:11): 好的,太好了。那么我们到了非常令人兴奋的快问快答环节。这里有六个问题,会非常快速简单。想到什么就说什么,我们会比较快地过一遍。可以吗?
Ian McAllister (00:59:22): 好的,来吧。
Lenny (00:59:23): 来吧。你最常推荐给别人的两三本书是什么?
Ian McAllister (00:59:28): 我会说 37 Signals 的《Getting Real》,特别是其中关于核心设计(epicenter design)的那一章。我分享过很多很多次。你可以附上链接。这绝对是我分享最多的东西。休闲阅读的话,Hugh Howey 的《The Wool》三部曲,他可能是我最喜欢的作者,一个很棒的系列。学习方面,最近一本我觉得超级有趣的是 Vaclav Smil 的《Energy and Civilization》。所以它可能不在畅销榜上,但我觉得很有意思。
快问快答:播客与影视
Lenny (00:59:55): 除了这个节目之外,你最喜欢的播客是什么?
Ian McAllister (00:59:59): 我觉得《How I Built This》很有意思,可以拆解那些有趣的商业和产品是怎么诞生的。然后因为工作的关系,《EV News Daily》是关于电动汽车领域动态的每日简报。所以每天花五分钟了解一下最新情况,是非常好的时间利用。
Lenny (01:00:18): 非常小众。我喜欢。你最近看过最喜欢的电影或电视剧是什么?
Ian McAllister (01:00:24): 《Yellowstone》。这绝对是我的最爱。等不及下一季了。蒙大拿是我的快乐之地,不过我可能正是剧里那些人抱怨的那类人,所以有点讽刺。电影的话应该是《Everything Everywhere All At Once》。我喜欢不可预测的电影,我觉得那部非常有创意。
Lenny (01:00:40): 《Yellowstone》里死了那么多人让我很震惊。那个剧到处都是谋杀。我没料到一个关于牧场的剧会是这样。
Ian McAllister (01:00:50): 环境很严酷。
Lenny (01:00:51): 确实很严酷。特别是如果你惹了 Dutton 家的人的话。下一个问题。你最喜欢问的面试问题是什么。
Ian McAllister (01:00:58): 当我出其不意的时候,我会问人们:在你职业生涯的这个阶段,你对自己有什么了解?你和其他人有什么不同?没有人对此有准备。
Lenny (01:01:06): 你在他们的回答中寻找什么?
Ian McAllister (01:01:08): 不好说。没有什么特定的东西,也没有标准答案,这可能有点不太公平,但就是想看看他们有没有一点自我反思,是否了解自己的优势,有没有足够的自我认知来知道自己的与众不同之处在哪里,并能把这种独特性加以利用,从而成为一个更好的产品经理或工程师什么的。所以大概就是我在寻找的东西,但没有固定答案。更多就是想打他们一个措手不及。
Lenny (01:01:32): 有意思。你最喜欢的 app 是什么。
Ian McAllister (01:01:35): 答案可能不太出人意料,但说实话,YouTube。它简直是世界第八大奇迹。每天只要我想学什么新东西,都会被它惊艳到。几年前一个夏天我休了段时间假,基本就是通过它自学了木工,做了一个厨房和其他一些东西。它持续不断地成为这样一个资源和宝库,帮助我成长、学习任何东西。
Lenny (01:01:58): 我想现在可能就有人在 YouTube 上看这个。
Ian McAllister (01:02:01): 没错。
Lenny (01:02:02): 我刚读到过一个故事,一个奥运标枪运动员就是看 YouTube 学的标枪。他好像在非洲某个地方,周围没有教练,就看另一个标枪选手在网上分享教学视频,然后变得极其厉害。太疯狂了。
Ian McAllister (01:02:18): 而且我年纪大了,我小时候可没这些。我还记得去图书馆、给杂志背面地址写信索取资料手册什么的。那时候学东西没那么容易。互联网显然是一个巨大的资源,现在也是,但 YouTube 更进一步,让你能看到别人实际操作的过程。看别人实际动手演示也很有意思。总之,我是 YouTube 的粉丝。
最敬佩的思想领袖
Lenny (01:02:40): 最后一个问题。业界你最敬佩谁作为思想领袖,你最仰慕的人是谁?
Ian McAllister (01:02:46): 我会说是 Gibson Biddle。他拥有极为丰富的产品经验,我认为非常有价值。我敬佩他愿意花时间分享这些经验。他不是非分享不可,但他就是愿意去做。而且他也是一个非常出色的沟通者,你能看出来他会在意衡量自己演讲的 [录音不清 01:03:02] 等等方面。他在整个职业生涯中持续投入,成为了一名优秀的沟通者。所以我认为他对我、对其他人来说都是很好的榜样。
Lenny (01:03:11): 这个人太厉害了。我很高兴我们已经在播客上请过他了。我希望每位被提到这个问题答案的人最终都能上我们的播客。所以又勾掉一个。我也很喜欢 Gibson。他有一个很棒的 newsletter,askgibbs.substack.com,应该是这个。Ian,非常感谢你来参加节目。太棒了。真的很感谢你和我们分享这些智慧。最后两个问题。如果大家想联系你、了解更多,在网上哪里可以找到你?听众有什么方式可以帮到你?
在哪里找到 Ian
Ian McAllister (01:03:38): Twitter 是个好地方。我的账号是 IanMcAll,I-A-N-M-C-A-L-L。另外我也开始写了一个 newsletter。说实话更新不太频繁,我有很多好的想法和 intentions,就是还没来得及写。地址是 ianmcallister.substack.com。欢迎通过这个来联系我,也欢迎订阅,如果你有想看的文章主题或问题可以在 Twitter 上找我。如果一条推文能回答的我就直接回,不行的话我会加到写作队列里。最后,Lenny,谢谢你的邀请。我们之前聊过写作或者做其他事情的话题,这些事的价值就在于和人们建立连接。所以这次能和你重新联系上就很棒。而任何能让我和世界上新的人产生联系的机会,都是好事。
Lenny (01:04:25): 太好了。我们最初就是因为那篇文章才认识的,所以大概十年后又兜回来了。谢谢,Ian。
Ian McAllister (01:04:32): 好的。谢谢 Lenny。
Lenny (01:04:34): 非常感谢大家的收听。如果你觉得这期节目有价值,可以在 Apple Podcasts、Spotify 或你喜欢的播客 app 上订阅本节目。另外,也请考虑给我们评分或写评论,这真的能帮助更多听众找到这个播客。你可以在 lennyspodcast.com 找到所有往期节目或了解更多关于本节目的信息。下期再见。
术语表
| 原文 | 中文 |
|---|---|
| Amazon Smile | Amazon Smile(Amazon 的公益购物项目) |
| ASIN | ASIN(Amazon Standard Identification Number,Amazon 产品标识符) |
| Berkshire Hathaway | Berkshire Hathaway |
| book of business | 业务簿 |
| cascading effect | 级联效应 |
| Consumer Business Review | 消费者业务评审 |
| copy | 文案 |
| disagree and commit | 反对并承诺(Amazon 领导力原则之一) |
| Doug Herrington | Doug Herrington(Amazon 消费者业务负责人) |
| driven by impact | driven by impact(以影响力驱动) |
| earn trust | earn trust(Amazon 领导力原则之一) |
| fitness function | 适应度函数 |
| Gibson Biddle | Gibson Biddle(曾任 Netflix/Chegg 产品副总裁,产品领域知名博主) |
| gifting business | 礼品业务 |
| GM | GM(General Manager,总经理) |
| Goldilocks zone | 金发姑娘区间 |
| GPM | GPM(Group Product Manager,高级产品经理) |
| intentions | intentions(此处 Ian 口语中夹杂使用,指”好的出发点/计划”) |
| Kim Rackmiller | Kim Rackmiller(Ian 在 Amazon 的上级,全球发现业务 SVP) |
| mechanism | 机制 |
| newsletter | newsletter(通讯/邮件订阅刊物) |
| one pager | 一页纸 |
| Operator’s Manual | Operator’s Manual(Ian 写的一篇产品经理操作指南帖) |
| PM | 产品经理 |
| PRD | PRD(Product Requirements Document,产品需求文档) |
| press release | 新闻稿 |
| program manager | 项目管理(微软岗位,近似产品经理角色) |
| roadmap | 路线图 |
| Russell | Russell(Ian 的第一任老板) |
| Sarah | Sarah(Ian 的妻子,AWS 产品经理) |
| six pager | 六页文档 |
| skip level | 隔级上级 |
| think big | think big(Amazon 领导力原则之一) |
| Thomas | Thomas(Ian 在微软的产品单元经理) |
| trade-offs | 权衡 |
| Warren Buffett | Warren Buffett |
| WBR (Weekly Business Review) | 每周业务评审 |
| weasel words | 模糊措辞 |
| working backwards | backward working(流程) |
此文档由 AI 分片翻译(translate_long_document)