Scaling Google’s data platform
Dhirendra Sinha quit a comfortable job in Singapore because he wanted to decide what to build rather than how. His first months at Google felt like navigating a sea without a compass — and that turned out to be the point.
Watch the full episode on YouTube
Executive summary
Dhirendra Sinha has spent a decade and a half in data — from a TCS data warehousing project that happened to be the fourth-largest database in the world, through startups, through Informatica, and now at Google, where he builds the products that move customer data from an enormous variety of sources onto Google Cloud.
The episode is a close look at how product management actually works inside an engineering-first company at planet scale. Three ideas carry it.
First, the career decision the whole thing turns on. Working in Singapore for a Chennai-based company, comfortable and well cushioned, something clicked:
"What I have been doing was more in terms of how to build. But I wanted to shift gear and see what to build."
He quit — "it was not easy, because you have a lot of cushion over there" — went back to India and joined a data management startup. That sentence is the cleanest one-line description of the move from engineering into product anyone gives.
Second: at Google, conviction is a job requirement, not a personality trait. "Google is an engineering-first company, so as a PM your conviction about the product needs to be very strong." Engineering is, in his words, rock solid. You do not direct it; you persuade it — and you persuade it with evidence.
Third, and the most disorienting part of the story: Google gave him no path. Nobody greeted him on his first day. A set of emails arrived, some training to work through asynchronously, and that was it.
"I checked my letter of appointment — did I choose the company which I wished for?"
His conclusion, a year in, is that the absence was deliberate and the mechanism works: "there is no defined path. You have to make your own pathway."
The story
The first job mattered more than first jobs usually do. Fresh out of engineering, at TCS, he landed on data warehousing projects for a major telecom — and one of the warehouses he helped manage was the fourth-largest database in the world.
"That gave me exposure in terms of how the data management field was — the scale of that, and how the volume and the veracity differs from one project to another."
Startups followed, in various shapes and sizes. Then Singapore, then the decision, then a data management startup back in India.
Informatica came next, and the change was one of magnitude. Startups had taught him the craft; Informatica put that craft in front of a customer base large enough to change what the craft meant. "The problem we were serving was impacting a magnitude of customers which was very different from the startups I came from."
Google was the same instinct applied again, one level up:
"Companies like Google are solving planet-scale problems. That's something you always desire for as a PM, because you have the ability to impact lives of a magnitude of customers, in different segments and verticals."
He arrived, by his own admission, carrying baggage: "I was pretty much sure this is another drill for me. I'm going in a company which is pretty big in size, I'll just land over here, start my job and start delivering on day one."
"Now that's not how Google works."
What followed was months of feeling lost, which he now reads as the onboarding itself. The advice he extracts is specific: in the first six months, focus on understanding the culture and set aside everything else. "You may feel like you are lost, but at the end of the day you are navigating in the right direction."
The other surprise cut the opposite way. For a company of that size, he found Google startlingly quick to change: "it's not very often that you see a company of this size change its strategy to adapt to the market, to adapt to competition."
Key decisions
Decision 1 — Let the people building it decide
The structural difference he highlights most is where authority sits:
"Here at Google, decision making is grounds up. People who build the product are the ones who take the decision."
Specifically, a trio: the PM, the lead engineer working on the feature, and the UX designer. All three have to be in sync — "in order to create that symphony" — and the decision is then escalated for stakeholder agreement rather than handed down.
Which is also why conflict has no procedural fix. His answer is communication, defined precisely: clarity, concision, and enough thoughtfulness "to respect others' decision or thought process as well." And a framing that does the real work — "it's not that they are UX people, they are engineering. You need to act as a single team."
Decision 2 — Navigate by the lighthouse
Asked how to balance innovation against a customer base large enough that no request can be casually ignored:
"You need to have your vision very clear. Once you have clarity in terms of the vision, it acts as a lighthouse."
Both tactical and strategic work then get aligned to that bearing. In practice they explicitly allocate bandwidth — a percentage, or a number of people — to staying ahead of the curve. And the ratio moves with the product's lifecycle: a mature product can lean into innovation, while one still finding the market has to listen harder to its users.
Decision 3 — Prioritise by value, not by backlog
The line that reframes the prioritisation question entirely:
"It's not about clearing the backlog. It's more about how, and what level of value addition you can do to the customers."
He is candid that this means saying no to real customers with real needs — and that the test is the vision. "Many times, when we see that it doesn't add value for us, even if it serves 10 different customers — if that doesn't add up to the vision of the product, we don't go that path."
The reason is structural rather than stubborn: "it's not very easy to scale your product if you start catering to all the requests which are coming your way."
Decision 4 — Bake in reliability, do not add it
For enterprise products, reliability is not a quality attribute to be tuned later:
"Reliability can't be an afterthought in an enterprise product, because you are impacting the lives of your customer. You are impacting the way your customer does day-to-day business."
This is enforced by process. A feature in preview waits roughly six months before it can go GA — and the approval can still be refused. "I have seen cases where you have done preview six months back, but in that time frame some customer raised that they are not satisfied, or the reliability angle or the SLA angle has been breached."
Mental models
Reversible and irreversible doors
His go-to decision model, borrowed from Jeff Bezos:
"If you think of a problem statement which can be reversed, you can be pretty quick on that — take a quick decision, move on. If there is a one-way door, you need to be very cognizant that you need to take time, think logically, and then take a decision."
Enterprise scale is about impact, not headcount
A correction worth internalising if you work on B2B products inside consumer-scale companies. His products serve tens of thousands of customers — nothing next to Maps or Pay. That does not make the stakes smaller:
"Their whole reporting may stall because there is a small issue which is conflicting — maybe just a data type. And the whole thing would change how the customer sees the report."
Segment by maturity, not by revenue
His most contrarian framework. The instinct is to tier customers by what they spend. For data products he tiers them by where they sit in their own data journey:
"Some customers might be pretty advanced — they're on cloud, they're trying to use AI, building models for fraud detection. Financial companies are way ahead of the curve, especially because they want to mitigate risk."
Google supplies org-level segments — enterprise, SMB — but services are given room to define their own. He describes his as "aligned to what is there at Google, but not entirely the same."
Sell the lifecycle, not the service
A discipline forced by working inside a platform. His product handles one stage of the data lifecycle, but a customer's problem spans all of it — creation, governance, curation, metadata, consumption.
"When you go to the customer, you need to tie in this story of the entire data lifecycle for them to truly understand the value."
The value is in the stitching, not the single service.
Frameworks
Framework 1 — Three signals for positioning
Working for a cloud vendor means an exact replica of your service exists on every competing cloud. Three inputs, in increasing order of usefulness:
- Competition — necessary but limited, because "competition will drive you in terms of a catching game." You fix the missing feature, then the next one.
- Customer feedback — the surprise channel. "You may have thought your product can work in n number of ways. There is an n+1 use case which your customer would come with, and you will be surprised."
- Innovation — the only one that gets you in front. "You need to drive where the market would go... think from a five, ten year perspective."
Framework 2 — Finite bandwidth against an infinite pipeline
He names the permanent condition of enterprise product management: engineering capacity is fixed, and the request queue is not.
The resolution is a value matrix that prices both sides. "You might be building a very good feature which impacts a magnitude of customers, but it may require a ton of investment which you can't do right now."
And when the answer is no, he pushes back explicitly rather than deferring: "this is a new thing you are asking for, maybe the use case is not getting covered, but this is not where we are heading right now." Genuine bugs are the exception — those go straight to engineering.
The subtlety is timing. Innovation "doesn't always give you fruit right away." Some of what you build is for two years out, and the value calculation has to account for value that has not arrived yet.
Framework 3 — How AI actually changed the PM job
Not speculation — the two places it changed his week.
Competitive research. What used to take two or three days to assemble now needs the right prompt. "It has changed my life as a PM drastically."
Customer feedback analysis. A customer sentiment study that would have taken the team at least a couple of weeks was done "in a couple of hours, and I was ready with the presentation the very next day."
Both feed the same downstream need — conviction with evidence. In an engineering-first culture, the difference between being heard and being questioned is a number:
"When I present to my stakeholders, I have a data point that says 50% of my customers are not able to use this feature because of XYZ. That becomes a pain point, and I can say it with much more conviction rather than just saying my customer is not able to use that."
He also relays the internal expectation, stated bluntly in a session he attended: "being a product manager, if you're not building something using AI at Google, you are not doing the right thing." Knowing is not the bar. Building is.
Framework 4 — The feedback loop is the go-to-market
"When we talk about GTM, people think it's flashy marketing, flashy product launches. It's not just that."
The actual loop: take feedback, iterate and refine, go back and show the customer what changed, collect the next round. Customers are "the champions of your product — they will tell you what exactly the product is good at and what the product lacks."
When the feedback is bad, empathy first, then honesty. Some of it becomes a priority; some of it gets a clear no with a reason.
Lessons
Escalation at Google is unusually heavy in both directions. Decisions are made bottom-up, yet "every feature passes VP-level approval" before it ships to that many customers. And on incidents: "I have never seen a company throwing so many hands towards it." Stakeholders he has never spoken to appear, demanding a clear RCA — what happened, what was done, what prevents recurrence. Multi-region impact reaches the highest levels of the company.
Dogfooding is a genuine perk. Googlers get the latest builds before the market. In his first three months, with little else to do, he tested products well outside his remit and filed feedback — which is also how he learned the culture.
Scale and latency are the two enterprise constraints, and AI has tightened both: models need data fed quickly and in volume, and "that's a competitive edge — you have volumes of data, you have variety of data that you are feeding into AI models."
Geography is mostly handled beneath him. European data residency rules mean data cannot leave the country, and GCP does the heavy lifting of standing up regional infrastructure. His service complies and checks the boxes.
The product he admires outside Google: Datadog, for observability — "unifying all the log management, all the issues which you are not able to troubleshoot at a low level, into a unified view."
Books: The Design of Everyday Things by Don Norman, and Insanely Simple, written by Apple's creative director from his time with Steve Jobs — which he values for what it says about "the conviction with which you need to work with your teams."
And his advice for PMs in the AI era: "Shoot for the moon. Don't think of incremental changes, because as a PM you need to think about bigger things — and this is possible today."
Actionable advice
If you are moving from engineering to product: the question you are trading is how to build for what to build. If that trade is what you want, the comfort you are giving up is the price, not the argument against.
If you are joining a much larger company: budget six months for culture and ignore your own impatience. Feeling lost is not evidence you chose wrong.
If you work in an engineering-first organisation: bring data, not requests. Conviction backed by a number survives scrutiny that conviction alone does not.
If you are drowning in customer asks: test each against the product vision, not against the backlog. Push back explicitly when the answer is no, and give the reason.
If you are deciding how fast to decide: ask whether the door is reversible. If it is, move now.
If you are a PM and not yet building with AI: start. Competitive research and customer feedback analysis are the two places the return is immediate.
Final thoughts
The most useful thing in this conversation is also the least comfortable: that the disorientation of his first months at Google was the system functioning correctly. No greeting, no defined path, no clear brief — just enough time to work out how the place actually thinks before being asked to have opinions about it.
That runs against every instinct a senior hire has. You arrive wanting to demonstrate value quickly, carrying the baggage he describes carrying — this is another drill for me. The organisations that let you do that get a fast start and a shallow one. The ones that make you build your own pathway get someone who understands the terrain before they start rearranging it.
It also explains the rest of his answers. Lead with the problem statement rather than the solution. Stay with the problem before devising anything. Segment customers by where they are rather than what they pay. Sell the whole lifecycle rather than your slice of it. Each is a version of the same discipline — resist the urge to act until you have genuinely understood the shape of the thing.
His one-line product philosophy, offered at the end, is exactly that:
"Lead with the problem statement rather than the solution."