Blog 107: Cloud decisions are increasingly becoming Product decisions
- Idea2Product2Business Team
- 2 days ago
- 4 min read
When I attended my first cloud conference in 2018, the conversations were around:
"How do we migrate faster?"
"Should we move to Kubernetes?"
"How many containers should a node run?"
"Is serverless mature enough?"
"Which cloud provider is cheaper?”
Back then, cloud success was largely around technical milestones:
How many workloads had migrated?
How many virtual machines had been decommissioned?
How quickly could infrastructure be provisioned?
How much deployment automation had been achieved?
Those were important questions and they still are.
But now the conversations are very different.
Instead of discussing clusters, engineers debate developer productivity.
Instead of talking about compute instances, they discuss platform capabilities.
Instead of asking how to provision infrastructure, they ask whether developers should even know infrastructure exists.
Instead of celebrating migrations, they measure deployment frequency, lead time, platform adoption, cloud economics, developer satisfaction, and business outcomes.
So, currently it is about:
BUILDING SOFTWARE FASTER
OPERATING SOFTWARE BETTER
HELPING BUSINESSES MAKE DECISIONS QUICKER
Case Study 1: Netflix
When Netflix began moving away from its own data centers after the major database corruption incident in 2008, the objective wasn't simply to "move to the cloud"
It was to build an architecture capable of surviving failures while supporting rapid innovation.
Instead of investing years into expanding physical infrastructure, engineering teams focused on creating resilient systems where services could evolve independently.
This philosophy eventually gave rise to many of Netflix's well-known engineering tools and practices, including Chaos Monkey, which intentionally terminates production instances to verify that systems recover automatically. Thus, Netflix gearing itself towards uninterrupted streaming for millions of subscribers.
The infrastructure decision served a business objective. Not the other way around.
Today, Netflix engineers rarely talk publicly about "cloud migration."
Instead, they discuss resilience, reliability, developer velocity, experimentation, and platform engineering.
The infrastructure became almost invisible.
Official Sources:
Netflix Technology Blog
Netflix Open Source Software
AWS Case Study – Netflix
Case Study 2: Spotify
By 2020, Spotify had grown into thousands of engineers spread across hundreds of engineering teams.
Each team had different tools.
Different deployment processes.
Different templates.
Different operational practices.
Innovation was slowing—not because engineers lacked talent, but because they were repeatedly solving the same infrastructure problems.
Spotify responded by creating Backstage.
At first glance, Backstage looks like an internal developer portal.
In reality, it's much more.
It became a central platform where developers could:
discover services
create new services using standardised templates
manage documentation
browse APIs
understand software ownership
access deployment workflows
find engineering resources in one place
Notice something interesting.
Backstage didn't improve Kubernetes. It improved the developer's experience of Kubernetes.
That's a completely different problem.
Instead of asking,
"How do we make infrastructure better?"
Spotify asked,
"How do we make building software easier?”
Today Backstage has become one of the CNCF's fastest-growing open-source projects, adopted by organizations including LinkedIn, American Airlines, Expedia, VMware, Philips, Epic Games, Twilio and many others.
'Developer Experience' is now a competitive advantage.
Sources:
Spotify Engineering — Introducing Backstage
Backstage Project
CNCF Backstage
How does Cloud Computing affect Product Management?
Why does this matter to Product Managers?
Reason 1: Cloud architecture is no longer just about servers. It's about strategy
Sometimes we product managers still assume that cloud architecture belongs exclusively to engineering teams.
Five years ago, that assumption was largely acceptable.
Today, it can become an expensive oversight.
Consider a product manager deciding between two approaches for a new feature:
Build it as a set of always-running microservices on Kubernetes.
Deploy it using event-driven serverless functions that scale to zero when idle.
Both options might satisfy the functional requirements.
But they create vastly different operational realities.
The Kubernetes approach may offer greater flexibility and control but also demands continuous cluster management, capacity planning, security patching, and potentially higher baseline infrastructure costs.
The serverless approach could reduce operational overhead and optimize costs for bursty workloads, but it introduces its own trade-offs around cold starts, execution limits, and vendor-specific architectures.
Neither choice is purely technical.
Both affect:
Cost of ownership
Time-to-market
Engineering velocity
Scalability
Customer experience
Future roadmap flexibility
This is why cloud decisions are becoming product decisions.
Hence, cloud architecture is no longer just about servers. It's about strategy.
Reason 2: Cloud migration is never the goal. Business growth is
Several organisations thought migrating to the cloud would automatically make them more faster, more cheaper and more reliable. However,
Cloud bills increased.
Architecture became more complicated.
Operational overhead exploded.
A study from the FinOps Foundation's State of FinOps Report consistently shows that organizations rank managing cloud spend as one of their highest priorities, even years after migration. The challenge is no longer getting to the cloud—it's operating efficiently once you're there.
Source: FinOps Foundation – State of FinOps Reports
Hence, cloud migration is never the goal. Business growth is.
Playbook for Product Managers who leverage Cloud
1. Think in Business Outcomes
Don't ask:
"Can we deploy this?"
Ask:
"Should we deploy this?"
Every architectural decision should trace back to customer value, operational simplicity, or business impact.
2. Optimize for Developer Experience
The best platforms are the ones developers barely notice.
Reduce cognitive load.
Automate repetitive tasks.
Create golden paths (https://cloud.google.com/blog/products/application-development/golden-paths-for-engineering-execution-consistency)
Make the secure path the easiest path.
3. Master Trade-offs, Not Tools
Tools change.
Trade-offs endure.
Whether it's Cloud Run vs. Kubernetes, PostgreSQL vs. Spanner, event-driven vs. synchronous architectures, your ability to evaluate options will outlast any individual technology.
4. Understand Economics
Every engineering decision has a financial consequence.
Learn the basics of FinOps.
Understand unit economics.
Design for efficiency, not because cloud is expensive, but because thoughtful engineering creates sustainable businesses.
5. Keep Learning, but Learn Differently
Five years ago, success meant learning another cloud service.
Today, success means understanding how technology, people, and business intersect.
That's a much harder skill.
It's also a much more valuable one.
To conclude,
Cloud computing has matured from an infrastructure migration initiative into a strategic business capability.
Platform Engineering has emerged to reduce developer cognitive load and improve software delivery.
Developer Experience (DevEx) is now a competitive advantage, not a nice-to-have.
FinOps has made cloud engineers active participants in financial decision-making.
AI is automating operational tasks but increasing the importance of architectural judgment and strategic thinking.
The most valuable cloud engineers today understand trade-offs, economics, and organisational design - not just cloud services.
Jump to blog 100 to refer to the overall product management mind map.
I wish you the best for your journey. 😊
