CHAPTERS
- 0:00 – 0:20
AWS’s biggest product miss: letting Snowflake dominate cloud data warehousing
The hosts shift from praising AWS to calling out what they see as its most notable failure: data warehousing. They frame Snowflake’s rise (despite running on AWS and other clouds) as surprising evidence AWS left value on the table.
- •AWS praise gives way to a pointed critique
- •Snowflake becomes a massive standalone company while relying on public clouds
- •Redshift’s success doesn’t erase the fact that Snowflake “ran the gauntlet”
- •Sets up the central question: why did AWS miss this market?
- 0:20 – 0:52
Redshift vs. Snowflake: why “good enough” wasn’t enough
Ben acknowledges AWS would point to Redshift as a fast-growing service, but argues that doesn’t address the core issue. The database organization at Amazon likely views Snowflake’s success as a painful competitive outcome.
- •AWS’s defense: Redshift is growing quickly
- •Counterpoint: Snowflake still captured disproportionate mindshare/value
- •Internal implication: Amazon’s database teams would be unhappy
- •Positions the miss as significant even in an otherwise strong AWS record
- 0:52 – 1:22
How AWS scale and enterprise obligations can slow product intuition
A key explanation offered is “big company stuff”: at AWS’s scale, security, operations, and SLA commitments can constrain speed and product simplicity. This can make it harder to ship an opinionated, streamlined, developer-friendly experience.
- •Enterprise trust brings heavy requirements (security, ops, SLAs)
- •These constraints can reduce agility and product focus
- •Difficulty being “opinionated” and simple at massive scale
- •Organizational maturity can hamper quick, intuitive product delivery
- 1:22 – 1:52
Customization burden: Redshift complexity vs. Snowflake out-of-the-box developer delight
The hosts argue Redshift often requires substantial customization, while Snowflake feels immediately usable for developers. Ironically, Snowflake’s approach resembles early AWS’s developer-first playbook, making AWS a “victim of its own success.”
- •Redshift perceived as requiring more setup and tailoring
- •Snowflake positioned as great out of the box for developers
- •Snowflake mirrors early AWS’s “serve developers first” strategy
- •AWS’s enterprise evolution creates an opening for simpler challengers
- 1:52 – 2:22
Fighting the last war: Redshift’s Oracle-shaped framing misses new segments
Citing Ben Thompson, they suggest Redshift’s positioning is anchored in replacing Oracle-style warehouses in the cloud. Snowflake, by contrast, attracted customers who might never have bought Oracle—indicating a different segment and set of needs.
- •Ben Thompson’s critique: the issue is “right there in the name”
- •Redshift framed as cloud analog to traditional Oracle data warehousing
- •Snowflake unlocks a different customer base and use cases
- •Market expansion beyond legacy incumbents was the real opportunity
- 2:22 – 2:27
Acknowledge and recover: leadership changes and “getting the house in order”
They note AWS appears to recognize the misstep and is reorganizing under new leadership. Still, they characterize the Snowflake outcome as a clear “whiff.”
- •AWS reportedly recognizes the gap in approach/segment coverage
- •New leadership is implied to be driving corrective action
- •Even for AWS, this stands out as an unusual miss
- •Sets up a comparison to much larger strategic misses by others
- 2:27 – 2:48
Putting the miss in perspective: not as catastrophic as Big Tech missing cloud entirely
The hosts calibrate the significance: AWS’s data warehouse miss is meaningful but far smaller than Microsoft or Google failing to build cloud businesses. This keeps the critique proportional to AWS’s overall success.
- •“Big whiff,” but not existential
- •Comparison: Microsoft/Google missing cloud would be far bigger
- •Frames AWS’s error as an exception within a strong track record
- •Leads into an upcoming grading/analysis section
- 2:48 – 3:19
Second ‘victim of success’ problem: two-pizza teams and the ‘alphabet soup’ of AWS services
They argue Amazon’s team structure encouraged shipping many separate services without a cohesive product strategy. The result was an overwhelming console experience where services blur together and customers struggle to choose confidently.
- •Two-pizza teams drive rapid, fragmented service launches
- •AWS becomes “alphabet soup” rather than a unified product suite
- •Console/service sprawl overwhelms users and obscures differentiation
- •Proliferation creates customer confusion and decision fatigue
- 3:19 – 3:49
Messaging shift: from counting launches to pitching vertical solutions and guardrails
They observe AWS keynotes have moved away from boasting about dozens of new features and toward industry-specific solutions and case studies. AWS also adds more “guardrail” services to reduce customer misconfiguration—though this can feel like adding yet another layer of complexity.
- •Keynotes pivot to vertical solutions and industry narratives
- •Less emphasis on raw volume of new service/feature announcements
- •Guardrails emerge to help customers avoid missteps without deep expertise
- •Tradeoff: guardrails can add more layers (managers/standards) to an already complex ecosystem
- 3:49 – 4:48
Competitive implication and closing reality: coherence as Google’s opening, but AWS still wins financially
They suggest AWS’s complexity becomes part of the bull case for Google Cloud, which can present a more cohesive strategy to customers. Despite cleanup efforts, AWS’s market leadership and profit dominance make the overall strategy hard to argue against.
- •Complexity creates an opening for competitors with clearer product strategy
- •Google positioned as a newer entrant with more coherence and guidance
- •AWS is actively cleaning up and reframing its offerings
- •Bottom line: AWS still leads in revenue and operating income by a wide margin
