Working Backwards Quotes
Working Backwards: Insights, Stories, and Secrets from Inside Amazon
by
Colin Bryar7,297 ratings, 4.20 average rating, 659 reviews
Open Preview
Working Backwards Quotes
Showing 91-120 of 292
“the Analyze stage is all about developing a comprehensive understanding of what drives your metrics. Until you know all the external factors that impact the process, it will be difficult to implement positive changes.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“We can’t tell you how many times we’ve heard people say, when talking about a recently launched Amazon initiative, “You can do that at Amazon because you don’t care about profits.” That simply isn’t true. Profits are just as important to Amazon as to any other major company. Other output metrics like weekly revenue, total customers, Prime subscribers, and (over the long term) stock price—or more accurately, free cash flow per share—matter very much to Amazon. Early detractors mistook Amazon’s emphasis on input metrics for a lack of interest in profits and pronounced the company doomed, only to be stunned by its growth over the ensuing years.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“Input metrics measure things that, done right, bring about the desired results in your output metrics.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“Donald Wheeler, in his book Understanding Variation, explains: Before you can improve any system … you must understand how the inputs affect the outputs of the system. You must be able to change the inputs (and possibly the system) in order to achieve the desired results. This will require a sustained effort, constancy of purpose, and an environment where continual improvement is the operating philosophy.2 Amazon takes this philosophy to heart, focusing most of its effort on leading indicators (we call these “controllable input metrics”) rather than lagging indicators (“output metrics”).”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“When the retail, operations, and finance teams began to construct the initial Amazon WBR, they turned to a well-known Six Sigma process improvement method called DMAIC, an acronym for Define-Measure-Analyze-Improve-Control.1 Should you decide to implement a Weekly Business Review for your business, we recommend following the DMAIC steps as well. The order of the steps matters. Progressing through this metrics life cycle in this order can prevent a lot of frustration and rework, allowing you to achieve your goals faster.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“Shortly after that holiday season we held a postmortem, out of which was born the Weekly Business Review (WBR). The purpose of the WBR was to provide a more comprehensive lens through which to see the business.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“share price is what Amazon calls an “output metric.” The CEO, and companies in general, have very little ability to directly control output metrics. What’s really important is to focus on the “controllable input metrics,” the activities you directly control, which ultimately affect output metrics such as share price.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“Generating and evaluating great ideas is the real benefit of the Working Backwards process.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“This process enables a product team and the company leadership to gain a thorough understanding of the opportunity and the constraints. Leadership and management are often about deciding what not to do rather than what to do. Bringing clarity to why you aren’t doing something is often as important as having clarity about what you are doing.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“The fact that most PR/FAQs don’t get approved is a feature, not a bug. Spending time up front to think through all the details of a product, and to determine—without committing precious software development resources—which products not to build, preserves your company’s resources to build products that will yield the highest impact for customers and your business.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“A common mistake among less-seasoned product managers is to not fully consider how third parties who have their own agendas and incentives will interact with their product idea, or what potential regulatory or legal issues might arise.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“Define-Measure-Analyze-Improve-Control.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“The PR/FAQ process creates a framework for rapidly iterating and incorporating feedback and reinforces a detailed, data-oriented, and fact-based method of decision-making. We found that it can be used to develop ideas and initiatives—a new compensation policy, for example—as well as products and services. Once your organization learns how to use this valuable tool, it is addicting. People start to use it for everything.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“But Kindle had not started out that way. In the early stages of its development—before we got started on the press release approach and when we were still using PowerPoint and Excel—we had not described a device that could do all these things from the customer perspective. We had focused on the technology challenges, business constraints, sales and financial projections, and marketing opportunities. We were working forward, trying to invent a product that would be good for Amazon, the company, not the customer. When we wrote a Kindle press release and started working backwards, everything changed. We focused instead on what would be great for customers. An excellent screen for a great reading experience. An ordering process that would make buying and downloading books easy. A huge selection of titles. Low prices. We would never have had the breakthroughs necessary to achieve that customer experience were it not for the press release process, which forced the team to invent multiple solutions to customer problems.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“The great revelation of this process was not any one of the product ideas. As we’ve described in chapter four, the breakthrough was the document itself. We had freed ourselves of the quantitative demands of Excel, the visual seduction of PowerPoint, and the distracting effect of personal performance. The idea had to be in the writing. Writing up our ideas was hard work. It required us to be thorough and precise. We had to describe features, pricing, how the service would work, why consumers would want it. Half-baked thinking was harder to disguise on the written page than in PowerPoint slides. It could not be glossed over through personal charm in the presentation.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“During the discussion stage, it’s also important that notes be taken on behalf of the entire audience, preferably by someone knowledgeable about the subject who is not the primary presenter.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“Some groups at Amazon go around the room, ask for high-level feedback, then pore over the document line by line. Other groups ask a single individual to give all their feedback on the entire document, then ask the next person in the audience to do the same. Just pick a method that works for you—there’s no single correct approach. Then the discussion begins, which essentially means that the audience members ask questions of the presenting team.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“We mentioned earlier the estimated reading speed of three minutes per page, which led to the six-page limit. If yours is a 30-minute meeting, a three-page narrative would therefore be more appropriate. Our goal has been to leave two-thirds of the meeting time for discussing what we’ve read.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“While Tufte’s essay wasn’t the sole impetus behind the move to narratives, it crystallized our thinking.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“an essay called “The Cognitive Style of PowerPoint: Pitching Out Corrupts Within,” by Edward Tufte, a Yale professor who is an authority on the visualization of information.1 Tufte identified in one sentence the problem we’d been experiencing: “As analysis becomes more causal, multivariate, comparative, evidence based, and resolution-intense,” he writes, “the more damaging the bullet list becomes.” That description fit our discussions at the S-Team meetings: complex, interconnected, requiring plenty of information to explore, with greater and greater consequences connected to decisions. Such analysis is not well served by a linear progression of slides that makes it difficult to refer one idea to another, sparsely worded bits of text that don’t fully express an idea, and visual effects that are more distracting than enlightening. Rather than making things clear and simple, PowerPoint can strip the discussion of important nuance. In our meetings, even when a presenter included supporting information in the notes or accompanying audio, the PowerPoint presentation was never enough.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“This journey is also a great example of another phrase you’ll hear at Amazon: be stubborn on the vision but flexible on the details.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“The other crucial component of the STL model is a separable, single-threaded team being run by a single-threaded leader like Tom. As Jeff Wilke explains, “Separable means almost as separable organizationally as APIs are for software. Single-threaded means they don’t work on anything else.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“What was originally known as a two-pizza team leader (2PTL) evolved into what is now known as a single-threaded leader (STL). The STL extends the basic model of separable teams to deliver their key benefits at any scale the project demands. Today, despite their initial success, few people at Amazon still talk about two-pizza teams.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“We found instead that two-pizza teams could also operate successfully in a matrix organization model, where each team member would have a solid-line reporting relationship to a functional manager who matched their job description—for example, director of software development or director of product management—and a dotted-line reporting relationship to their two-pizza manager. This meant that individual two-pizza team managers could lead successfully even without expertise in every single discipline required on their team. This functional matrix ultimately became the most common structure, though each two-pizza team still devised its own strategies for choosing and prioritizing its projects.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“One significant lesson became clear fairly early: each team started out with its own share of dependencies that would hold them back until eliminated, and eliminating the dependencies was hard work with little to no immediate payback. The most successful teams invested much of their early time in removing dependencies and building “instrumentation”—our term for infrastructure used to measure every important action—before they began to innovate, meaning, add new features.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“with microservices, it becomes possible to establish small, autonomous teams that can assume a level of ownership of their code that isn’t possible with a monolithic approach. The switch to microservices removed the shackles that had prevented the Amazon software teams from moving fast, and enabled the transition to small, autonomous teams.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“All in all, the NPI process was not beloved. If you mention NPI to any Amazonian who went through it, you’re likely to get a grimace and maybe a horror story or two. Sometimes you got lucky, your project was approved, and you could move forward smoothly enough. Too often, however, your plans were thwarted. Instead of doing vital work on something you owned, you’d be assigned to support another team’s project while still taking care of everything that was left on your plate. “Getting NPI’d,” as we called it, meant that your team was literally getting nothing for something.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“This new system greatly improved upon the free-for-all it replaced. For the purposes of this book, suffice it to say that implementing this improvement meant replacing Obidos, acb, and many other key pieces of our software infrastructure piece by piece while it was still running our business nonstop. This required a major investment in development resources, systems architecture planning, and great care to ensure that the monolith continued to stand until its last surviving function had been replaced by a service. The rolling regeneration of the way we built and deployed technology was a bold move, an expensive investment that stretched over several years of intensive and delicate work.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“If multiple teams have direct access to a shared block of software code or some part of a database, they slow each other down. Whether they’re allowed to change the way the code works, change how the data are organized, or merely build something that uses the shared code or data, everybody is at risk if anybody makes a change. Managing that risk requires a lot of time spent in coordination. The solution is to encapsulate, that is, assign ownership of a given block of code or part of a database to one team. Anyone else who wants something from that walled-off area must make a well-documented service request via an API.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
“Tearing Down Monoliths “Be autonomous.” Sounds simple, doesn’t it? In fact, it would be hard to overstate the effort we expended to free these teams from the constraints that bound them so tightly at the beginning. The effort would necessitate major changes to the way we wrote, built, tested, and deployed our software, how we stored our data, and how we monitored our systems to keep them running twenty-four hours a day, seven days a week.”
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
― Working Backwards: Insights, Stories, and Secrets from Inside Amazon
