Mehdi Shabestari

I turn complex infrastructure into products people can use.

Technical Product Manager · Cloud & AI Infrastructure

Twenty years up the stack — analog telephony, enterprise networks, datacenters, cloud platforms — and, since 2022, product decisions for cloud services used by hundreds of thousands of people. I speak fluent engineering and fluent business, and I'm most useful where the two don't translate themselves.

20 years
from PSTN to AI-era infrastructure
Hundreds of thousands
people using services I help shape
5 chapters
support → network → datacenter → product
01

Selected impact

What changed because I was in the room — described the way infrastructure people describe things: qualitatively, and only where the evidence supports it.

  • Cloud services at population scale

    Product direction for infrastructure services used by hundreds of thousands of people — where the roadmap is made of promises and every default removes a thousand bad decisions.

    Read the case study →
  • A NOC that held through 2020

    Led the network operations room when the world's traffic moved indoors: escalation paths people trusted, handovers that survived the night, and an incident language engineering could act on.

    Read the case study →
  • Voice platforms for real customers

    Eleven years in telephony while the phone network became software — administering, engineering, and leading the systems businesses ran their calls on.

    Read the case study →
  • This site, as a working argument

    A bilingual, accessible, 180-page knowledge platform — typed content models, static generation, zero trackers — that practices the product thinking it documents.

    Read the case study →
02

Problems I help solve

Not a skill list — the situations where I create the most value.

  • Productizing complex infrastructure

    Turn technically deep infrastructure into a product customers can understand, evaluate and operate — without lying about what's underneath.

  • Platform and cloud product direction

    Define what gets built when reliability is the product: which promises to make, how to phrase them honestly, and what each one costs to keep.

  • Product ↔ engineering translation

    Convert architecture constraints into roadmap choices a business can evaluate — and business goals into constraints engineering respects.

  • Enterprise and technical buyers

    Keep the whole cast coherent: the engineer who integrates, the operator at 3 a.m., the finance owner, the security reviewer — one product, four audiences.

  • Discovery on technical systems

    Take an ambiguous platform problem from signals — usage, tickets, postmortems, prospect questions — to product definition and execution.

  • AI-era infrastructure products

    Apply the same discipline to the newest rung of the ladder: turning AI capability into infrastructure people can depend on, not just demo.

03

Featured work

Three case studies from the practice — judgment, constraints, trade-offs — plus the site you're reading, documented like it matters.

All case studies →

04

How I think

Principles earned the long way — each one traceable to an incident, a trade-off, or a system that stayed up (or didn't).

  • Users buy outcomes, tolerate products

    Nobody wants your infrastructure. They want their launch to survive its traffic. Design for the outcome, remove the ceremony.

  • Abstractions are promises

    Each layer of the stack promises you can stop thinking about the one below. Every leak is a broken promise someone answers for.

  • Coordination problems are technical problems

    Most 'technical' failures at scale are interface failures between humans. Design the interface; don't just staff it.

All principles, and the models behind them →

05

The stack under the product

One career, climbed bottom to top. Product decisions made here are grounded in what each layer actually does when it fails — because I have been the person it failed on.

  1. Product

    Direction, promises, defaults — since 2022

  2. Cloud & platform

    Fleets, control planes, abstractions — 2019

  3. Networking

    Routing, switching, the paths packets take — 2012

  4. Telecom

    Voice, signaling, the century of copper — 2007

  5. Systems

    The physical layer that answers eventually

Most product managers learn this stack from slide decks. I learned it from pager alerts — which is why my roadmaps tend to remember the on-call rotation.

06

From analog to cloud native

The unusual part of this career is the direction: I didn't move from business into product vocabulary — I climbed the entire stack first. The product judgment has the smell of the datacenter on it.

  • Early yearsA home computer, a mailed Linux CD
  • 2007Voice becomes software — VoIP at Tel4Tel
  • 2011 – 2018Under the cables — networks and voice at FCP
  • 2019 – 2020The abstraction ladder — cloud, then the NOC room
  • 2022 –Infrastructure as a product

The whole journey →

07

Selected writing

Longer arguments behind the one-liners.

All essays →

08

Beyond work

The rest of this site is the rest of me: three thousand years of communication history mapped as a timeline, the thinkers who sharpened the questions, and a quiet corner to breathe.

Next

Let's build something difficult.

If you're hiring for a technical product role, shaping a cloud or AI infrastructure product, or want a second brain that has actually carried a pager — I'd like to hear about it.

  • Discuss a role

    Technical product management, platform and infrastructure product roles — especially where engineering credibility is part of the job description.

    Start the conversation →
  • Discuss a project

    Productizing complex infrastructure, discovery on technical systems, or a product strategy problem that needs someone who can read the architecture.

    Tell me about it →
  • Look around first

    Case studies, principles, and the journey that produced them — everything is one click from here.

    Explore the work →