SaaS spend management, and the two ways you are overpaying: Munish Gandhi of Productiv

Most SaaS spend management conversations are about cutting licenses. Munish Gandhi's point is that there are two entirely different problems hiding under that heading, and only one of them is solved by removing seats.

Gandhi is co-founder and COO of Productiv, a SaaS management platform backed by Accel, Norwest, IVP, Okta and Atlassian. Before that he was a revenue operations leader at LinkedIn, with earlier roles in corporate strategy and technology at Bain, HP, Oracle and Equinix.

Michael opens with the product rather than the career, and explains why: when the economic climate turns, companies cut headcount, and the other place to look is software spend, which is usually murky.

How we got here

Gandhi's account of the last decade is worth reading before you audit anything.

There has been an enormous expansion in SaaS. Pick any job title in America, he says, and there are at least twenty and probably fifty companies building software for it.

Combine that with abundant capital and a growth-at-all-costs mindset, and you get two consequences: very loose governance over which applications get bought, and very loose governance over whether the ones you bought were ever properly implemented.

Now IT, finance and CEOs are trying to optimize cost, reduce risk and build operating discipline. And the arithmetic is simple. At a technology company, your largest cost is people. Your second largest is very likely software.

The numbers Michael cites frame the opportunity: Gartner forecast annual SaaS spend growing more than 19% to $195 billion, with roughly 25% of it underutilized or overdeployed. He offers his own example of finding and removing 40 completely unused Asana seats.

The two kinds of underutilization

This is the distinction to take away.

Too much of one application. Gandhi points at the incentive structure first: buy more volume, get a lower unit price. Then he names what he calls the euphoria at purchase, where you genuinely believe the whole organization will use this tool. Actual utilization lands well below what you bought.

His sharpest example is entitlements rather than headcount. With an e-signature tool, most people only need to sign things. They do not need the permissions required to create new envelopes. But companies buy one license type for everyone, because nobody asked which people need which capability.

His estimate is that on a single application, a CRM for instance, this is worth 20 to 30% of the cost.

Too many applications. This one he finds more interesting, and its cause is not procurement at all. It is hiring.

His formulation is the line I keep coming back to: when you hire new people, you are hiring behaviors. Someone arrives having used a particular project management tool at their last company and needs it to be productive. Multiply that across a hiring wave, add loose governance, and companies end up with six or seven tools in the same category.

The cost is not only financial. Past a certain point, having too many tools is actively bad for productivity, because working with finance means one tool and working with marketing means another.

The fix is harder than cancelling seats. It requires a standard, a set of sanctioned tools per category, and companies that do it have shut down hundreds of thousands of dollars of duplication.

Governance at the point of entry

Gandhi's answer on risk and compliance starts by returning to first principles. Why do you buy software at all? To streamline processes and make people more effective. SaaS changed the delivery and billing model, not the reason.

His most mature customers run what they call a software architecture review board. Every purchase goes through it. A head of sales bringing in a new sales tool explains why, and the board checks two things: whether it duplicates something the company already has, and whether it meets the compliance posture, whether that is SOC 2, sector-specific standards for financial companies, or FedRAMP if there is government business.

His principle is stated plainly: you control for compliance at the point of entry, and it cannot be an afterthought.

What makes it work is framing, and this is the part operators should copy. The CEO normally sponsors it, and the message is not that buying tools is prohibited. It is that the company should get the benefit it is paying for and should not break something that surfaces later in an audit. He calls it bringing an ownership mindset to software purchasing.

When you have no point of entry to control

Michael raises the case that defeats all of this: the email from an account executive noting that 60 people at your domain are already using their product, and would you like to consolidate onto an enterprise plan. Usually the product is freemium, and you never had a point of entry to control.

He connects it to a live risk, citing employees pasting proprietary code into AI tools and the well-publicized consequences.

Gandhi's answer is that visibility has to come from multiple angles at once, because no single one catches everything. The financial ERP shows what people are expensing. Login data shows who is authenticating with a company email address. Network integrations, including cloud access security brokers, catch the rest.

Together those paint the picture that 60 people are using something on a credit card, so you are not surprised.

His description of the surprise is the version every finance leader will recognize: you need to sign this by this date, or 80 people at your company lose access. And the CFO's reaction is to ask who you are and why they have never heard of you.

His summary: unless you have good visibility, how can you make decisions.

What AI is actually useful for here

Gandhi splits it into two problems, which is a cleaner framing than most AI answers on this show.

Collating information. Combining what they know about a customer with publicly available information about what tools exist, so the picture is contextualized rather than purely internal. His concrete example is fuzzy matching across the finance system, where someone has expensed a software tool but coded it as entertainment and meals, and the system matches on application and vendor names to catch it.

Deciding what to do about it. This is where he wants to be a copilot for the procurement, IT and finance people using the product. Flagging that an application went from 10 users to 60 in the last fortnight, so nobody is surprised downstream. Or intervening when an employee starts buying a new tool to point out the four existing tools that solve the same problem.

His statement of intent matters more than the mechanics: the goal is not to shut things down, it is to help people make the right decisions.

Contracts, and negotiating from evidence

Today Productiv extracts around ten attributes from a contract using a combination of people and machine learning: renewal date, what was purchased in terms of license types and quantities, whether there is an auto-renewal clause. The limit is cost, since reading and validating contracts is genuinely expensive.

Where Gandhi sees the technology helping is going from ten attributes to fifty, and then, more valuably, making contracts comparable.

That comparison is the interesting part. Do you have the right terms relative to companies like you? What are the variances in service level agreements, in overage fees? He points out that the larger the contract, the more complex it becomes, and that no human is going to read fifty contracts to work out which terms actually matter.

So the output is procurement leverage: here are the terms to focus on, here is where you should push back, and here is where your spend with this vendor should be earning you better terms.

Michael's reaction captures the appeal for any operator. Taking actual usage data, comparing it against what the contract assumed, and having the analysis produced automatically is the difference between negotiating on instinct and negotiating on evidence.

Procurement is a coordination problem

Gandhi's description of why software buying goes wrong is not really about software.

Take any tool. The owner is usually in the business, so for a sales tool that means the head of sales and revenue operations, probably marketing, IT for architecture, security, and legal for the contract. Many of those people hold decision rights or veto rights.

The questions that need answering are straightforward: does this overlap with something we have, does it meet our compliance posture, does it integrate with the systems it needs to.

His diagnosis of the failure is one sentence: those questions today get lost in email.

Which is why Productiv built a workflow product for it. And his framing of the underlying problem is the best line in the episode: just because you can buy software does not mean you know how to buy software.

Michael notes the obvious irony, that this is SaaS for managing your SaaS, and then explains why he pushed the product discussion to the front of the episode. In conversations with other operators, the recurring picture is a spreadsheet with 170 applications and 35 columns of contract terms, and a hope that nobody misses a renewal. Add offboarding, where leftover access is a genuine security exposure, and it is a real operational problem rather than a procurement footnote.

The accidental founder

Gandhi calls himself an accidental founder, with a business school essay declaring that he wanted to start a company and roughly a decade passing before he felt ready.

The actual motivation was working with people he rated. His co-founders are Jody, the CEO, whom he describes as a strong product mind and a visionary, and Ashish, the CTO, who had built large engineering teams.

His own role was, in his words, everything else. Early customer success, sales, marketing, working out how to pay people, setting up payroll, getting the first legal contracts out, and starting to build an HR function.

The founding logic was three questions. Can we fund the company and get the product vision right. Can we actually build it. Can we operate well as a company.

On the role itself he offers the same taxonomy several guests have reached for independently. COOs come in different flavors: one that is essentially back office, one that is go to market, and one that is closer to a chief of staff running special projects. Because there was no go to market at the start, he began on the operations side building the foundation, and has spent recent years mostly on go to market.

What LinkedIn taught him about buyers

Gandhi's path to Productiv ran through a specific observation at LinkedIn.

He was on a small team turning what was then LinkedIn for Sales into a standard B2B product, on a motion that started with individuals trying it, then teams, and eventually earning an enterprise conversation with a chief revenue officer.

What he saw from that seat was both sides at once. The paths enterprise companies take to build large businesses, and the friction sitting on the buyer's side of the table. Nobody wants to negotiate with vendors. Nobody wants to be informed that a hundred of their people are already using something.

And at the same time, the productivity impact was real. These tools do make people more effective at their jobs.

The reframe that became the company came from his co-founder: getting everyone the right tools to do their job is a data problem. Hence the name.

His point about company building is one founders should sit with. You have to identify the initial entry point, because otherwise there is no company, and you only raise enough money for your first act. Governance and procurement were the most compelling problem they could solve immediately, but the larger ambition is connecting software to productivity outcomes.

Two things he took from LinkedIn

Plan to win big, with intellectual honesty. Unless you know where you are going, you will not get there. He credits LinkedIn with a culture of honesty both in setting goals and in assessing progress against them.

His articulation of what that means for a leader is genuinely useful. At any moment you should have a clear narrative of the business in three parts: what is going well and what you are excited about, what is not going well that you are actively working on, and what is not going well that you have consciously decided not to address, because you cannot fix every fire.

Relationships matter, and trust is earned. With customers, employees, partners and investors alike. His formulation: you need metrics to run a business, but you build a business with people.

The behavior it produces is his approach to every conversation. Go in with empathy, asking what the other person expects to hear and how you can help, rather than arriving with five slides and a message they are supposed to sit through and be impressed by.

Asked how LinkedIn actually built that, his answer is a collection of small things. Team meetings that opened warmly. New hire introductions at all-hands where people could be vulnerable and occasionally silly. And a leadership habit of asking what do you think, how can I help, how should we engage, which he contrasts with the alternative posture of holding someone accountable.

His summary is individual first: get to know people, stay curious, and rather than judging what someone is saying, work out why they are saying it.

The hour that decided everything

Gandhi's answer to the standing question is the collapse of Silicon Valley Bank.

A friend who works in banking called and asked whether they banked there. Told yes, he said that as a friend, Gandhi should drop everything, pay attention, and make a decision, and that he would not say more.

Gandhi pulled in the head of finance and the CEO immediately. His framing of what they needed is a good crisis instinct: being action-oriented does not mean you have to act, it means you need a clear opinion on how you are going to handle the situation.

What followed was an hour of calls, talking to other founders and to investors, collecting whatever data existed.

The decision was genuinely non-trivial. There were real commitments about maintaining balances, so acting had costs. But they banked almost entirely in one place and had payroll to meet.

After about an hour they concluded that the information was imperfect and the benefit of waiting was not there. They moved.

His articulation of the tradeoff is the clearest way to think about decisions like this: he would much rather be in the position of having all the cash secure and having broken a covenant, which is a good problem and hard to resolve, than have the money stuck and be unable to make payroll, which is a bad problem.

He calls it a crucible moment that now looks easy in hindsight.

The part he adds unprompted is the one worth keeping. Acting was not sufficient. They had to communicate immediately, to investors, to customers, because receivables were incoming and accounts had to change, and to employees, because questions were already appearing on Slack.

His conclusion: in a crisis you will never have perfect information. What matters is making a decision and then clearly explaining the rationale and the impact on everyone affected. That, he says, is what leadership is.

The 5 things I took away from this conversation

1. Separate too much of one tool from too many tools. They look like the same line item and they are completely different problems. The first is a licensing and entitlements audit worth 20 to 30% on a single application. The second is a standards problem caused by hiring, and cancelling seats will not touch it.

2. You hire behaviors along with people. This is the most useful reframe in the episode. Every new employee arrives wanting the tools they were productive with before, and without a category standard that is how you end up with seven project management tools. Worth addressing at onboarding rather than at renewal.

3. Audit entitlements, not just seat counts. The e-signature example generalizes widely. Most tools have permission tiers, most companies buy one tier for everyone, and most people need less than they have. That is invisible in a seat count and obvious in an entitlements review.

4. Compliance has to be checked at purchase. An architecture review board sounds like bureaucracy until you consider the alternative, which is discovering a compliance gap during an audit. Framing it as the company getting what it pays for, rather than as a block on buying things, is what makes it survivable.

5. In a crisis, decide and then communicate immediately. The SVB story is a good template. One hour of gathering data, an explicit acknowledgement that the information is imperfect, a decision made on which problem you would rather have, and then rapid communication to investors, customers and employees before anyone has to ask.

FAQ

What is SaaS spend management? The practice of establishing what software an organization actually uses, what it costs, and whether the spend matches the need. Gandhi splits the waste into two categories: buying more of a single application than people use, including permission tiers nobody needs, and accumulating multiple overlapping tools in the same category.

What does a SaaS management platform actually do? It provides visibility across every application in use regardless of how it was acquired, whether purchased by IT, by a function, by a team or on someone's personal card. Productiv builds that picture from the finance system, from login data tied to company email addresses, and from network security integrations, then layers recommendations on top.

Why do companies end up with duplicate software? Because hiring introduces it. New employees bring the tools they were productive with elsewhere, and without a sanctioned standard per category those preferences accumulate. Gandhi has seen companies running six or seven project management tools, which costs money and actively harms productivity.

How do you control shadow software purchases? By controlling compliance at the point of entry through a review process, and by maintaining visibility across all the channels through which software enters. Gandhi's most mature customers run a software architecture review board that checks every purchase for duplication and for compliance posture before it happens.

What licenses are companies most likely to be overpaying for? Ones where permission tiers exceed need. His example is e-signature software, where most users only need to sign documents but are given the entitlements required to originate them. He estimates a single major application can carry 20 to 30% of unnecessary cost from this kind of mismatch.

Also mentioned

• Productiv, its SaaS intelligence platform and procurement workflow product
• Accel, Norwest, IVP, Okta and Atlassian, the investors behind it
• Gartner's SaaS spending forecasts, source of the underutilization figures
• SOC 2 and FedRAMP, the compliance standards checked at point of purchase
• Cloud access security brokers, one source of application visibility
• LinkedIn Sales Navigator, the product motion that shaped Gandhi's view of buyer friction
• The collapse of Silicon Valley Bank, and the hour Productiv spent deciding what to do about it

Listen to the full episode

Munish Gandhi on Between Two COO's

Between Two COO's is hosted by Michael Koenig. Subscribe on Apple Podcasts, Spotify, or wherever you listen.