From data chaos to business clarity
Himant Goyal was the business analyst on Apple Pay's Citibank launch. Now he runs consumption analytics at Informatica, where his central claim is blunt — for a SaaS company, infrastructure is the revenue engine.
Watch the full episode on YouTube
Executive summary
Himant Goyal spent nearly two decades getting to the least visible part of software. He started as an engineer at TCS in 2006, wrote code for four or five years, moved to the US, and pivoted into product almost by accident. Today he owns consumption analytics at Informatica — recently acquired by Salesforce — where his job is to collect, transform and organise every signal customers generate while using the product.
The episode is about data platforms. Its actual subject is what happens to a business when the invisible layer underneath it is weak.
First, the claim that reframes the whole conversation: "For any SaaS company, infrastructure is the revenue engine. That's how I put it."
This is not a metaphor about importance. It is a description of mechanics. Because SaaS moved to consumption pricing, the system that measures usage is the system that produces revenue. "Every API call is some dollars or some cents." If the telemetry breaks, you do not lose a dashboard. You lose the ability to bill, to spot churn, and to see expansion coming.
Second: consumption pricing changed the nature of the customer relationship. The old model was a license bought and renewed. The new one is continuous:
"Now every single day the customer is re-deciding whether your product is worthy of what they are paying."
His own example is disarmingly small — he bought a Zoom license, did two meetings that month, and will think twice about renewing. Scale that logic across a customer base and "you are selling millions of micro-commitments."
Third, and the line that most directly challenges how product managers spend their time: "A PM's job is not to ship features. A PM's job is to go for the kill."
His estimate is that 60% of the problems brought to you are not worth solving. Sharper still: "half of the time I don't even have to solve a problem — there is some solution that already exists, people do not have the knowledge."
The story
The pivot happened in New York in 2012.
He had been an engineer since 2006 — bachelor's from NIT Bhopal, then TCS, then four or five years of writing code. Coding taught him the craft but left a persistent gap, and he describes it as the thing that pushed him out:
"When you do programming, you're writing code, you're writing specifications, but you don't know what really goes on. What is the customer experience? What is the customer buying? What are we selling?"
Those questions get answered, he notes drily, "on the line of fire" — on escalation day.
In 2012 he became a business analyst on a TCS engagement with Citibank North America. That was the beginning of product work, even though the title had not caught up yet.
Then, in 2014, the moment he still names first. Apple launched the iPhone 6 with Apple Pay, in collaboration with Citibank North America — and he was the business analyst on it.
"That was my first opportunity to work on a product which customers use on the street."
The distinction matters to him more than the prestige does. He had spent years on systems that power ATMs and online banking without ever building the thing a person touches. "The real joy of product management is when you see people on the street using your product."
In 2015 he moved from New York to California and joined Bank of the West, again as a business analyst — but the bank was mid-transformation from project methodology to product methodology, and the role converted underneath him. He became a product manager officially, and built the bank's master data platform.
He is candid that none of this was designed: "it's nothing that I planned to be a product manager. It has been a very organic evolution." What was constant was the curiosity.
Now at Informatica he handles the telemetry side — every API call, every transaction, what time it happened, which source and target database were involved. "All of that data is the gold."
Key decisions
Decision 1 — Treat master data as a transactional system, not an analytical one
His explanation of master data management is the clearest part of the episode, and he builds it from a consumer example. You use Gmail, YouTube and Drive. Each has its own localised database. Somewhere you need a golden system that consumes all of it and produces one profile of you.
Banking works the same way — checking accounts, certificates of deposit, mortgages, home equity, all in separate systems. His concrete test:
"If a rep in the call centre has to call me, he needs my latest phone number. I go to a bank, I update my phone number on just a checking account. How does that phone number get propagated everywhere? That is where master data comes in."
The architectural point underneath: data platforms come in two kinds, transactional and analytical. Master data belongs to the transactional side because it must respond in real or near-real time — "less than a minute or less than 30 seconds." Analytical platforms came first historically, funded by banks and insurers with regulatory reporting obligations. Master data exists because the world moved to real-time.
And it is industry-agnostic. He runs through utilities — PG&E may work with 30,000 suppliers — plus hospitals, insurers, and retail.
Decision 2 — Build the platform for the growth you have not had yet
"You cannot be just living in the present. With data platforms, you have to live in the future."
His working standard: at any point, the platform should support at least 2–3× growth in the next six months. His cautionary example is Arattai, the Indian messaging app that grew 20–50× within a month and could not serve the users it had won.
The Salesforce acquisition made this concrete for his own team. The announcement came eight or nine months before the conversation, and planning started immediately, because "their customers are like 50× than us."
The trap he flags is assuming the curve is straight:
"Let's say today I'm supporting 3,000 users with a million. Would I be supporting 6,000 users with [two] million? No — it's never linear."
Which is why capacity, computing, storage and pricing all have to be replanned together at each step.
Decision 3 — Shield the engineering team first
Asked how he works with engineers, he gives four rules in priority order, and is unambiguous about which comes first:
- Shield them from the chaos. "That's the number one priority for a PM. If your engineer is not focused, you cannot deliver a product."
- Absorb the ambiguity. What engineers need is someone who takes the unresolved questions and returns informed decisions so they can progress every day.
- Pass on the credit. Product managers sit closest to the business and collect praise by default. "I'm a middle man here, to be honest."
- Connect the code to the revenue. Engineers deep in delivery rarely see how a single line of code produces money. Making that visible is the PM's job.
Mental models
The nervous system
His description of owning a data platform, and of why the stakeholder load is unlike any other product role:
"You have been appointed to manage the nervous system of the company. Just like every part of the body is talking to the nervous system — it's the same with the data platform."
Everyone arrives with a demand, and every demand is urgent: "whoever talks to a product manager, they always say this is very important, this is very important." He deals with 60 to 75 services on the consumption side alone. Ruthless triage is not a style preference; it is the only way the role functions.
Feature thinking versus platform thinking
The most immediately usable idea in the episode, and he insists it is a dual mindset rather than a hierarchy.
Feature thinking answers the user's next demand. Platform thinking asks an ecosystem-level question: what foundation would make every future feature cost a fraction of what it costs today?
His arithmetic makes it concrete. Build separate solutions for sales, finance and customer success and you spend roughly $200,000 each time. Build a platform and the first one still costs $200,000 — but the next feature ships for under $50,000.
Then the test that turns it into a decision rule:
"If you do not make the platform scalable — which reduces your cost to do the features in the future — you are not building a platform. You are only building features."
Anything else is a point solution.
Hunter, not farmer
His framing of what separates an average product manager from an exceptional one. The average PM ships features, documents them, writes user stories, follows up with engineering. His verdict: "that could be 10% of your job."
The exceptional PM hunts valuable problems, focuses on outcomes, and moves on fast when something fails. "It's a game of mindset, skills and behaviour that has to come together."
Art and science
A clean split he uses when assessing people. Science is learnable: Python, SQL, the technical apparatus. Art is analytical ability, communication, and the judgment to read data properly. He notes that he has watched college students clear PM interviews that people with fifteen years of experience fail — because the deficit is rarely in the science.
Frameworks
Framework 1 — Where consumption data creates and destroys revenue
Because pricing is consumption-based, the telemetry is an early-warning system running in both directions.
Downside — churn. A license expires in three months. If you cannot see that adoption is low, you cannot intervene, and the customer leaves.
Upside — expansion. A customer is consuming at a high run rate and will hit their limit in two months. If you only discover this after they hit it, they have already been over-consuming, your COGS has risen, and you are losing money on them. Spot it early and it becomes a commercial conversation instead.
"There is a downside, there is an upside. That is where data infrastructure helps companies make those revenue decisions."
He notes that roughly 70% of B2B SaaS companies now run on some form of consumption model.
Framework 2 — What leadership actually wants to hear
When a PM goes to executives, the instinct is to talk about the product. His correction: talk about company outcomes, and know which outcome each leader owns.
- Product leadership — how the product is performing
- Sales — quarterly numbers
- Customer success — adoption
His illustration from banking is the sharpest version: a bank wants to know whether its mortgage cycle beats the competition. "If other people are giving a loan in 20 days and I'm giving in 25 days, obviously I will lose the business." That is the altitude the conversation happens at.
And bring numbers, always: "Even if I have to stay awake all night, I will have my numbers ready. Because numbers speak for themselves."
Framework 3 — What LLMs should and should not do to your data
A useful boundary from someone running a data platform in the agentic era. LLMs do two kinds of work: summarisation and reasoning, and computation. His position is that the first two are ready and the third is not:
"We do not want LLMs to generate our metrics. We want them to be more accurate."
His example: ask what revenue was this quarter, and an agent still has to call a database, pull the sales figures, and only then use the model to render the number in readable English. The number comes from the platform. The sentence comes from the model. Confusing the two is how you get confident, wrong reporting.
Lessons
Curiosity is the actual entry requirement. His advice for aspiring PMs is not a certification but a habit: look at anything — a ball pen, a coffee cup, a notebook — and ask how you would build it. "That's what makes you a product manager."
A successful PM knows how to code. He is unusually firm here: "I know a lot of people say, I'm a product manager, I do not code. Then you are not a product manager." The reasoning is practical rather than territorial — if you cannot pull your own data, you cannot build your own story for leadership, and you wait on someone else. "You are dependent on others. It will slow you down."
Moving industries means letting go of the old vocabulary. Coming from banking into Bay Area technology, he found the background actively in the way: "you have to forget the banking to find a job in technology." What transferred was not domain knowledge but curiosity and data skill.
Stay current deliberately. He subscribes to data engineering digests and AI newsletters, and treats it as maintenance rather than reading.
The frameworks matter less than people think. "There are so many product management frameworks that people use, but it's all art. There's no science in there."
He is teaching his eight-year-old to write prompts to build things — which tells you where he thinks the entry point to building has moved.
Actionable advice
If you own a data platform: work out the magnitude of each problem before touching it. Solve the top 40% that changes an outcome, and check whether a solution already exists before building anything.
If you are pricing a SaaS product: treat the consumption telemetry as revenue infrastructure with a matching reliability bar, not as analytics.
If you are scaling: design for 2–3× in six months, and re-derive capacity, storage and pricing together at each step. Assume nothing is linear.
If you work with engineers: shield them, resolve ambiguity for them, give them the credit, and show them how their work becomes revenue.
If you are deciding between a feature and a platform: ask what the next feature will cost. If the answer is unchanged, you are building a point solution.
If you are heading into an executive review: bring the number that leader owns, not the update you want to give.
Reading: Decode and Conquer for people entering product management. He is also about 70% through writing his own, on the shift "from data pipelines to products."
Final thoughts
The most interesting thing about this conversation is how far the centre of gravity has moved. A decade ago, the data platform was plumbing — necessary, unglamorous, discussed only when it broke. Himant Goyal's argument is that consumption pricing quietly promoted it into the commercial core of the business, and most organisations have not updated their mental model to match.
If every API call carries a price, then the system that counts API calls is not reporting on the business. It is the business, in the only form the finance team can see. Which makes the reliability of that layer a revenue question, the design of it a pricing question, and the person running it something closer to a general manager than a back-office owner.
His career reads as a slow move toward that realisation — from writing code without knowing what was being sold, to a launch people used on the street, to owning the layer that determines what a company can charge and whether it can see its own customers clearly. The through-line is the question he says should never switch off, whether you are looking at a data platform or a ball pen: if I had to build this, how would I build it?