Mehdi Shabestari
I spent years keeping infrastructure running. Now I help decide what gets built.
I work on a cloud product used by 200,000 people. Support, networks, systems and operations shaped how I approach product decisions — especially what happens after launch.
What should the next person know?
In customer excellence, a technical issue could cross a customer's environment, the product, infrastructure and several teams. The next person taking over needed more than a ticket marked ‘in progress.’
- We used a consistent handover: what was known, what had been ruled out and who owned the next action. Runbooks had to be usable by someone other than the person who wrote them.
- That structure takes time on a routine issue. The alternative is spending time reconstructing the same context when an issue crosses teams. The aim was enough detail to make the next step clear, without turning every ticket into a document.
This is a working practice from a role overview, not a claim about a measured project outcome.
How I think about the work
A request needs a problem behind it
Customer issues and usage data tell me where to look. Before writing a requirement, I want to know what the customer was trying to do and what blocked them.
Read the principle →The cost continues after launch
A new cloud option can be useful and still add setup choices, support cases and operating cost. Those consequences belong in the product decision, not in a post-launch surprise.
Read the principle →
An Ubuntu CD came by post.
Before cloud products and roadmaps, there was a computer at home and a Linux CD that arrived in the mail. I still like following a system down to the layer where it becomes understandable. That curiosity is also why I built a timeline of communication technology, from the alphabet to packet switching.
Let's compare notes.
If you're building an infrastructure product and want to talk through a role, a product problem or how a service works for its users, I'd like to hear from you.
Get in touch →