The value of connected systems

I was Rippling's first employee. Over five years I led Device Management, built billing on the side, and eventually ran all of Health Insurance. Three different products and one thread connecting them: I kept ending up wherever systems needed to talk to each other.

When I joined Rippling, it was just the founders and a big ambition: reimagine how companies manage employees. At first, it sounded chaotic but in reality, it gave me a front-row seat to something I would spend years thinking about.

Like most companies, customers didn't wake up in the morning wanting payroll software, device management software, insurance software, or HR software. They wanted employees onboarded, paid, insured, equipped, and productive. The problem was that every one of those workflows lived in a different system.

For years, the conventional wisdom in software was specialization. Software companies built the best product for a single function. The best system for payroll, HR, or device management. The key word here being “or” and not “and.” Individually, many of those products were excellent in their own stream but none of them talked to one another.

From the customer's perspective, the folks who are on the platforms every single day, each additional system created more work, leading to an increased risk of manual errors. Information had to be entered multiple times, teams had to reconcile differences between systems, and processes inevitably broke when one tool didn't know what another tool knew.

What made Rippling different was not that it built more software. It was that everything was built on top of the same underlying dataset. An employee wasn't represented differently in payroll, benefits, devices, and HR. There was one employee record. Everything else was built around it.

The value wasn't coming from any single feature. It came from connectedness.

Over time, I watched the company launch more and more products. What struck me was that each new product created value far beyond its own functionality because it became part of a larger system. The whole platform became more useful than the sum of its individual pieces.

That lesson stayed with me.

Applying the lesson

When I left Rippling and began thinking about what to build next, I kept returning to a similar problem in finance and revenue operations. It looked a little something like:

• Contracts in one system
• Billing in another system
• Revenue recognition in another system or a spreadsheet
• Commissions lived in spreadsheets
• Approvals lived in emails or slack
• Customer data lived in the CRM

Here’s the scenario I see often with the systems above: a sales team closes a deal, someone manually creates billing records, finance checks whether invoices match the contract, revenue schedules need to be updated, commission calculations need to be reviewed, and finally, approvals need to be tracked.

Each individual tool solved its own problem reasonably well. But the work happened in the gaps between them. And looking at the list above, that’s five handoff points, giving each contract five points of failure. 

The complexity wasn't coming from any one workflow, it was coming from the number of handoffs between workflows.

The more we looked at the problem, the more it reminded us of the same pattern we had seen before: multiple systems trying to manage different parts of a single process. So when we started Measure, we didn't think of ourselves as building billing software or revenue recognition software.

We started with a different question:

What would happen if contracts, billing, revenue recognition, commissions, approvals, and customer data all operated from the same underlying model? What would happen if every downstream workflow already understood what had been sold, who bought it, how it should be billed, and how revenue should be recognized?

The goal wasn't to create another tool. It was to remove as many handoffs as possible. And candidly, we're still early in that journey. But the idea behind Measure is the same lesson I learned years ago: software becomes most valuable when it stops being a collection of features and starts becoming a system.

The best products don't just help people do work. They help work flow.

How we're building

We're builders at heart.

One thing I've learned throughout my career is that complexity doesn't disappear just because you ignore it. It still exists somewhere. Most often, it gets pushed onto the customer through manual processes, spreadsheets, and operational workarounds.

Our approach has been different. We try to absorb that complexity into the system so the work itself remains simple. Revenue operations can be incredibly complicated behind the scenes, but that doesn't mean the people doing the work should have to feel that complexity every day.

We've chosen to build Measure with a lean team to give better value to our customers. That philosophy extends to our pricing as well. Our goal is to align with the value customers receive and build a platform companies can grow with for years.

Why now?

I've spent enough time around growing companies to know that nobody wakes up excited to replace their billing system. But these problems rarely get smaller with time. They usually become more deeply embedded in the business. The best time to put the right foundation in place was at the beginning. The second best time is now.

If your revenue management journey looks a little like the scenario I shared, let’s chat.

I'm the co-founder and CEO of Measure. Measure connects contracts, billing, revenue recognition, and commissions in one system for B2B SaaS companies. If you want to see how it works, book a demo.

‍