Dipak A.’s Post

Amazon has a secret strategy that they've been using for decades 💡 Its their #1 tool that keeps all of their operations around the world running efficiently Its incredibly simple, yet so many businesses don't have it implemented, or struggle to implement it. I'm talking about a Standard Work Checklist and End of Day Report. Learn how to implement it and I guarantee your business will EXPLODE. Check out my video on this strategy below 👇

Software development is like any leaky abstraction. For example, when ordering an item from amazon, a customer shouldn't be forced to specify HOW will the item be delivered to their doorstep. That's premature optimization, which is the root of all evil. Similarly, when starting to work on a brand new system, premature optimization is the worst thing one can do. Meaning, leave any decisions about the infrastructure to as late as possible. Do not insist on fleshing out the details.

Amazon engineers deploy new code every 11.7 seconds on average. I worked for a product company that had a 6-month release cycle. Imagine the deployment velocity in that case. However, this doesn't mean that Amazon engineers are superior and the latter ones inferior. Both groups are equally impactful in their capacities. Don't chase useless vanity metrics. No one pays for the number of lines of code or speed of deployments. You are paid for the problems you solve and the impact you create. 🔁 Consider a repost if this is useful.

One of my favorite tools that I learned at Amazon to optimize work processes is the concept of Mechanisms. Amazon refers to "mechanisms" as structured, repeatable processes or systems designed to drive specific outcomes within the business. This concept is a core part of Amazon's corporate culture and strategy, aimed at ensuring efficiency, consistency, and scalability across its operations. The idea behind mechanisms is not just to identify best practices but to embed them into the fabric of the organization in such a way that they produce reliable, predictable results. Mechanisms are built on a few key principles: 𝗖𝗹𝗲𝗮𝗿, 𝗪𝗿𝗶𝘁𝘁𝗲𝗻 𝗡𝗮𝗿𝗿𝗮𝘁𝗶𝘃𝗲𝘀: Amazon prefers detailed, written narratives (six-pagers or FAQs) over slide-based presentations for discussing ideas and strategies. This encourages clarity of thought and thorough examination of proposals. I honed my writing skills while at Amazon and it's helped me drive alignment with all future teams. 𝗢𝘄𝗻𝗲𝗿𝘀𝗵𝗶𝗽 𝗮𝗻𝗱 𝗔𝗰𝗰𝗼𝘂𝗻𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆: Mechanisms are designed to ensure that teams or individuals are directly responsible for outcomes. This ownership ensures that there's always someone specifically accountable for the success or failure of a process. Coinbase also leveraged DRI (directly responsible individuals) in the same manner. It's a powerful way to ensure things get done. 𝗠𝗲𝘁𝗿𝗶𝗰𝘀 𝗮𝗻𝗱 𝗠𝗲𝗮𝘀𝘂𝗿𝗲𝗺𝗲𝗻𝘁𝘀: Amazon is known for its focus on data-driven decision-making. Mechanisms often include specific metrics to measure performance, success, and areas for improvement. This approach ensures that decisions are made based on evidence and that there are clear benchmarks for success. 𝗖𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀 𝗙𝗲𝗲𝗱𝗯𝗮𝗰𝗸 𝗮𝗻𝗱 𝗜𝗺𝗽𝗿𝗼𝘃𝗲𝗺𝗲𝗻𝘁: Mechanisms are not static; they include processes for regular review, feedback, and adjustment. This ensures that they evolve over time to remain effective and relevant as the business and its environment change. 𝗦𝗰𝗮𝗹𝗮𝗯𝗶𝗹𝗶𝘁𝘆: Designed to be scalable, these mechanisms can be applied across different parts of the organization, regardless of size or function. This scalability is crucial for a company as vast and diverse as Amazon. Examples of mechanisms at Amazon include the “Working Backwards” process, where new product ideas are proposed in the form of a future press release and FAQ document, and the “OP1” (Operating Plan 1) process for annual planning. These mechanisms ensure that initiatives are customer-focused, align with long-term objectives, and are thoroughly vetted before they are pursued. How could you use Mechanisms in your organization to improve your processes and your company?

Amazon engineers deploy new code every 11.7 seconds on average. I worked for a product company that had a 6-month release cycle. Imagine the deployment velocity in that case. However, this doesn't mean that Amazon engineers are superior and the latter ones inferior. Both groups are equally impactful in their capacities. Don't chase useless vanity metrics. No one pays for the number of lines of code or speed of deployments. You are paid for the problems you solve and the impact you create.

Amazon engineers deploy new code every 11.7 seconds on average. I worked for a product company that had a 6-month release cycle. Imagine the deployment velocity in that case. However, this doesn't mean that Amazon engineers are superior and the latter ones inferior. Both groups are equally impactful in their capacities. Don't chase useless vanity metrics. No one pays for the number of lines of code or speed of deployments. You are paid for the problems you solve and the impact you create.

Almost a decade ago, Amazon was updating its codebase every 𝟏𝟏.𝟔 𝐬𝐞𝐜𝐨𝐧𝐝𝐬—essentially reinventing the way they serve their customers 𝐟𝐢𝐯𝐞 𝐭𝐢𝐦𝐞𝐬 𝐚 𝐦𝐢𝐧𝐮𝐭𝐞. 𝐈𝐦𝐚𝐠𝐢𝐧𝐞 𝐰𝐡𝐚𝐭 𝐭𝐡𝐚𝐭 𝐟𝐢𝐠𝐮𝐫𝐞 𝐢𝐬 𝐭𝐨𝐝𝐚𝐲 🤩 In 2018, Google revealed it runs over 500 million tests a day. That’s more than 4 million relaunches of existing and new systems every single day. These numbers inspired me. 𝐓𝐡𝐚𝐭’𝐬 𝐭𝐡𝐞 𝐦𝐨𝐝𝐞𝐫𝐧 𝐩𝐚𝐜𝐞 𝐨𝐟 𝐜𝐡𝐚𝐧𝐠𝐞. 💡 As products change incrementally, business development and sales should do the same. I believe the number one skill to thrive in this environment is 𝐜𝐮𝐫𝐢𝐨𝐬𝐢𝐭𝐲. We need to be curious enough to continually learn, test, and understand new technologies and methodologies. I can imagine how we can grow together with these products. Our strategies must evolve as quickly as the tech does. Stay agile, adapt, and watch your growth skyrocket. What steps are you taking to keep up? P.S. A little bit of art to your feed: The picture represents ordinary things that possess secret powers and challenge us to re-think the surrounding world as we know it.

Spending valuable time at #awsebc with industry colleagues learning about Amazon culture and what it takes to partner with them for ideas and placing products within their services and infrastructure. Every idea that manages to get implemented starts the same way: 1. One-pager (and 6 Pager for more details) 2. A prepared press release which states why Amazon Web Services (AWS) partners and sees opportunity in the product or collaboration. 3. A comprehensive FAQ that answers all the peer questions on the new product or collaboration. Without these nailed, no software developer will touch anything. One of many reasons for this process is to take away potential frustration to work on products that never actually launch as they were not properly thought through in the first place. Apparently once implemented the press releases are used almost 1:1 from what they were at the start of the project. Very distinct company culture. Comment if you want to learn more about what I learn here over the next two days!

Common pitfalls and mistakes to avoid when implementing SOPs: SOPs are the backbone of any successful Amazon agency. They provide clarity, consistency, and help scale your workflow. However, if not implemented correctly, SOPs can do more harm than good. Here are some common pitfalls to avoid: → Assuming everyone knows how to follow SOPs → Lack of accountability → Not reviewing and updating SOPs regularly → Over-complicating SOPs By avoiding these common pitfalls, you can ensure that your SOPs are effective, efficient, and help your Amazon agency grow. Leave a comment below with your experience in implementing SOPs - what worked and what didn't work for you?

Week 3 SDM at Amazon - Working Backwards "Customer-obsession" is a bold statement, but what does it actually mean? How do you apply this on-the-job? 🔁 At Amazon, it involves a process carefully named "Working Backwards". "The Working Backwards process is a huge amount of work. But, it will save you even more work later on." - Jeff Bezos Working backwards means to start with the customer need first, and work back from there to the implementation details and technical solution. The most important thing is to understand the problem you are trying to solve for your customer and how it will make their life better. It involves meticulously developed strategies and mechanisms (complete processes) where we are answering questions such as: 1️⃣ Who is the customer? Here we consider elements such as time, place and situation. 2️⃣ What is the customer problem or opportunity? Here we specify the problem we are going to solve for the customer. We define as well the size of the problem. 3️⃣ What is the most important customer benefit? Here we prioritize the exact elements the customer values. 4️⃣ How do you know what the customer wants or needs? Here we challenge our thinking process with concrete data (e.g., What data led to this conclusion?). We also try to eliminate bias (recognizing that our personal experiences or beliefs may not be representative of the customers) as well as consider why the proposed solution is the right one versus other options considered. 5️⃣ What does the customer experience look like? At this point we start to envision how our proposal will look and feel in the hands of the customer. It may involve elements such as: Whiteboard sketch, Storyboard, User Journey Map, Wireframe, Architecture diagram, etc. We innovate on behalf of our customers, and as such, we start with the customer in the center of everything we do, working from there to our solution to bring smiles. 😊 ❕This is by no means an exhaustive list but rather the bare minimum to consider when evaluating any problem or opportunity for our customers. It also does not represent Amazon's complete view over the process, but rather my (quite brief) understanding as of today, where I'm barely scratching the surface. I've also not covered yet the mechanisms that enable this, or the stages of the process (such as measuring success, intended/unintended impact, etc), but those are for another post. 📖 If you're eager to Dive Deep further on your own, I highly recommend the book "Working Backwards" from Colin Bryar and Bill Carr (two former Amazon VPs). It's probably the best book on customer centricity I had the pleasure to read. 🤔 Now an interesting exercise - Can you easily answer the 5 questions above on the project you are working on? How do you keep the customer need at the center of everything you are building? Do you have better or different questions you're asking yourself when building a solution for your customers? Would love to know in the comments 👇