顶尖 1% 产品经理练什么，以及逆向工作法真正在逆向什么

Lenny introduces Ian McAllister as the author of the classic post on what separates a top 1% PM from a top 10% PM, and says it shaped his own early focus as a new product manager. McAllister says he never expected that reach. He was reading Quora for fun, picking questions in a middle zone that were neither too abstract nor too specific, and answering them mainly to structure his own thoughts.

A related post described Amazon's working backwards process, which he says was not his invention but something he used and described. Writing more about product and people management let him connect with people in the startup community at a time when Amazon was a fairly private, heads-down culture. Those relationships eventually led him to Airbnb, where he first met Lenny's team.

Lenny adds that writing often starts as a way to collect your own thoughts, and cites the saying that you do not know what you think until you write it down. McAllister agrees that writing for an external audience pushed him to be compact and organized, and that business writing at Amazon taught him that you must be a clear thinker to be a clear communicator.

McAllister's path ran through finance and economics, marketing in the beer industry, a move to Tokyo where he taught himself software development, a developer role at a startup and a midsize company, and a program manager job at Microsoft. He joined Amazon in 2006 and spent 12 years there across retail and conversion, traffic and loyalty where he created Amazon Smile, Alexa International, and delivery experience. He now leads product and tech for vehicles at Uber, covering fleet tools, electrification and a path for autonomous vehicles.

Asked to run through his list, he names think big, communicate, simplify, prioritize, forecasting and measuring, execution, understanding technical trade-offs, understanding good design and writing effective copy. Forecasting matters, he says, because it separates product managers from consultants: you forecast, execute, then measure and validate, which builds your instincts.

When he refreshed the post in his newsletter he added earning trust, digging for data, pushing back effectively, adapting to change and being driven by impact rather than promotion. Lenny notes the post itself says he has never met a top 1% PM who does all of these things.

For new product managers, McAllister picks communicate, prioritize and execute as the core building blocks. He recalls being asked at Microsoft when something would ship and giving a long explanation without a date. At Amazon, a demanding boss prompted a collection of best practices, which he later extended into a post called the Operator's Manual: avoid weasel words, answer first and then explain, and own your problems.

His tactical advice is to answer a "when" question with a date, use numbers, and grade yourself after a document review, meeting or even an elevator answer. Lenny suggests also asking your manager how you could have communicated better. McAllister says that without this skill it is unlikely you will go far, however many of the other 150 skills you have.

On prioritization, he says the dimensions are many: which themes go on a roadmap, which projects within them, in what sequence, how much to build, and how you spend your own time. He claims a PM with a great innate ability here will produce 5x the impact. His own early success at Amazon, he says, came from hunger for impact and focusing the team on the projects with the greatest leverage on a business metric.

Execution, in his view, means molding what you want to build into a compact, high-impact package, and it depends on designers, data scientists and especially engineers. PMs have some ownership of how well that team is resourced and improving each sprint, because it affects their reputation for delivering. Lenny observes that the remaining list items can matter less in year one.

For senior PMs, communication still tops the list because the stakes rise. McAllister then adds thinking big, earning trust and being driven by impact. Citing a phrase he links to Warren Buffett's Berkshire letters about hunting for bigger elephants, he suggests asking at the start whether an idea could be bigger, and starting small only with a bigger vision in mind.

He calls trust the currency of a product leader. If leadership does not trust you to use resources well, you will not get more, and trust is built by repeatedly setting and meeting expectations, calling your shots and hitting them. Telling the truth, launching what you said when you said, and owning mistakes build it; evasiveness and repeating mistakes destroy it.

On impact, he says that if you forget politics and promotion and wake up trying to have the biggest impact you can, that guides your roadmap and your day. At Amazon he never discussed promotion with his manager, and the promotions came. Expectations rise with seniority: for a junior PM impact is a nice to have, while later it is how you are evaluated.

Lenny suggests early-career PMs can benefit from landing on a high-impact project. McAllister agrees that working on something that drives the business tends to help, and that who you work for matters, since a leader strong at prioritizing is a better teacher. Thinking big also means taking a wide view of what success requires, owning marketing or other functions until someone else does rather than wearing product-only blinders.

McAllister says he did not recognize the importance of trust until the last couple of years. Mentoring his wife, a product manager at AWS, he saw trust act as her superpower, which made him reflect on what he could have done better. Beyond honesty, he says, it means understanding another person's goals and their organization's goals and investing the time to reach alignment, rather than being bullheaded as he was earlier in his career.

His example is building the customer support technology platform at Airbnb. He focused on strong analytics and Amazon-style prioritization, aiming to keep quality high while reducing costs as the business scaled. But he did not partner as deeply as he should have with the customer support leadership, and it felt like alignment when it was not fully so.

The lesson, he says, is that even if your approach is right, it may not be executed well without the relationships and support of those who must carry it out. Building trust mitigates that risk. He frames it as continuous improvement: not dwelling on getting things wrong, but asking what could have gone better in every role, project and communication.

McAllister says he stayed 12 years because Amazon, which he calls something of a crucible, clicked with his structured thinking: pick one metric or fitness function and make it go up and to the right. He felt he was learning constantly, from reading documents, from weekly business reviews and from smart, driven colleagues. After a stint at Airbnb that involved a weekly trip between Seattle and San Francisco, he returned to Amazon.

He describes Jeff Bezos as encouraging, not the blow-up figure of rumor. While searching for what became Amazon Smile, he reviewed options with Bezos every couple of months, and Bezos told him the process need not be efficient because efficiency requires knowing where you are going. Once, McAllister brought a press release with no problem paragraph, and Bezos remarked that perhaps there was not really a problem.

He learned more from Jeff Wilke, whom he calls the consummate operator and who shaped the weekly business review. In that meeting leaders had to explain variances in their metrics, which cascaded down into teams that were prepared to bring insights and actions. He also credits Wilke with the operational point that product leadership is about how well you run what you have built, as well as building new things.

McAllister also admired Wilke's tough love, which was professional and respectful, and above all his teaching: explaining the why and the mental model rather than just the decision. He says he forgets this at times, but it has a more lasting effect and helps people disagree and commit.

Asked about the most common mistake teams make when copying Amazon, McAllister says they do not truly start from the problem. They have something they want to build, such as combining two technologies, and then add the customer problem afterward, which he calls retrofitting. Using the working backwards process without actually working backwards defeats the point.

He tells of an early Amazon project internally called ASIN to ASIN linking, which grew from an idea Bezos had sketched and that a team was excited about. The idea was to link products by subjective attributes and let customers vote. The team wrote the press release and built it, but it was not grounded in a customer problem and it was eventually shut down.

Today, he says, he cannot process a pitch until the problem and customer are clear; only then can he work backwards on how best to solve it, or which of several problems is number one. A telltale sign of getting it wrong is the pantry metaphor: we have these ingredients, so let's put them together. A compelling customer problem that feels strong before any solution is the opposite signal.

McAllister separates the concept of working backwards, from the goal or customer problem, from the working backwards mechanism of the press release and FAQ that Amazon used to enforce it. The release has a problem paragraph, a solution paragraph and a customer quote, and the FAQ asks whether there is a legitimate plan to succeed. Once you have built the muscle, he says, you can do it in a PRD or another format.

Outside Amazon, he says, you should recognize your environment. In a slide-culture company you may still have latitude to use documents with your own team, and you can ask senior leaders whether they are open to a document review in place of slides. He notes you often have more leverage down with your team than up or across, and if the organization has a required format, you should use it. He says his template is free and will be on his newsletter.

He says there is a scale below which the overhead is not worth it, but for any new product the process makes sense. A working backwards review is a meeting with leadership to review the press release and FAQ, and at Amazon it was often the gate for approval, as with Amazon Smile. He also recalls asking Bezos over lunch around 2008 for his criteria for investing: a big idea, something Amazon should be doing, and a legitimate plan to succeed, which the FAQ tests early.

McAllister recommends Getting Real by 37signals, in particular its epicenter design chapter, Hugh Howey's Wool trilogy for fun, and Vaclav Smil's Energy and Civilization for learning. He likes the podcast How I Built This and a daily digest called EV News Daily, and enjoys Yellowstone and the film Everything Everywhere All at Once.

His unexpected interview question is what the candidate has learned about themselves at this stage in their career and how they differ from others. There is no right answer; he looks for self-reflection and awareness of strengths. His favorite app is YouTube, from which he taught himself woodworking and built a kitchen one summer.

The thought leader he most respects is Gibson Biddle, for sharing his product experience and investing in being a great communicator. Listeners can find McAllister on Twitter and through his Substack newsletter, and he says connecting with people through writing is what he values most.