It’s not about learning to grow bigger, but about learning Day 1: Three shocks from reading “Amazon Digital Growth Mindset”

I have always felt that the most common mistake that companies make when talking about digital transformation is not to choose the wrong technology or buy the wrong tools, but to treat “transformation” as a project - such as changing ERP, migrating to the cloud, importing AI, making an app; completing the transaction, taking photos and closing the case, and then returning to the original way of doing things. So you will see a very familiar scene: meetings continue as usual, processes become more stuck, the only change is a bunch of KPIs and dashboards, but the organization becomes slower, duller, and even more afraid of making mistakes.

“Amazon Digital Growth Thinking” (original title: Think Like Amazon: 50 1/2 Ideas to Become a Digital Leader) gives me the completely opposite feeling: it is not teaching you “what to do”, but forcing you to admit that you think you are transforming, but in fact you are just putting a new skin on the old system. This book breaks down Amazon into a four-layer structure: culture, strategy, business and technology, methods and execution, and uses “50 and 1/2” actionable methods, like a toolbox, to let you compare your organization and team one by one.

More importantly, the author John Rossman (John Rossman) is not a storyteller standing on the periphery - he once led key businesses such as Marketplace (third-party seller platform) at Amazon. Marketplace later became one of Amazon’s core engines with a very high proportion of shipments and sales units. With this background, the methods in the book are not beautiful slogans, but management mechanisms with hard work and cost.

After reading this, the thought that came to my mind wasn’t “Amazon is awesome,” but a more poignant question: How can we prevent our organization from sneaking into the next day?

The first shock: The most terrifying thing about Amazon is not its ability to innovate, but its ability to resist rigidity.

Many people attribute Amazon’s power to AWS, drones, Alexa, algorithms, and logistics. But this book keeps reminding you: those are just results. The real bottom layer is that Amazon has turned anti-rigidity into a set of systematic and replicable organizational habits.

You see Jeff Bezos’s oft-quoted words – “Day 2 is stagnation, then irrelevance, then painful decline, then death; so it’s always Day 1.” ([Day 1] Letter](https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders)) - The reason why it is not chicken soup is because Amazon turns it into management design: processes, decision-making, employment, communication, and measurement methods are all fighting against Day 2.

The slowness I often see in corporate internal training and consultant situations is mostly not due to lack of ability, but because everyone is using processes to protect themselves: first hold a meeting, then find consensus, then write a report, and then approve it at all levels - everyone is avoiding responsibility, and in the end there is no speed. Amazon’s approach is the opposite: it uses a bunch of seemingly harsh mechanisms to force you to face reality, to make ambiguity clear, and to take responsibility. So the speed is not to rush everyone, the speed is to make the system naturally faster.”

If you put this passage into the context of Taiwanese companies, you will suddenly understand: Many companies do not lack AI, cloud, or data, but lack the courage to “be willing to admit that they are slowing down.” Because if you admit it, you have to change it; and if you change it, you will definitely offend people, break your comfort zone, and invalidate some vested interests.

The second shock: Two Pizza Team is not a slogan, but an “accounting to reduce communication costs”

Many organizations in Taiwan have a typical problem: the more people there are, the lower the efficiency. It’s not that everyone doesn’t work hard, but the cost of information flowing in the organization is too high; you only need to cross one department, just like crossing a country.

The book talks about the spirit of Two-Pizza Teams (https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html). What I care about most is not the pizza, but the cost concept behind it: when the team is so big that it needs to use meetings to maintain synchronization, the output begins to be swallowed up by management costs. AWS’s official article even directly states that the ideal number of two pizza teams is less than 10 people, because small teams can reduce communication lines, reduce bureaucracy and decision-making costs.

If we move the scene back to Taiwan, you will find that small and medium-sized enterprises do not lack people, but lack the design to reduce the number of people. The way to reduce the number of employees is not to lay off employees, but to cut tasks into clear service boundaries so that each team is responsible for a result and has enough authority to get things done. Otherwise you will always be stuck on the word “coordination”.

I would even apply it to my personal career: the reason why many people are anxious about their work is because they have too many “boundary tasks” at the same time - they have to take care of everything, and in the end nothing can produce visible results. The thinking of the two pizza teams, personally, is: Can you turn your week into a few service units that are “small enough to be delivered independently”?

The third shock: Amazon uses writing to create clarity and backward reasoning to create good products

I particularly like the write-first-do-then mechanism discussed in the book: instead of using slides, narrative documents, memos, and working backwards are used. Because slides are the easiest way to package ambiguity into beauty; but text is different, text will force you to face loopholes in logic.

The core spirit of Working Backwards is to first define the customer experience, and then work backwards all the way to what you should do and how you should do it. The related method is often called PR/FAQ (write “future press releases” and FAQ first), and the purpose is to put “will customers be surprised” before everything starts.

I read this paragraph with great emotion, because I have been teaching writing for many years, and I know one thing best: writing is not expression, but thinking.

Many teams think they are making products, but in fact they are just making functions; they think they are making transformation, but in fact they are just making superficial digital engineering. You just ask them to “use one page to explain clearly: Who will be better because of you? In which scene will he exclaim? Without you, how will he feel pain now?” You will see the truth immediately - most proposals have no customer picture at all, only internal processes and supervisor preferences.

And this is what I think is the most valuable thing for Taiwanese companies to learn from this book: not to blindly copy Amazon’s tools, but to learn how to use mechanisms to combat ambiguity.

Implementation route: Change the Amazon method to the three-stage method of Taiwanese companies

Next, I want to tell you how I will use this book? To put it simply, it is to rewrite the Amazon method into a three-stage formula that can be launched by Taiwanese companies.

If you ask me: How will this book be implemented? I wouldn’t ask you to import 50.5 methods at once, that would just become another form of transition anxiety. I will use a more pragmatic approach, split it into three parts, let the organization start moving, and then gradually become stronger.

1. In the first paragraph, pick the most painful process first: such as new product registration, customer service feedback processing, content marketing output rhythm, or cross-department delivery. Then introduce the strategy of using writing to force clarity: use a simplified version of PR/FAQ or 6-pager to force the team to clearly write down the customer value first, and then talk about resources and scheduling. Get this right, and you’ll find that meetings suddenly become shorter and arguments less frequent because everyone is finally discussing the same thing on the same text.

2. Paragraph 2, Processing Speed: Replace cross-department coordination with team boundaries. You don’t have to really reorganize the entire company, but you can start with a project by setting up a single-line team that is small enough to be responsible for the end, and make it responsible for the results rather than the process. The spirit of the two pizza teams is not to divide labor, but to turn “delivery” into a unit that can be undertaken.

3. The third paragraph, put data and AI in: It is not “AI for AI’s sake”, but to go back to the very key concept in the book - automation and AI. Starting from the formula, first clearly define [measurable input] (/blog/ai-outlook-2026) and production capacity. Only then will you know what to automate and what period of manpower to let AI help you save. Otherwise, if you buy a bunch of tools, you will end up with a bunch of more reports and less results.

Conclusion: Amazon is not a template, but a magic mirror

After reading this, I am more certain of one thing: Amazon is not a corporate template, but a magic mirror.

“[Amazon Digital Growth Mindset](https://www.books.com.tw/exep/assp.php/vista/products/0011040884?utm_source=vista&utm_medium=ap-books&utm_cont ent=recommend&utm_campaign=ap-202601)” is both easy to read and harsh because it forces you to admit: what you thought was soundness might just be a fear of losing; what you thought was a process might just be a shirk of responsibility; what you thought was a consensus might just be procrastination; what you thought was innovation might just be an old practice with a different name.

Amazon’s strongest point has never been “how many new things it has made”, but that it regards “avoiding slowdowns” as the company’s top priority strategy. And that strategy ultimately comes back to the question: Can you still treat tomorrow as the first day?

If you are a leader, I would recommend that you treat this book like an annual physical check-up: instead of just finishing it, you should take each chapter and ask yourself - Where are we becoming Day 2? Can we start with a small process, a small team, and a written document to get the first day back?

If you are an individual worker, creator or lecturer, I would like to invite you to run yourself in an Amazon-like way: use writing to force positioning, use backward reasoning to force products, use team thinking to manage your own time and delivery, and use indicators to manage your own input, instead of just focusing on the results and anxiety.

Because after all, this book is about Amazon; but what it really wants to remind you is yourself - is what you are doing today making you faster or making you slower?

---

Further reading

• Let ChatGPT be your writing coach! Five steps to start creative inspiration
• AI Outlook 2026: How can we prepare ourselves?
• The starting point for building excellent writing skills: starting with building habits
• AI is not your master, but your co-pilot

---

☕️ Invite Vista to have a cup of coffee

---