Product decisions for cloud services at scale
Infrastructure products are judged by what never happens. This is what deciding what gets built looks like when the user's definition of success is silence.
Context
Since 2022 I've worked as a technical product manager on cloud services serving hundreds of thousands of users. The customers are engineers and enterprises running real workloads; the stakes are their production systems, not their leisure time. The product surface I work on sits on top of infrastructure I used to operate myself, a decade earlier.
The problem
Nobody wants cloud infrastructure. They want their application to work, their backups to exist, their launch to survive its traffic. The product's success is measured by its own invisibility — which inverts most consumer product instincts. Desire cannot be manufactured; only friction can be removed and trust earned.
Why it mattered
For an infrastructure provider, differentiation is not delight — it is working under specific, quantified, adversarial conditions. Durability, latency ceilings, failure-domain behavior: for the customer these are not fine print, they are the purchase. The product organization's job is to decide which of those promises to make, and what each one costs to keep.
My role
I own the 'what, for whom, and why' side of the services I cover: reading usage and support signals, defining direction with engineering, negotiating scope with stakeholders, and turning architecture constraints into roadmap choices a business can evaluate. The previous decade operating this class of system is the tool I use daily — I can read an architecture discussion and know which corner cuts will page someone at 3 a.m.
Constraints
The cast is the constraint set: the engineer who integrates the service, the operator who runs it at 3 a.m., the finance owner who pays, the security reviewer who gates. A change that delights one can punish another. Add enterprise buyers with long decision cycles, compliance requirements, and migration costs that make switching painful in both directions.
Discovery
The honest signals in infrastructure are behavioral, not aspirational: what users do at 2 a.m. during an incident, which API calls cluster together, where support tickets repeat, what prospects ask before they buy, what the ops floor says in postmortems. Feature requests are data about frustration, not specifications — the work is digging back to the job the user was trying to do.
Product reasoning
Three rules I apply, distilled in the Thinking section of this site: default to defaults (make the right path the path of least 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: flexibility versus inevitability. Every configuration option we expose is a decision we push onto the user and a state the platform must support forever. Removing an option is often the more valuable roadmap item than adding one — and the harder conversation. The second: transparency versus cognitive load — showing every failure domain builds trust and overwhelms most users; the design work is layering.
Outcome
Services that kept their promises at growing scale, a product direction that engineers could defend in architecture reviews because it accounted for how the system actually fails, and roadmap choices the business could evaluate on cost-of-promise rather than feature-count. The qualitative outcome that matters most to me: fewer decisions required from each user to get to a safe, working setup.
What I learned
Infrastructure product management is the craft of making powerful things feel inevitable. The decade I spent in the NOC was not a detour before product — it was the qualification. You cannot price a promise you have never had to keep.