Product decisions for cloud services at scale
Since 2022 I've decided what gets built, for whom and why, for cloud services used by hundreds of thousands of people. This is how those decisions actually get made.
Context
I work on the IaaS layer of a global-scale cloud provider: Cloud Server, networking and VPC, Storage, Migration, and more recently GPU services. The customers are engineers and enterprises running production workloads — their applications, not their spare time. The infrastructure I now shape in product decisions is the kind I operated myself for the decade before.
The problem
Users of infrastructure don't want the product. They want their application to work, their backups to exist, their launch to survive its traffic. Success is measured by nothing happening, and only failure is visible. That changes what product work means here: you can't manufacture desire, you can only remove decisions and keep promises.
Why it mattered
For infrastructure, differentiation isn't delight — it's working under specific, adversarial conditions. Durability figures, latency ceilings, failure-domain behavior: for the customer that is not fine print, it's the thing being purchased.
My role
I own the what-for-whom-why side: reading usage and support signals, setting direction with engineering, negotiating scope with stakeholders, and turning architecture constraints into roadmap items the business can evaluate. Ten years of operating this class of system is what I use daily — when I read an architecture proposal, I can tell which shortcuts will page someone later.
Constraints
Four audiences at once: the engineer who integrates the service, the operator who runs it at 3 a.m., finance, and security. A change that helps one can hurt another. Enterprise sales cycles are long, compliance requirements are real, and switching costs work in both directions.
Discovery
The honest signals are behavioral: what users do during an incident at 2 a.m., which API calls cluster together, which tickets repeat, what prospects ask before buying, what the ops floor says in postmortems. Feature requests are data about frustration, not specifications — the work is digging back to the task the user was trying to finish.
Product reasoning
Three rules I actually apply: default to defaults — make the right path the one with the fewest decisions. Price the promise — every reliability figure is a roadmap item with an engineering cost. Write like an operator — if the runbook can't be followed at 3 a.m., the feature isn't done.
Trade-offs
The recurring one is flexibility versus defaults. Every option we expose is a decision we push onto the user, and a state the platform supports forever. Removing an option is often worth more than adding one, though it's the harder conversation. The other is transparency versus noise: showing every failure domain builds trust with some users and overwhelms the rest, so the work is layering.
Outcome
Services that kept their promises as scale grew, and setup paths where users take fewer decisions to reach a safe working configuration. I can't publish internal figures; the shape of the outcome is what I can describe.
What I learned
You can't price a promise you've never had to keep. The decade in operations wasn't a detour before product — it was the qualification.