从客户倒推：亚马逊如何把客户执念做成可重复的操作系统

Bill Carr, who spent 15 years at Amazon and later co-wrote Working Backwards with Colin Bryar, says many people know Amazon for products like the Kindle, AWS, Alexa and Prime but not that it was equally focused on process innovation. In his telling, they often stood on others' shoulders, and the book exists so readers can stand on Amazon's in turn. Host Lenny Rachitsky notes that few companies have coined so many shareable ways of working.

Carr says the products and nearly all the processes emerged in a narrow window from 2003 to 2007, as Amazon moved from a hypergrowth bookstore to a complex company with a marketplace, third-party web services and many countries. At that point the CEO could no longer sit in every meeting or hire every person, so a system was needed. Jeff Bezos, a computer science graduate and former quant, approached it like a scientist, forming hypotheses, testing them and iterating.

Not every experiment survived. Carr describes the "fitness function," a weighted index of four to six metrics meant to measure each team. After several months to a year they realized that a compound metric obscures which actions are driving results, so they broke metrics out individually, and Carr now discourages any compound metric. Lenny says he made the same mistake with six rotating metrics.

Carr explains that in large companies, departments compete for a central pool of engineering resources, and the usual answer is heavy collaborative planning. Amazon went the other way, wanting ownership, speed and agility, by creating stand-alone teams under one leader with dedicated cross-functional resources. This was a move from a project orientation, such as a six-month search-page project, to a program orientation, where a search team always works on search with controllable metrics like the click-through on the top three results or page load time.

The model needed groundwork. Amazon first had to break a monolithic code base into services with well-documented APIs, so teams could own their code. Senior management then refereed resource allocation once or a few times a year rather than every roadmap item. Carr stresses that the leader and team still write a plan that is deeply reviewed by the vice president, senior vice president or the S-Team before they run; ownership is not freedom from scrutiny.

The cost is functional excellence. Carr himself, a marketing generalist with an MBA, ran software engineers in 2004 and could not review code or coach craft. Amazon's countermeasures kept core services and standards under a central engineering leader, Rick Dalzell, who set company-wide norms for code review, interviewing and promotion. Senior people also took on extra subject-matter jobs, such as sitting on promotion panels or reviewing code for other teams.

Carr calls this the least understood of Amazon's original ten leadership principles because it is the most nuanced. The obligation to "have backbone" and disagree is about bringing new information or a different view, much like a king's court advising the ruler, and it goes up the chain if an important issue is being ignored. Citing Peter Drucker, he says good decisions come from first understanding all the points of view.

The stopping point comes when the leader shows they understand the objection and have weighed it. At that point the disagreer should commit, and ideally the commitment rests on real understanding so they can explain the reasoning to their own organization. Saying "I still think it's wrong, but I'm committed" is, in his words, not actual commitment.

When he still disagreed with Bezos, Carr focused on the kernel of why Bezos wanted to pursue an idea and tried to expand it into something viable, advice he credits to manager Steve Kessel. He adds that data rarely makes the decision for you, since you can frame a dataset to support or oppose almost anything. That is why "leaders are right a lot" is about sound judgment built mostly from experience, including being wrong.

The book's title comes from the customer-obsession leadership principle and from the PR/FAQ process created in the same window. Most companies start from constraints or from goals like increasing revenue, Carr says, whereas Amazon took it as an "article of faith" that serving customers well would produce sales, active customers, share price and free cash flow. Working backwards is strictly about customer needs, and even cost reduction counts only if it is passed on as lower prices.

In practice a team writes a press release for the feature as if launching it, which must read as something a customer would truly need. It has to define who the customer is, what the specific problem is and what the solution will be. Carr says the first two are hardest: "all restaurants" is not a customer, and ideally the problem is quantified and one people would pay to solve.

Asked whether press releases are outdated, Carr says it is not a real press release and could be called a customer problem-solution statement. The heart is the short description, the problem statement and the solution statement, though the headline and hypothetical launch date add useful cues. It should be factual and data-rich, not hyperbolic, and a template is available at workingbackwards.com.

The PR/FAQ is reviewed in concentric circles, starting with one author, then a small group, then wider groups, up to the CEO in a large company. Many documents die along the way, either because the author sees the idea is weak once written down or because a manager's feedback sinks it. Carr's example is that of 100 PR/FAQs in a year, perhaps 20 reach the CEO.

He wants a product funnel, not a tunnel in which everything entering comes out the other side. He tells leaders to think like venture capitalists, since engineering is the most precious resource and Amazon left many good PR/FAQs unshipped because better ones existed. Lenny sums it up as a way to stop "stupid" things from happening, and Carr adds that it separates the decision about what to build from the process of shipping it well.

To the "thinking-to-doing gap," Carr says companies get stuck debating big ideas that were never fleshed out, so decisions go to politics or top-down will. They also often lack structure to hand a good idea to an owner to investigate and then build. As he grew more senior, he could either set an idea aside or dedicate a person or team to it, otherwise it would never happen.

Carr traces input metrics to the early 2000s, when Amazon missed quarterly growth plans and scrambled with last-minute promotions, price cuts and extra emails. Those fire drills mostly pulled revenue forward and distracted people from work that mattered to customers. Around then Bezos and the S-Team read *Good to Great*, which Carr calls the most influential management book for the company, and it helped them codify the growth flywheel.

The flywheel's inputs were broad selection, a great customer experience, such as ease of finding, buying and receiving, low prices, many merchants and lower costs. Carr argues nobody will ever prefer fewer items, higher prices or slower delivery, so improving those inputs is the path to winning. Around 2007 or 2008 the S-Team counted a goal list of about 500 items and only 10 had a financial metric.

To find good input metrics, map the end-to-end customer experience and ask how you measure the speed, quality and ease of each step. A good input is something you control, which usually touches the customer; which ones are most causal is found by measuring, observing and improving. The approach borrows from Six Sigma's define-measure-analyze-improve-control cycle, and Amazon had to refine its selection metric after measuring it wrongly for years.

Asked about the Fire Phone, Carr says none of Amazon's tools gives you the answer; they just help decisions. His view is that the team started from a technology, 3D effects, and went looking for a problem, and he could not see how it improved discovering or playing music and video. When a product fails and execution was sound, he says, the first question to ask is what problem it solved.

Doubt is not a reliable signal either: many inside Amazon doubted the Kindle, and people laughed at his plan for original film and TV. Some launches failed on timing, such as the early-2000s Slots ad feature, and Bezos described an Echo-like kitchen puck in 2004 when the technology was a decade away. Public companies, he says, fear failure because of near-term financial pressure from Wall Street.

Two structural factors let Amazon tolerate risk. There were no performance bonuses and pay was tied to stock price, so moving from a big P&L to a zero-revenue digital media business did not cost him, and reviews weighed what people built. Second, the CEO took part personally, with Steve Kessel on digital media and Andy Jassy on AWS meeting regularly with Bezos, who could clear obstacles that large-company approvals would pose to a small new team.

The Bar Raiser process dates to 1999, when new engineering leaders were hiring managers who were hiring more managers, none yet steeped in Amazon's culture. Each was applying criteria from previous employers, and Carr warns that success at Microsoft does not guarantee success at Amazon, Google or Facebook. Amazon borrowed the idea from a Microsoft process called As Appropriate.

On each interview loop, one trained person from outside the hiring chain runs the debrief and technically holds veto power, which Carr says he never saw used in his 15 years. Later the loop gained objective criteria, the leadership principles, and behavioral interviewing. The Bar Raiser keeps discussion on those criteria and offsets the hiring manager's urgency bias to fill a role with the next warm body.

The hiring manager still makes the final decision, and Carr urges new managers to see the loop as help, since a wrong hire costs far more time. Being a Bar Raiser can take up to 10 hours of a week. To start, he advises piloting in one department with people who care about hiring, interview well and have high standards, and notes it is a good leadership opportunity for early-career staff.

Carr says companies do not need to turn into Amazon, and he could not make them if they wanted to. The aim is to consider adopting parts or all of these practices as one way to build scalable, repeatable processes. Many changes are profound, such as product development or hiring, and need CEO buy-in, though something like writing PR/FAQs can be piloted in a single group.

He warns that dipping a toe in will not work because a new process is hard at first and takes a few months to master. Carr and Bryar mainly advise companies with complexity, such as multiple product lines and well over $100 million in annual run rate, usually beginning with an assessment, then a prioritized plan, then hands-on coaching in team meetings.

In the lightning round, Carr recommends *Good to Great*, Drucker's *The Effective Executive* and the Steve Jobs biography. His favorite interview question asks for the candidate's most significant professional accomplishment, probed with the STAR method. His motto is "slow is smooth and smooth is fast": most people confuse speed with velocity, which also needs a clear destination.