Hari Raghavan, CEO of AbstractOps, on the composable enterprise

I expect that the problem we're solving is going to be as important and as fundamental to a company's functioning as an AWS or Salesforce or Stripe, where it's core infrastructure to their operations.

Today, we're serving many of our customers through software, and many of them through services. The question is, "How can you most efficiently serve the greatest number of needs in the most scalable way possible?"

In other words, for us, I don't think product-market fit is a hard flip of the switch. We’ve long since had PMF on our services, and we’re far into the goal of gradually shifting to product-driven solutions over time (with some human in the loop for judgment calls and edge cases).

Permalink

How do you think about partnering as well as competing with companies like Carta on cap table management, Mercury on banking, and Deel on payroll?

These are all critical partners to us. Partner relationships have gotten especially interesting lately, because the best players are moving much more towards “infrastructure”, which is a direction that’s much more compatible to our approach. 

You’re seeing that companies prioritizing interoperability thrive. Companies are even building products that don't have a UX at all because they're not meant to be interacted with. Instead, they’re the infrastructure layer that companies like ours can connect.

At the same time, if a product has both a fantastic UX and a fantastic API-first experience, it reduces both the frontend and backend effort required to solve that problem. Mercury is a great example of this: API-first product, fantastic UX, and great customer service. By integrating with them, we can bake in many of those benefits.

There are a lot of startups like Rippling and Ramp that are automating these different areas of HR and finance within an organization, and in some cases expanding outward to these different people functions. How do you think about your positioning with respect to companies like these?

The problem that Rippling is trying to solve is not the same problem we're trying to solve. Take a look at what they launched last year with Unity. I thought a very powerful use case they described was: when an engineer goes on vacation, you can set up an automation so their Jira tickets are rerouted to someone else. 

We have zero desire to get involved in that. We don't want to touch the work being done inside the company at all. What we touch is the work of the corporation itself.

Both of us have used the phrase “company OS”, but the word “company” is being used in a very different sense. The company can be used to mean an organization, or a corporation. Rippling is building an operating system for the organization -- the work being done inside a company; and we're building an operating system for the corporation -- the business that an enterprise engages in. We’re solving for, its business relationships, its contracts, its payments, its transactions, and things like that.

There's some overlap: specifically in HR around the hiring and onboarding workflows. But there the overlap ends; as a result, we end up working with Rippling a meaningful portion of the time. A third of our customers are on Rippling, which clearly means that a customer is getting value from both our platforms.Because: but does Rippling handle all of your contracts? Does Rippling think about all of your vendor payments and management? They don’t. I'm sure they'll continue to expand that surface area more and more over time, but am I really worried about competing for market share, or share of wallet, with Rippling? Not really.

Everybody wants to grow their circle over time, and of course, there's going to be overlap. But over time, there's still going to be plenty of work for each of us to do in our respective spheres. With any of these tools -- Gusto, Rippling, Mercury, Ramp, Carta, Pulley… I'm a big believer in the idea that we should be competing with the SAPs and the Oracles of the world, not with each other.

Permalink

Is there a particular size of company that you’re most focused on serving at the moment, and how do you think about expanding to service operations for companies of all sizes?

Right now, our focus is on companies that are 5 to 50 people, and the reason we start earlier-stage is because there's less toothpaste to put back in the tube. The earlier we get started, the more we can organize information from the get-go, and the less there is to jam back into the data structure. This is key to building a data platform -- if you can enter earlier, before the “digital exhaust” has gotten out of control, the better.

The second reason is because we can work with them to choose the parts of their stack that are compatible with us and that will scale really well. A lot of the work we do with clients is making vendor recommendations, and if 80% of our clients use a particular tool or accountant, then we become a lot more efficient because our operations and API efforts can be concentrated on just those best-in-class tools.

How do you think about maintaining consistency of user experience with an operationally heavy company? Is there any concern about that becoming more difficult as the companies you work with get bigger?

If you think of relationship management as a price to pay, then you're always going to try to optimize the crap out of it, and you're going to end up making it worse over time. 

If you think of it as part of the value proposition, you'll make very different decisions.

For example, we don't try to load up our operating team members with clients. We’re always testing to find the right number, but the goal is not just to get to a better gross margin—it’s about finding the sweet spot at which we get the best overall outcome.

If you think of it as a positive-sum game and look at how you can create more value even if you end up spending more, you can charge more for more value that you create later on down the road. At the same time, it's really important not to go down the slippery slope of selling $1 for $0.90. That’s what happened with venture-funded companies like Uber, where the unit economics were questionable for a long time.

It's important to know how it's going to get better over time, and know that it's going to be a sustainable business model. At the same time, you don’t want to squeeze it for margins—you want to think of it as a way of creating more value over time.

Permalink

To what extent do you see AbstractOps taking over 100% of commerce back-office needs? Are there some areas you don't think AbstractOps wants to touch on?

I'll tell you the philosophy underlying how we work.

First, we do things that are repeatable. We don't get involved in things I would call bespoke or strategic, like your forecasting or financial planning or recruiting.

We might make a vendor recommendation or provide a baseline template of a policy or job description, but we won't do that last mile of customizing and solving these kinds of more bespoke problems.

We also don't touch your engineering or product design stack, and we don't touch your sales or go-to market. In other words, we don't interface with code or customers. Our surface area is really the routine, repeatable work in HR, finance, and legal compliance.

Permalink

How do you guys think about data security and the compartmentalization of different information? Within the organization, certain people have the ability to see certain things, or they can't. How are you working around those security and compliance-related issues that might exist in organizations?

We’re building security to be a core competency. People are the weak links in any system, and who has access to information is one of those important questions that is often overlooked.

One thing you can do with our system is permission a class—for example, ensure that an HR manager has access to all offer letters. 

You can also add provision access to individual instances. Let’s say you have a Director of Operations and they're hiring an operations associate. The HR manager can invite them to participate in that hiring workflow, but just in that one instance—so they can’t see the offer letters for everyone else. The same is true of NDAs, customer contracts, vendor agreements, invoices, and so on.

Building our security around people considerations ensures that we’re building on strong security foundations -- not just internally, but for our customers’ internal workflows as well.

Permalink

What are some of the core companies that comprise the modern HR, finance, and legal compliance stack?

For payroll, Gusto is a primary with Rippling as a backup.

For cap table management, there’s Pulley and Carta—it depends on your company, and a bit on your lawyer. 

Historically, Carta has been the entrenched 800-pound gorilla here, in a manner of speaking. Pulley has built some really compelling stuff more recently, and they’re a little bit more API-first and a little bit more data portability friendly. I don't think we have a clear first and second, as they're both really compelling offerings.

For banking, Mercury is a ridiculously delightful product. Brex is an easy close runner-up. There are also a number of challenger banks. 

Banking is one of those things where it's not a singleton. We typically recommend that people have two to three bank accounts with different providers, not for the sake of de-risking—if your bank goes out of business, there's something very wrong going on with the world—but because banks can have slightly different purposes. 

For bookkeeping and account ledger management, it’s QuickBooks. It's not even close. At some point, you'll have to graduate to NetSuite, but that's true of other tools too. For example, you'll probably have to graduate to ADP for payroll at some point in time.

There have been some interesting developments in the space recently. Puzzle is a company that we know well, and they’re building some really cool stuff. There seem to be interesting things going on with Pry and Digits and some of the others as well, so we'll see how that space ends up evolving. 1Password is the gold standard for password management. Do not second guess it.

Sign up for Google Workspace. Please don't sign up for Outlook. It's just not part of a modern stack. 

I would say the most non-negotiable things we have as part of taking on a customer are probably Google Workspace and 1Password. If you're not on those, it's just way harder to make your company run. 

For international payroll, we're currently huge fans of Deel. We work very closely with them. 

This is definitely one of those spaces where there's a lot of competition—I mean, there are a dozen of those players right now. Going with established players from a compliance perspective is pretty important. There's no perfect solution, but Deel is currently our go-to for the most complete effective solution. 

For credit card, Ramp is the most robust, but again, I don't think you'll go too wrong with Brex. If you want to marry both your bank and credit card in one, Brex is a good approach. But Ramp will scale a lot better, as their permissions and controls and feature set are really robust. 

On the flip side, one of the risks with Ramp is the fact that it's currently overwhelming for a non-power user. There's a lot going on. I think the Ramp team knows that as well, according to their public statements. I expect them to take a breather to reorganize things in the product and make it easier to navigate. 

For business insurance, Vouch should be your go-to. 

I think those are most of the important elements of a modern HR, finance, and legal compliance stack. 

For contract management, you should use us if you’re an early stage startup. At some point, Ironclad or other more powerful CLMs might become valuable. Our experience is that using contracts in AbstractOps is a 10X better experience than using DocuSign plus your Dropbox or HelloSign plus your Google Drive.

Permalink

Who are AbstractOps' key competitors? Is hiring a fractional or full-time COO for some of these smaller companies the alternative that they're looking at?

The way people currently solve this problem is through a patchwork quilt of tools, or through hiring people, whether fractional or full-time. We're not trying to rip out any of those things. We recognize the necessity of both of those aspects of the solution. 

What we're trying to create is a common language between those tools, so they can talk to each other more effectively and so people can share information and context with each other more readily.

The analogy for what we're doing is like what Salesforce does for the customer stack. It's an operating system. It has a database with structured data. It has workflows that sit on top of it. And it has an app exchange that plugs into an ecosystem of other things out there.

That's not that different from what I was describing earlier around our product or value proposition. There's a data structure that organizes the information. There's standardization around workflows and knowledge that goes with it to make these things much more predictable. Then there’s the human in the loop who deals with exceptions, does quarterly reviews and onboarding and things like that. They’re the trusted expert and advisor on all things operations, on questions you can’t ask a piece of software.

Permalink

What are some of the key industry tailwinds that you see for AbstractOps? Are we heading for a world where startups use many more different products to run their operations, or on the flip, will there be consolidation across the many tools we see out there?

There's a great phrase: “There are only two ways to make money: bundling and unbundling.”

Over the last 10 years, we've seen a massive explosion in the number of tools. I don't think we're done, especially when it comes to HR, finance, and legal, because it only started in the last 5 to 8 years. 

Right now, there's a little bit of an abundance of choices, and that’s partially because we've been in a very low interest rate environment with lots of cheap capital. That's likely to continue a little bit longer, but at some point, it’ll be due for a correction. (Editor’s note: this interview was conducted at the beginning of April.) There is such a thing as too many tools. 

That said, I do think another interesting broader trend is emerging. Not to quote a very corporate tool, but Gartner has a really interesting phrase: they call it the “composable enterprise”. 

Things that used to be core competencies are becoming modularized. Building a company is becoming a Lego exercise: you just take this thing, plug it in here, take this thing, plug it in here, and so on. What's important is those little round ridges on a Lego block, that make sure things can connect to each other.

We're starting to see that people are feeling overwhelmed by too many tools. At the same time, we’re seeing more interoperability across API services and the infrastructure layers. We then sit in the middle and tie them together.

We’re moving more and more in this direction, where human APIs are being replaced with actual APIs.  This lets software can do what it does best, which is create rules, store data, set reminders, and so on. That frees up human potential to do what they do best, which is make judgment calls, make decisions, and drive the strategy forward. If we -- and our partners in the ecosystem -- can pull that off, then we take this black box of “company-building” and make it way less intimidating, way more accessible. We automate the routine tasks by gluing together these building blocks… so that founders, operators, executives can do their best work, build massively impactful companies and put a dent in the universe.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.