Applying Amazon’s Working Backwards to your technology project
This blog post is based on my field experience, case-studies, and during my time at Amazon Web Services.
“We innovate by starting with the customer and working backwards. That becomes the touchstone for how we invent.” - Jeff Bezos
Technology projects frequently fail, with data showing a mean cost overrun of 73% and catastrophic overruns of 447% in 18% of cases. The culprits: cookie-cutter approaches that oversimplify complex realities, insufficient planning, and short-term thinking that accumulates technical debt.
Amazon's "Working Backwards" methodology offers a solution by starting with the desired outcome instead of the technology. This approach creates clarity by envisioning success in concrete terms before implementation begins, revealing potential obstacles early.
Key Takeaways
Start with the destination - use Amazon's Working Backwards approach to clearly define success before planning implementation steps.
Embrace fast feedback loops and low-cost failures to learn quickly and reduce catastrophic risk.
Question vendor-promoted methodologies that prioritise standardisation over your unique business context.
Consider specialised boutique consultancies whose success depends entirely on your success.
Avoid technical debt by balancing short-term functionality with long-term sustainability.
Beyond Cookie-Cutter IT: Working Backwards to Technology Project Success
Failed technology initiatives grows larger each year. While some projects succeed admirably, many more collapse under their own weight, leaving behind shattered timelines, exhausted budgets, and disillusioned teams. This isn't merely anecdotal - empirical data identifies technology projects as the fifth riskiest project category, with a mean cost overrun of 73%. More troubling still, 18% of technology projects suffer catastrophic budget explosions averaging 447% over initial estimates.
What separates success from failure in this high-stakes domain? Why do cookie-cutter approaches consistently under-deliver? And how might we chart a different course?
The Fragility of Conventional Wisdom
Technology vendors preach standardised methodologies with evangelical fervour. These approaches promise predictability and efficiency but often deliver neither. The fundamental flaw lies in the oversimplification - complex, unique business environments compressed into oversimplified narratives that ignore critical nuances.
Systems become brittle, unable to adapt to the inevitable surprises that emerge during implementation. The one-size-fits-all approach demands extensive customisation, paradoxically increasing complexity rather than reducing it.
Many project teams, under pressure to show immediate progress, skip crucial planning phases. They rush past prototyping and testing, launching implementation without a clear vision of the journey ahead. Like setting sail without a map, they soon find themselves adrift, the project stalled and eventually abandoned when the path forward becomes obscured.
Even successful implementations often carry the seeds of future failure. Short-term thinking prioritises immediate functionality over long-term sustainability. Technical debt accumulates silently, making future extensions and integrations increasingly complex and inflexible. The apparent victory becomes Pyrrhic when maintenance costs skyrocket and adaptability plummets.
Working Backwards: The Antidote to Forward Failure
Amazon's "Working Backwards" methodology offers a powerful alternative to conventional approaches. Rather than starting with technology and forcing it to fit business needs, this approach begins with the desired outcome and works backwards to determine the necessary path. The process starts with writing a future press release and FAQ document that describes the completed project's impact in concrete terms. This forces clarity about what success actually means - not in technical specifications, but in tangible business outcomes and user experiences.
This approach eliminates the hazards of vague objectives. The end state becomes vivid and specific, allowing teams to trace a clear path backward to the present. Each step in the implementation becomes visible because you've already envisioned the destination in detail. Working backwards also exposes hidden complexities early. When you mentally traverse the path from future success to present starting point, you naturally identify obstacles, dependencies, and potential failure points that might otherwise remain hidden until they derail the project.
As one of my favourite writers, Earl Nightingale, noted, "People with goals succeed because they know where they're going." Working backwards crystallises that destination, making success infinitely more achievable.
Here are the five fundamental steps of Amazon’s Working Backwards approach, and the fundamental question each aims to answer:
Customer Insights: Who is the customer and what insights do we have about them?
Customer Problem or Opportunity: What is the prevailing customer problem or opportunity?
Customer Benefits: What is the solution and the most important customer benefits?
Customer Experience: How do we describe the solution and the experience to customers?
Test & Iterate: How to test the solution with customers and measure success?
Before looking into how this obsessed-customer-focus mechanism can be applied to your Technology project, it is important to establish a few axioms to help dispel some powerful illusions.
Axiom 1 - The Power of Low-Cost Failures
Innovation requires experimentation, yet most organisations structure technology projects to avoid failure at all costs. This paradox - requiring innovation while punishing experimentation - dooms projects from the start.
The alternative is designing systems that enable fast feedback loops and low-cost errors. Rather than staking everything on a single, massive implementation, break the journey into small, testable hypotheses. Each mini-experiment provides valuable data at minimal cost, gradually revealing the optimal path forward. This approach transforms failure from catastrophe to teacher. As my favourite thinker Nassim Taleb might observe, it makes your project anti-fragile—actually benefiting from the stressors and surprises that would break rigid implementations.
Consider how quickly you'd learn to navigate a dark room if each step provided immediate feedback. Now imagine waiting until you've walked the entire length before learning you've been heading in the wrong direction. Technology projects benefit from the same principle - rapid feedback accelerates learning and increases success rates.
“Our success at Amazon is a function of how many experiments we do per year, per month, per week, per day.” - Jeff Bezos
Axiom 2 - Challenging Vendor Narratives
Vendor-promoted methodologies often serve the vendor's interests more than the client's. Their cookie-cutter approaches streamline their operations and maximise their profitability, not necessarily your success. True innovation requires courage to challenge these dominant narratives. The most successful technology implementations often emerge from questioning conventional wisdom and discovering new approaches tailored to specific organisational needs.
Technology vendors sell standardisation as a virtue. But standardisation that ignores your unique business context introduces more problems than it solves. The key is determining which elements benefit from standardisation and which require customisation—a nuanced decision that cookie-cutter approaches cannot accommodate.
Remember that vendors profit from your dependency. Their ideal scenario often involves locking you into their ecosystem, making future changes costly and difficult. True partnership means prioritising your long-term flexibility and self-sufficiency, even when that means less revenue for the partner.
The cases of this practice are too numerous to mention. Here are a few public examples of vendors squeezing new and existing clients:
Increase of 1,050% in licensing costs in key hypervisor technology
Increase of 400% in licensing costs depending on hosting platform
Increase of 200%-500% of framework licensing costs
Increase of 200% in critical application delivery components
Business-at-risk uncertainty due to software provider acquisitions
“A squeeze occurs when people have no choice but to do something, and do it right away, regardless of the costs.” - Nassim Nicholas Taleb
Axiom 3 - The Boutique Advantage
Small, specialised consulting firms offer a compelling alternative to the technology giants. Their business model depends on excellence rather than scale, allowing them to focus fanatically on client outcomes rather than standardised processes.
These boutique firms bring several distinct advantages:
Deep specialisation allows them to understand nuances that generalists miss. Their expertise isn't spread thinly across dozens of technologies but concentrated in specific domains where they've developed genuine mastery.
Without massive overhead costs, boutique firms can afford to be selective, working only with clients where they can deliver exceptional value. This selectivity creates alignment—their success depends entirely on your success, fostering a level of dedication that larger firms struggle to match.
Perhaps most importantly, boutique firms remain independent from vendor incentives. They can recommend solutions based solely on client needs rather than partnership agreements or sales quotas. This independence allows for truly objective guidance, free from the conflicts of interest that plague larger consultancies.
The result is fanatical loyalty to client outcomes. While large firms must balance your interests against shareholder demands and growth targets, specialized consultancies succeed only when you succeed. This creates a powerful alignment that drives extraordinary results.
“Artisans have their soul in the game. Primo, artisans do things for existential reasons first, financial and commercial ones later. Their decision making is never fully financial, but it remains financial. Secundo, they have some type of ‘art’ in their profession; they stay away from most aspects of industrialisation; they combine art and business. Tertio, they put some soul in their work: they would not sell something defective or even of compromised quality because it hurts their pride. Finally, they have sacred taboos, things they would not do even if it markedly increased profitability.” - Nassim Nicholas Taleb
The Path Forward
Technology projects don't have to remain high-risk endeavours with unpredictable outcomes. By working backwards from clearly defined success, embracing experimental approaches with fast feedback, challenging vendor narratives, and partnering with deeply aligned specialists, organisations can dramatically improve their success rates.
The alternative—continuing with approaches that empirically fail 75% of the time—represents the true risk. In technology implementation, conformity to failed methodologies guarantees continued disappointment.
Here’s a guideline on how to apply the working backwards approach to your project.
Customer Insights: Who is the customer and what insights do we have about them?
Map stakeholder ecosystem including developers, operations teams, security teams, and business users with their specific technical capabilities and needs
Gather data on current deployment frequency, lead time, and mean time to recovery to establish baseline metrics
Document the current infrastructure friction points through hands-on workshops with technical teams
Customer Problem or Opportunity: What is the prevailing customer problem or opportunity?
Identify deployment bottlenecks where manual processes are creating delays in releasing business value
Quantify technical debt and compliance risks in the current environment that prevent scaling
Determine where lack of standardisation is creating operational inefficiencies and security vulnerabilities
Customer Benefits: What is the solution and the most important customer benefits?
Define clear metrics for improvement (e.g., 80% reduction in deployment time, 50% reduction in operational costs)
Create capability matrix showing which DevOps practices deliver the highest ROI for your specific organisation
Establish a security and compliance posture that enables rather than restricts innovation
Customer Experience: How do we describe the solution and the experience to customers?
Design self-service portal that abstracts infrastructure complexity while maintaining necessary guardrails
Create clear documentation and learning paths for different user personas to build proficiency
Establish feedback mechanisms that allow teams to report issues and request new capabilities
Test & Iterate: How to test the solution with customers and measure success?
Implement small proof of concept with one application team to validate approach before scaling
Establish clear KPIs for each phase (deployment frequency, lead time, change failure rate)
Create a regular feedback loop with users and adjust implementation based on real usage patterns
The choice is clear: continue with the cookie-cutter approaches that predictably under-deliver, or chart a new course that begins with the end in mind, learns through small failures, challenges questionable assumptions, and leverages deeply aligned partnerships.
The empirical evidence makes the consequences of each path clear. The only remaining question is which path you'll choose.
I invite you to subscribe to my blog, and to read a few of my favourite case-studies describing how some of my clients achieved success in their high-stakes technology projects, using the very same approach I just described.
Have a great day!
João