Crystal thinking & the untold cloud PM playbook
Kunal Parekh sold industrial valves in Mumbai before he built the control plane under Microsoft's biggest data workloads. His advice to anyone entering product in the AI era is not what you would expect — learn to write.
Watch the full episode on YouTube
Executive summary
Kunal Parekh is a Principal Product Manager at Microsoft, where he owns the infrastructure under two large data products — Cosmos Analytics, the internal platform Microsoft's own heavy workloads run on, and Fabric Spark. He arrived there by a route that looks nothing like a product career: selling industrial valves to refineries and petrochemical plants around Mumbai, then consulting at Infosys, then Shell, and finally big tech. Three pivots across three industries in roughly fifteen years.
The episode is nominally about cloud product management. What it actually delivers is a working theory of how you stay useful while the ground underneath your job keeps moving.
First: the unglamorous layer is the product. Infrastructure gets described as plumbing — the thing underneath the features that customers actually want. He rejects the framing outright. "You can also consider it as a product, because your reliability, scalability, stability of the product comes from there. It's not something which is an add-on feature — it has to be there." He has watched the alternative play out: "we have a lot of other product examples also in the past where the features were nice, but it was not supportable."
Second: AI did not change the standard — it changed the expectation. Reliability targets that used to sit at two or three nines now sit at four, five, six. Not because the engineering discipline was reinvented, but because users now judge instantly. "If something is not giving you the better experience, obviously within a fraction of a second your feedback will be like, okay, this is not a good product." The pressure lands squarely on the backend systems nobody sees.
Third — and this is the one worth sitting with: the highest-leverage skill for a product career in AI is writing. Asked what a 20- or 25-year-old should learn, he does not say a language, a framework, or a cloud certification: "Try to learn to write, structure your thoughts, rather than learning any new coding language." His reasoning is disarmingly practical. Everyone is now working through prompts, and a prompt is only as good as the thought behind it. "As long as your prompt is clear... as long as you are very structured, think through in your approaches — it will help."
Asked separately what he would do differently on a full retrospect, he lands in the same place: "maybe I would have spent more time on comprehending how the things are going on, documenting it somewhere, and maybe evolving from there."
The story
Start with the valves, because everything downstream is a reaction to them.
His first job was commercial sales of industrial valves into refineries and petrochemical companies across Mumbai. It is about as far from a cloud control plane as a career can start. But it taught him something that a product role normally takes years to teach, and it taught it under pressure:
"In a company like valves business — basically in the commercial space — they know your product better than yourself. And to sell them your product, it's very difficult, because you should know the right configurations and everything."
Read that again, because it inverts the usual assumption. The person he was selling to understood the product more deeply than the person selling it. There is no way to bluff a refinery engineer on valve specifications. The only survivable strategy is to actually understand what the user needs and why. He describes it as "keeping your feet on the street" — and it is the origin of a habit that shows up at every later stage: go to the person doing the work, and find out why the requirement exists.
The first pivot came from noticing an opening. Working in energy, he saw institutes launching MBAs specifically in energy, and took one. That led to Infosys, where the role was advisory — "a bridge between customer and your development team." He learned how requirements are generated and how applications get built, and worked with customers outside India, including in Germany.
But advisory work has a ceiling, and he names it precisely: "advisory always has some limitations." You receive the requirement, you pass the message to the development team, and eventually a product appears. You are adjacent to the building without ever doing it. What he wanted was to be on the other side of the fence — a phrase he uses repeatedly, and which turns out to be the actual through-line of his whole career.
Shell was the second pivot, and the real beginning of the product work. He moved from advising to being hands-on: business analyst, then product owner. His first product was commodity pricing. The job put him directly in front of traders, operators and supply-chain orchestrators — the people moving crude and products into the market — and the work was exactly what the valve years had trained him for. Talk to them. Understand the requirement. Then keep asking why:
"Why is the requirement generated? What is the reason behind it? Why are we solving this problem at all? Let's say a supply chain problem — why are we solving the supply chain problem?"
The most interesting thing he built at Shell was not a product but a team. Around the industry-wide move of data from on-premise to cloud, he set up what he calls a data-as-a-product team — a horizontal group serving all the feature teams, rather than another vertical shipping its own features.
Two details make this worth studying. The first is that he built it without formal authority: "I was not a people manager. I had an influence without authority." He was the product lead, not the boss. He defined the criteria, worked out which specialisms the team needed — someone strong in Spark, someone in middleware integrations, someone in analytics — then went to the people managers, screened résumés alongside his architects, and picked the people he wanted. That took two years.
The second detail is the outcome: the team became "one of the success stories which they are replicating to other organizations as well." A structure built by someone with no headcount authority became the template.
The third pivot, to Microsoft, he is candid about: "it was a very conscious and I think it was very opportunistic choice as well." Working on data and cloud products at Shell, he had been a user of Azure, and had started wondering how the thing he was consuming actually got made — "how they come and invent a lot of new things, how the data basically runs in a very efficient way." Then he names the real decision underneath it, which is not about companies at all:
"I had to decide whether I would be very domain specific, or I would like to go to the other part of the fence... whether I really wanted to end my career becoming a kind of a domain-specific master, or maybe I would try something new."
He chose the second, and prepared for it deliberately — taking a postgraduate product-management programme through COVID, nine years after his MBA, on weekday evenings and weekends, precisely because the lockdown had removed the usual excuse. "We had nothing else to do... I don't want to have a regret."
Four and a half years in, he now owns the control plane for Cosmos Analytics and Fabric Spark. The user became the builder.
Key decisions
Decision 1 — Treat the infrastructure layer as a product, not a substrate
The instinct is to treat infra as the cost centre beneath the real product. He argues the opposite: reliability, scalability and stability are product attributes, and they are the ones you cannot retrofit. "It's not something which is an add-on feature, but it has to be there."
His evidence is the failure mode, and it is worth quoting because it is the whole argument in one line: "the features were nice, but it was not supportable." A beautiful feature on an unsupportable foundation is not a half-win. It is a liability that eventually gets escalated.
Decision 2 — Put scale in the roadmap before you need it
Scale is not something you address when it arrives. It is a roadmap input from the beginning, because the jumps are not linear:
"If your scale is not measured properly in your roadmap, obviously the product will not be having that experience."
He reaches for streaming as the illustration — if Prime or Netflix could not scale and buffering became the norm, you would simply switch. The user does not distinguish between "the feature is bad" and "the backend could not keep up." They experience one thing: the product is bad.
Decision 3 — Choose the wedge over the perfect launch
The trade-off every PM faces: hold until it is perfect, or ship when it is good enough. He refuses both extremes and describes a third path:
"Let's not give a half-baked product. Limit the features, narrow it down — a wedge approach, where we can have only very few things to start off with, and then we can iterate based on the feedback."
The distinction is precise and often missed. A narrow product that is complete is not the same as a broad product that is half-finished. Cut scope, not quality. Then iterate — on the model layer and the infra layer both.
Decision 4 — Optimise for the impact radius, not the title
His answer on what changed most at Microsoft is not about seniority. It is about the blast radius of a decision:
"What I would have worked on in Shell impacted maybe hundreds or maybe a thousand. But here it impacts thousands and maybe more than that."
At that scale, the discipline inverts: "a small change might create a big impact." The skill being trained is not shipping more, it is understanding consequence — which is why he frames the shift as moving from building features to keeping very large distributed systems running.
Mental models
Infrastructure as the foundation layer
His framing: features and data blocks sit on top of a foundation, and the foundation maps everything above it. "If there will be something wrong, things will fly and it will get escalated." Companies that treat this layer as mission-critical are not being conservative — they are protecting every feature above it.
The four elements of any product
Asked what a PM must hold in mind before building anything, he narrows a long list to four:
"Latency, performance, memory optimization, and at the same time cost. These are the four elements which are very critical for anyone to manage a product — and I would not say only an infra product. Because without all these three or four elements, the product will not survive."
Note the last clause. He is explicit that this is not an infrastructure-specific checklist. It applies to any product, because every product eventually meets its own limits.
The magnifying glass
His model of an AI system has four layers: the application layer where intent is expressed, the model layer, the data and reasoning backend, and the servers underneath. The image he uses for the middle is the useful part:
"Model is just like a magnifying glass which basically looks at the data."
A magnifying glass does not create anything. It enlarges what is already there. Which is exactly why the layer underneath decides the ceiling — and why he insists the foundation must be "a solid foundation of good data, not general data."
From assistants to agents — and why metadata suddenly matters
The shift he keeps returning to: "we were talking about assistants in the past. Now we are talking about agents." An assistant responds to instructions. An agent acts on intent — and intent has to be interpreted.
That is a data problem before it is a model problem. "We don't need only data, we also want to know what that data means." Metadata — data about the data — is what lets a reasoning layer work out what a request actually means. He is realistic about the bar, too: the reasoning does not have to be perfect. "It may not be 100 percent, but it may be at 70, 75 — also not bad. Something good to start off with."
Systems thinking as a debugging discipline
He credits systems thinking as the habit that matters most in data and AI work: "you not only look from the experience point of view, but you look at the holistic system." Bad experience is a symptom. Underneath it is latency, underneath that an API, underneath that the backend. And the corollary he draws is a warning: if you intervene in a system, understand how big an impact that intervention can create.
Frameworks
Framework 1 — The three-way roadmap tension
Every roadmap decision, he argues, is a choice between three competing claims — plus customer requests arriving on top of all of them:
- Weak spots — fixing what is deficient in your own product
- Parity features — "if a competitor has it, I also need to have it"
- Differentiation — the things only you would build
Reading the market is what tells you the ratio: your own strengths and weaknesses, competitors' strengths and weaknesses, and where the field is heading next. His standard for resolving it is deliberately modest — "I'm not saying that we have to cover everything, but it has to be meaningful" — favouring whichever feature delivers the biggest value "without disrupting your engineering."
Framework 2 — The five work streams of data analytics
For anyone entering the data space, he lays out the pipeline as five stages: ingestion → transformation → processing → curation → reporting and consumption. Curation is the hinge — once data reaches that layer it is ready to be consumed. His advice for newcomers is to learn the fundamentals of all five rather than specialising immediately.
Framework 3 — Product critique as a training method
The most actionable thing in the episode is a habit, not a framework, but he describes it with enough structure to copy. Take a product you use daily. Then interrogate it in writing:
- What did they implement, and what did they get right?
- What is bad about it?
- What could they have done differently?
"I'm quite critical about a couple of products as well. But as long as I have that particular frame of mind — the lens to look at the things — it would be good to be a little critical of a few things."
He is careful to qualify the mode: constructive and structured, not cynical. And his justification is that this is precisely what product thinking is — especially now, because "new products which are coming up are not out-of-the-blue products. They are complementing the existing product stack, but in a more refined, better way." If you cannot articulate what is wrong with what exists, you cannot see what should come next.
Framework 4 — Writing as prompt engineering
The strongest claim in the episode is that clear writing is now a technical skill, and the logic is worth laying out as a chain:
You cannot instruct a system you cannot describe a problem to → you cannot describe a problem you have not structured → so structuring your thinking is upstream of everything. "Try to comprehend your thought process in a more nuanced way, which will make your prompts a little smarter — because we all are prompting only right now."
He does not dismiss technical fluency; he says understanding the basics is good. His point is about relative return. Low-code and no-code tools keep absorbing the mechanical work. The thinking does not get absorbed.
Lessons
The person you are selling to may understand the product better than you. The valve years gave him no room to fake expertise, and that constraint produced the habit that carried through every later role: start from the user's actual problem.
Ask why the requirement exists, not just what it is. The chain he models — why this requirement, why this problem, why now — is what separates a product owner from a ticket router.
Influence without authority is a real operating mode. He built and staffed a team at Shell as product lead, not people manager, and it became the model other groups copied. He also notes the hidden cost he avoided: people management can consume half your time.
A ceiling is a signal, not a complaint. He left advisory work because "advisory always has some limitations" — not because it was bad, but because he could see its boundary. Naming the boundary is what made the next move obvious.
Expectations move faster than technology. His read on AI is not that the engineering changed, but that user tolerance collapsed. Judgment now arrives in a fraction of a second.
Diversify your inputs deliberately. His main scepticism about AI is governance — and specifically recommendation loops: "if you like something you get the extreme version of that, and then you get into that particular loop." His countermeasure is to cultivate genuinely diverse interests so the model gets balanced signal, and you avoid "some bias for a specific action."
The books he names: Measure What Matters, a systems-thinking text he was rereading at the time, and Hooked — the last of which changed how he evaluates everything: "now if I use a couple of products on a daily basis, I always need to look at what is the hook factor here."
Actionable advice
If you want to move into product from a non-technical domain, do what he did: find the adjacency. Valves to an energy MBA to energy consulting to energy trading products to cloud data platforms. No single jump is implausible. The full distance is enormous.
If you are early in your career in AI or data, his answer is unambiguous — learn to write and structure thought before you learn another language. Understand the basics of code; invest in comprehension.
If you are a PM deciding when to ship, narrow the scope rather than lower the bar. Wedge in, gather feedback, iterate across both the model and infra layers.
If you are building anything at scale, put latency, performance, memory optimisation and cost on the table at design time — and put the scale curve in the roadmap before the users arrive.
If you want to develop product judgment without a product job, start the critique habit this week. One product you use daily, in writing: what works, what does not, what you would have done differently.
If you are worried about AI narrowing your thinking, treat your own information diet as a system to be managed. Deliberate diversity is the defence against the loop.
Final thoughts
The title of this episode promises a cloud PM playbook, and the episode delivers one — the four elements, the roadmap tension, the wedge, the layered model of an AI system. But the argument that lingers is quieter and slightly subversive.
Kunal Parekh has spent fifteen years moving toward technical depth: valves, consulting, product ownership, and now the control plane beneath some of the largest data workloads at Microsoft. He has every reason to tell an ambitious 25-year-old to go deeper on the stack. He says the opposite. Learn to write. Structure your thoughts. Be able to say clearly what the problem is.
It is not a soft answer dressed up as wisdom. It is a claim about where leverage has moved. When low-code tools absorb the mechanics and every interface becomes a prompt, the constraint stops being what you can build and starts being what you can articulate. His own retrospect points the same way — not I should have learned more technology, but I should have documented more, comprehended more, written more.
The through-line of the whole conversation is the phrase he keeps reaching for without ever quite defining: the other side of the fence. Advisory to hands-on. User to builder. Consuming the platform to owning its control plane. Each move traded a comfortable specialism for a harder question — and the tool he credits for making each crossing survivable is not technical at all. It is the ability to think clearly enough to explain what you are looking at.