For folks listening who don't know, give us the elevator pitch. What is Zip, and what exactly are you tackling?

Zip provides one front door for any employee in an organization to request a purchase. Then we route that purchase for approval across all the different teams that need to review it, like finance, IT, legal, security and so forth, before connecting downstream all the way into the financial system or an ERP. We're a B2B SaaS company focused on solving for procurement.

Procurement is a massive category. There's a trillion dollars transacting across business spend of all shapes and sizes, and hundreds of Fortune 500s now have chief procurement officers, so it's really become a core function. There are also legacy players: Ariba was acquired in 2012 for over $4 billion, and Coupa more recently for $8 billion. Walk us through how you see the space. How has the paradigm in procurement evolved over the last decade or so?

The way that buying and procurement actually works inside of organizations has changed, and that's precipitated the need for software to solve a new problem. Let me walk you through that.

In the last 10 or 15 years, buying has become much more distributed. It's been pushed down into organizations. For example, there was a time when the IT department would decide all the software that a company would buy, and then they would buy it, and then they would implement it. Today that sounds kind of crazy, because each function, marketing, sales, engineering, product, wants to do their own thing. Maybe they're buying software, but maybe they're hiring a contractor, or buying billboards, or running a campaign. They need to buy stuff, which means they need to work with some set of vendors. Some might be new vendors, some might be existing vendors. So, one, that decision-making has been pushed throughout the organization, closer to the edge, if you will.

The second, maybe even more important change in the last 15 years is that the review of that spend has become more cross-functional in nature. It's not just about how much it costs. It's about the cybersecurity risk it might carry, the privacy risk. IT might need to review it because it's software, or it's a contractor that's going to have access to core company systems. Or, of course, there's a contract, so you have to have some sort of legal review of the MSA.

If you take both of those changes, even more people need to buy things inside of companies. These are people that have regular day jobs, so training them on how to do procurement would be a bad use of their time, because that's not even their job. And all of that stuff they're requesting, especially if it's a new supplier, has to go through way more reviews than in the past. How much the thing costs is not necessarily correlated, in fact it's inversely correlated, unfortunately, with the risk that it carries.

That was a gap we found in the world, so we created a category around it that we call intake-to-procure: managing that intake through one front door, and then the cross-functional reviews and approvals required for that spend, whether it's a new vendor or not. That used to not be much of a problem 15 or 20 years ago, but it has become a problem, and that's the problem we started to specifically solve for.

That distribution of purchasing power happened before you started the company. What was the status quo? How were people doing it before they started working with Zip?

There's a spectrum. In the worst-case scenario for a company, it's just email, Slack, Microsoft Teams. In some organizations it's even a phone call, trying to reach somebody and say, "How do I do this?" Then if the company has a procurement team, somebody on that team will be the quarterback of that request and manually track this stuff.

But you lose a lot. If a company has a security team, they don't actually have assurance that the security team is reviewing everything that requires security review, because it's not programmatic. It's not in software. It's humans trying to track this stuff. And if it's a $5,000 thing, it's hard to justify having a human manually track it, when that's exactly the type of thing that might open your business up to risk. The significant majority of breaches actually come from vendors, not from any other source, and this process is the culprit of that.

The best case is having built something on SharePoint, or maybe in Jira, that has some logic in it. But then it's extremely cumbersome to maintain. There are a lot of permissioning issues, as you can imagine. Spend can be complex but also sensitive. If you're hiring a contractor, their TIN is maybe actually their Social Security number. And how much you pay them is kind of like their salary. Should that be visible? So you get into a lot more complexity and ongoing maintenance challenges.

Ultimately, I think it's a question of whether this is your comparative advantage as a company. Is it your comparative advantage to run your intake-to-procure process? Or should you buy something purpose-built for it, because it's a new problem that has been created in the world in the last decade? What we've found being in the market for some time now is that it's important for a company to be able to procure, because it's important for them to control their spend and get visibility into that spend early, while also making sure it doesn't take longer than it should for something that actually does need to be bought, so that person in the business can be empowered to go do their day job. But it's not something every company should be building from first principles, from scratch. That's almost kind of dumb. That's the realization we had.

If I remember correctly, you left Airbnb in 2019 and started the company in 2020, when you were exploring problems to solve. How did COVID, if at all, inform how you thought about this problem, and how did the shift to remote work shape the thesis?

COVID certainly exacerbated this problem, because for the first time you couldn't just walk up to somebody and ask them how this process works. Especially in a larger organization, you'd have to figure out who those people even are and then find a way to get in touch with them. Without a formal system, a lot was worked through with organic, informal conversations and processes. Suddenly that went away, because you had to schedule a Zoom meeting to have a conversation. All the problems we all faced at the beginning of the pandemic made this a harder problem to solve, so I think it resonated more with people after the pandemic.

For us, when we started the company in mid-2020, people were still at home, unable to do much. A lot of the finance leaders and procurement leaders we reached out to, just to understand how they think about this problem, were kind enough to chat with us, share their two cents and walk us through their problems. I think some of that was because they were also kind of bored at home. Now we're more back to regular life, but that helped us in a way that isn't specific to our idea.

When I think about the product, there's a core workflow tool: people want to purchase things, there's information gathering and submission, and then on the back end an approval process that involves a lot of different people in a lot of different departments. What framework do you use to think about the product surface area, and what are the most important components?

I do agree that the intake-to-procure process is predicated on having a really great, clear visual workflow that can be extremely flexible and support lots and lots of variants. We see that because the needs differ so much. We have customers that are banks that might have 18 different types of risk teams, believe it or not. Then there's a small tech company that actually has this problem, but it's much simpler to solve for them. And there are healthcare systems that have a wildly different set of teams that need to review under very different circumstances, depending on the use of patient data and many other variables.

Building that in a way that is completely no-code config, where a non-technical person at the customer can own the entire implementation and change anything in their workflow over time, with the right permissioning, increases the complexity and the burden for our product and engineering teams. It's that much harder to build a product that is not just that extensible, but extensible in a no-code way for somebody else to administer and maintain. And then to maintain it across hundreds and hundreds of deployed customers, with all the different states of the product that exist as you ship new features, while ensuring stability. That's a really hard engineering problem and product problem. I'm proud of the fact that the team has done a really good job there, but I agree with you that that's the core.

Ultimately, our guiding light when you think about surface area is that we're here to make our procurement champions [successful]. By procurement champions, I mean somebody who is responsible for the procurement process, regardless of whether they have the title. Sometimes someone else is responsible and doesn't have that title, but it's the core tenet of their role at their organization. We want to make sure those champions are really successful, that we're helping make them look like heroes and helping them focus on the more strategic stuff and do less of the tactical stuff. The manual quarterbacking of these requests across teams is pretty tactical, so that's a core thing we want to automate for them. So is matching approved purchases to invoices coming in, in our procure-to-pay product. That can be completely automated.

Then, from a product perspective, it's holding ourselves to the absolute highest bar of product quality and user experience, and doing things as serially as we can, not all at the same time. There is a lot of pain in the general space and a lot of desire for improvement, and we will get there, but we have to maintain our discipline getting there.

I've heard you describe the product as a front door that sits in front of your procurement process. Is it fair to say that originally you tried to sit in front of things like Ariba and Coupa, and over time have expanded to replace those tools? How do you think about what you want to build versus partner or integrate with?

To be clear, we actually don't replace systems like Ariba. We're actually a partner of theirs. We're very focused on the intake problem. This is where there may be divergence by segment when you think about some of these other solutions and systems. But we now do intake-to-procure, which is our core product. We have since expanded to do intake-to-pay, where we do procure-to-pay, which is a more established category that has existed for quite some time. We also recently launched a sourcing product, which allows companies to run RFPs and RFXs much more efficiently, in a way that lets the end user kick that off. So they can bid out more purchases and drive more savings for their organizations.

As you get into the pay end of that intake-to-pay cycle, or into sourcing, where Coupa is certainly big, is there a vision where a company could eventually run its entire procurement stack with Zip? Or is there a defined universe you never want to get into?

Our view is that what we really care about is intake, and we want to maintain as agnostic a position as humanly possible to every other component around it. Of course, that varies by segment, but that's how I see it. Another way to frame it is that intake is the point of origination of a request, of somebody in the business needing something. We want to make sure we own that, because that's our reason for existence. That's the problem we're solving for. If someone in a certain type of company chooses to go with us deeper into the journey, that's great. But we're actually fine either way. It may sound counterintuitive, but we actually don't care as much about that. What we care about is the intake starting in Zip and owning that part of the experience.

Why is that so valuable? Are you thinking in terms of what corpus of data you want to be the system of record for, versus nice-to-have adjacencies?

It may be simpler than that for me. That's our reason for existence. That's the category we created, intake-to-procure. That's what makes us special in the world, because that's the problem we saw. That was the gap. That was the manual process, the emails, and we want to make sure we own that. I also think it's important, and we see this across our customers, that the employee base then knows they need to go to Zip to kick off anything procurement-related. We want to be the front door of that, because it's our reason for existence in the world.

There are also buying platforms that help procurement professionals with negotiations, and spend management tools that work after the fact. Do you see those as adjacent to what you're doing?

I look at them as adjacent. One, a lot of those companies are very focused on buying software and buying SaaS. We see that less than 20% of the requests that come through are software, across the $30 billion plus that has been approved in Zip. It's everything else you would expect: services, contractors, IOs for marketing spend, physical goods. Believe it or not, people still buy physical goods in 2023. It's easy to forget, but they do. All of those use cases are very complex and specific. We pride ourselves on knowing those use cases and on having a great set of templates for them, developed across our customers, that can help the next customers so they don't have to build all of this from scratch. We actually have integrations with a lot of the companies you mentioned, so they're separate.

From a negotiation perspective, we're a SaaS company, not a services company. There are definitely other providers that can help negotiate and provide the services components, but we don't do that because we're a SaaS company.

You've got some great customers, like Webflow, Notion and Snowflake. At your conference last year, the CFO of Snowflake talked about working with you. A lot of the public logos are in tech, but it sounds like there are also banks and healthcare companies. What does an ideal customer look like in terms of size and sophistication of procurement muscle?

The thing that matters most is that they also believe they have this problem around intake, and that it's a cross-functional challenge between all these different teams and stakeholders. That might sound like a cop-out answer, but it's the number one thing, because not everybody recognizes that it's a problem. That's not because it is or isn't. It's because, as humans, we get used to doing things the way we've always done them, and having a paradigm shift and realizing, "Wait, I actually don't need to do any of that," can be a challenge. But what I've seen in the last couple of years is that it's definitely becoming much more front and center, because the changes we were talking about earlier have only progressed, and so the pain is even more acute today than as recently as 2020.

It does not matter to us otherwise. We have customers with procurement teams of hundreds of people or more, and customers with no one on the procurement team because they don't have that function yet. The way we solve for that is with best practice guides and templates across those segments, from literally nobody to hundreds of people. Most companies will probably never get to hundreds of people in procurement, depending on the nature of the business. We also cut by vertical and industry. So if you're a health insurance company with 5,000 employees, we have relevant templates and guides for you, versus if you're a 300-person tech company that's growing quickly, doesn't have a procurement person yet, and is just trying to get early visibility into all its spend. It's a totally different template, but there are templates for that too. So for us, it's making sure the person believes in our mission and cares about intake and its value, and then supporting them with the learnings and resources we have.

That's backed up by data. In our research on Zip, we came across a BCG report that looked at the top 150 companies consistently in the S&P 500. Only 35% of them had a chief procurement officer or an equivalent role. But the companies that took procurement seriously outperformed the broader market from 2000 to 2020 by 134%. Anybody who doesn't work in procurement might think how a business buys things is the boring part, but it seems to be pretty impactful. When you find customers who really resonate with what you're describing, what is it that makes those companies special?

Typically, the procurement function rolls up into the office of the CFO. This is maybe more anecdotal, so it might be challenging for me to back it up, but I really do think it comes down to CFOs who really care about procurement. Especially with the macro in 2023, so many more companies were focused on managing and controlling their spend better. You have to have leadership that really believes in the value of procurement, because you have to believe in the value of the role itself, and then support that with investments in the right people, the right process and, of course, the right systems and technology, which is where we slot in.

It comes down from CFOs, and maybe even the CEO and founders. It has to start there, because if they don't care as much about it, and there's not as much focus on getting visibility into their spend quickly and early, a system isn't going to solve for that by itself. It has to have the belief and support of the organization.

How does that translate into success for you as a business? You mentioned something like $30 billion approved through your platform. What is your North Star metric that says your engine is working?

We certainly look at usage across our customers, by customer and by segment, and how much of their spend is actually being reviewed in Zip. We can also help our customers by saying, "For companies like you, you're best in class," or, "I think you might need some help, and here are three ways you could get better at this." That might be a policy change, or something about their workflows, or, "Do you really need 16 different reviews for this type of thing? That seems abnormal, because other companies like you don't seem to have that level of process." So part of this is getting the process and the system stood up, and then helping them continuously improve. There are metrics like that around spend visibility across the customer base, and predictability, that we look at.

Over the next three to five years, what are the obstacles to helping people manage more of their transactions through Zip? Is it philosophical, where more companies need to wake up to the value of this? Or could other solutions plugged into the stack do it better?

I tell the company this: I think it's nearly all execution risk. And that's significant risk, especially when it comes to the product. We get asked by customers all the time, "What if you built this?" or, "This is also really broken for me." It might be very closely related or completely unrelated, but we hear it all the time. And they're not wrong. There is pain in the world, in the general space of software in the back office, if you will. So it's balancing what we want to build next with making sure we're not biting off more than we can chew.

There are companies out there, not necessarily in this space, that have been too motivated by what will sell. They build product and trade that off against other investments, and you end up with a sprawling code base and a sprawling set of products that are not fully invested in. What they don't understand, and this is a core value of ours, is that if we write a line of code and ship a product, even if only one customer is using it, it is our job and our duty to service that line of code in perpetuity, until no one is using it. I think those ongoing investments are not necessarily made by a lot of B2B SaaS companies.

The reason for that, having worked at Airbnb before, is this. At a consumer company, if you don't have a good product, no one goes to your website, or they leave and go to somebody else's website because it's better and book there. You have to earn the right to the business every hour, every minute, every second of every single day. The unfortunate thing with B2B software, certainly software that's sold top-down, is that you only have to earn the right to the business once every year or three years or five years. And not with the people who are using the software, which is maybe the sad part. It's with somebody else who has the power and the budget. I think there's a cognitive dissonance there that causes software companies to go off the path and build bad products. I don't think anyone sets out to build a bad product. Everybody is very well-intentioned, but there are bad products. So how does that happen? I think it's because of that.

So we really ground ourselves in building with the end user in mind, because if we build for the end user, it makes the job [easier] for procurement, for finance, for all these folks. It's only hard if it's hard for the actual person to use it. If you make that easier, everything suddenly starts to flow with the current and not against it. That's how we trade things off, and that's how I look at the North Star and our philosophy for building.

The other side of the coin is what you say yes to. A few months ago, you launched a sourcing module. How did you apply that same framework of focus, and why was sourcing the next big thing for you?

First and foremost, there was a lot of customer demand for it. We did a lot of user research with customers, with prospects and with others, across different profiles: power users, and regular people who might have to buy something expensive that needs to be put out to bid through an RFP. We realized there was a gap, because a lot of the software out there that does sourcing is built for much more complex supply chain needs, reverse auctions and more nuanced use cases. That comes at the expense of allowing a regular person in the company to kick off an RFP for something that costs $100,000 in a simple way, without requiring a professional to orchestrate the process.

We realized that if you can solve for that, it's not the long tail, it's the fat middle, whatever the opposite of the long tail is called. There's a way to solve for that in a really intuitive way in the product and have it work naturally and seamlessly with our intake-to-procure product. What we found is that people don't start out thinking, "I need to go do an RFP." They start with something, and then it's, "Wait a minute, this is getting expensive. Oh, crap, maybe I should do an RFP." Usually it's not clean and clear at the beginning. It's somewhere in the middle. So we built the product to transition seamlessly in and out of an RFP at whatever point that occurs in the intake-to-procure process, if it ever occurs. That's a real differentiator, and it's what we found was of real value to our customers.

When you think about trade-offs, it has to work really seamlessly with the core, and there has to be a reason for it. We realized that before the sourcing product, people were leaving the product, doing this offline and then coming back. So it made natural sense to build, because it was part of the flow.

Given how broad and complex this category is, and how much customer push you're getting in specific directions, what will the Zip platform look like over the next three to five years? Is it getting what you've built into everyone's hands, or is there still an expansive vision for the product surface area?

We've built a lot of product, and it's about continuing to invest in the nuances of that product, especially when you look at different segments, different types of companies, different needs and the different teams we work with. It's doubling down and focusing on that over the coming years, and making sure we really care about customer love, which may sound surprising for a company that focuses on procurement software. But I've found that it's actually kind of an emotional thing for people. It's even an emotional sale, because they're usually so unhappy with how manual their process is that this can help elevate them to be much more strategic in the organization, and to be viewed as strategic as they actually are. So for us, it's making sure we double down on the core we've built, intake-to-procure and intake-to-pay with sourcing.

One of the announcements we made recently was around our generative AI capabilities. We started off with some really exciting use cases, but there's a lot, lot more that we're scoping. That's the other big pillar I'm really excited about, and I think it will carry us for years on our roadmap. I think we'll be able to make a lot of progress very quickly there.

Generative AI also illustrates the corpus of data you've already created, and what unique data you have to inform what people are doing or to produce templates automatically. Where is the most significant value for you in building generative AI into the product?

Any type of use case where there's a need to structure data stands out. If you're going to buy something, there's a contract and there's an order form, so those are obvious use cases to start with. But ultimately, I think you can lean on generative AI not just to programmatize and manage the process, but almost to do the work, in a way. There are a lot of reviews that can be relatively redundant. I'm not saying that today or tomorrow, or even two or three years from now, generative AI is just going to do the reviews. But it can certainly do a lot of the review, and then allow the human in that role to focus on what's different, and not on the other 95% that's probably okay and the same. They can focus on where they add value.

Then maybe in five or 10 years, we'll be at a point where you can reduce the need for human review of a lot of this stuff. But for now, we want to elevate. If someone is going to be working on something, let's make sure they're doing the most strategic work possible, and anything that's redundant or menial, software can do. AI can do that.