How Pave built a Compensation Planning product in 6 months

About Me

Hey, I’m Reuben, the Product Manager for Compensation Planning at Pave! I joined Pave as employee 10 in 2020 and have helped build out our Compensation Planning product from the very beginning, playing Software Engineer, Tech Lead, and Product Manager during my time here.

Below, I dive into the story of how we took a barebones product demo targeted at a burning pain point for our customers and turned it into a full-functioning product that has helped HR professionals across dozens of companies run better merit cycles. After reading this, engineers and product managers alike should come away with multiple lessons on how to build a prototype from scratch, validate features and look for patterns, and start scaling an early stage B2B product.

Our Story

At Pave, we sold and launched our Compensation Planning product in early 2021 to our first customer. Since then, it has launched for dozens of companies, of many shapes and sizes, some of which have well over 1,000 employees. We have companies that have run multiple cycles with us and we now have a strong end-to-end motion for how to successfully launch and run these cycles seamlessly. Today, Compensation Planning is a multi-million dollar business that forms the foundation for much of Pave’s revenue and growth.

What is Compensation Planning?

Pave’s Compensation Planning Demo

Compensation Planning is the process a company goes through, usually every six months, where it allocates pay raises and equity grants to its employees, based on a variety of factors such as market compensation data, employee performance, and compensation history.

You may have been frustrated in the past by how long you have to wait till you find out your raise. Cut your HR team a break — the process is incredibly complex and time consuming.

Different companies have different types of compensation they care about (salary, bonuses, commission, different types of equity, etc.), different budgets, different permission groups, different philosophies about compensation, and different employee groups they want involved in the process. Some companies want frontline managers to propose compensation changes and then have it bubble up through the management tree until HR finally signs off; others just want HR making decisions for employees at the outset, and some want only executives making the decisions. Many companies handle this complexity today using extremely large and convoluted spreadsheets: an antiquated, error-prone solution.

Our team is made up of a few engineers, mostly with previous B2C experience, and no experience in HR Tech or CompTech. To identify and understand compensation planning pain points, we performed user research with a customer from our first product, Total Rewards, which is how our customers communicate total compensation (including bonuses, variable pay, benefits, and equity) to their employees. We used what we learned to launch our planning product with them in late January, then launched three more companies in February. Soon, customers were asking for demos and buying our product, faster than we could onboard them. These early customers had already built trust in Pave from their usage of Total Rewards. Others followed suit and purchased our Compensation Planning product after hearing positive feedback from those early customers, a sign of clear product market fit. We now had a new challenge — keeping up with this surging demand and simultaneously delighting our customers. Here’s what we learned.

1) Listen to Customers

Since we were working in a space in which we did not have deep prior personal experience, we knew that the customer was truly always going to be right. They were intimately familiar with their pain points and our goal was to hear them out. We did not have any hubris about the “right” way to build Compensation Planning — instead we let our early customers drive the product while following sound engineering principles we picked up from our previous jobs.

To avoid the pitfalls associated with too much indirection, our engineers talked to those early customers directly as much as possible (3+ times per week). As we onboarded a few more customers, we looked for patterns, then focused on sharing product use cases between customers. For example, when one customer asked for a way to budget for employees using percent of salary, we validated this with two other customers before building a generalized, configurable solution. We struck a balance between doing exactly what customers wanted and generalizing between customers.

2) At First, Do Things That Don’t Scale, Then Create Leverage Where Possible

We had this mantra, championed by YC, built into our fiber from our inception. In the early days, we focused on delighting the customer with everything we had. We largely ignored scalability until we actually began to hit scale. As mentioned above, we had engineers devoting significant time to talking to all of our customers directly. We also found ourselves writing “custom code” for our first customers, at least until we collected enough data to identify patterns. We would build a new feature simply because one customer told us it was critical for them to be able to properly complete a compensation cycle. We supported new column types and pay types as they came up. Engineers onboarded customers using JSON configuration files instead of building customer facing onboarding and configuration tools.

Because we were ruthlessly focused on building and validating features, we quickly learned which features actually resonated with our customers and what typical patterns looked like before investing a lot of time into building out advanced onboarding flows.

Initially, it took around 40+ hours of engineering time to “launch” a customer. This included building the “features” that they expected and needed to run effective merit cycles, as well as just getting the base product working using their real-world production data.We moved to using scripts to upload and modify configuration data, bringing that time down to 10–20 hours per customer. These scripts helped scale engineering time so we could do more with less, but an engineer was still required to onboard each of our customers and make requisite configuration changes for them, which was better than before but remained truly unscalable.

3) Respond to Customer Issues Immediately

At the very earliest iterations of a product, things are going to break. That’s ok. In fact, if nothing breaks, it is highly likely that the product went to market later than it should have — after all, it was an MVP, right? In fact, there were a few categories of issues where things did not go as planned — a customer needed some critical new feature with a seemingly impossible deadline; a customer expected things to work one way when it actually worked differently; bugs where key user flows broke down; and complete “system down” outages (fortunately, this only happened once or twice). Usually, we had to deal with the first two categories of issues, and made those changes for our first customers as often as was reasonably possible.

Customers who sign up with a very early stage startup, as Pave was a year ago, know that product stability is not going to be perfect. We were shipping new features at lightning speed to meet customer demand, but as every engineer and PM knows, there is often a stability cost associated with that kind of product development. To make up for any bugs that made it to production and harmed the user experience, we knew we had to remind each of our earliest customers that they were truly special to us, and that we would do everything in our power to delight them. This included dropping other work and fixing bugs when they came up. We wanted to show our customers that even when things go wrong, we will go the extra mile to make sure they have an amazing experience. We invested deeply in the customer relationship by staying accountable for our mistakes, listening to feedback, and then actually incorporating suggested improvements into our product. This built a lot of trust with those early customers, improved our product overall, and elicited positive network effects when our customers chatted with their peers about Pave.

4) Communicate tradeoffs to Sales

Today, after much experiential learning, we have a tight loop between Sales and Engineering. Our demo accurately represents the current state of the product at all times, and we have clear expectations around if features are currently supported or are on the roadmap within the launch timeline of the customer. However, this was a hard-earned lesson. With the benefit of hindsight, we would have included all of these measures in our process much sooner.

In our earliest days, we really struggled to find Sales/Engineering alignment. In our eagerness to always delight our customers, we found ourselves selling and building custom features for each of them. Given how early we were, it was hard for us to draw the line between what was critical to all customers vs. just one. Very quickly, we learned this approach didn’t scale.

In retrospect, we probably should have only sold one or two prospects before the product was built and tested. With every new company we had to onboard, we had less time to build new features and less time to QA effectively, so product stability suffered. Our earliest launches had far more bugs than we were comfortable with. Our engineers had to endure a few too many long nights and stressful last minute feature updates leading up to launches, meaning we took shortcuts such as excluding unit and integration tests, compounding our issues around stability, the effects of which were felt for a long time.

The key was that we needed to explain to our partners in Sales what we were explicitly trading off with every deal we sold where the expected feature set did not match what was already supported. Specifically, we needed to show them that we were ending up with a buggy experience because of short timelines and unscoped features with varying customer expectations. Also, we explained that any time spent onboarding customers manually, fixing bugs, or resolving customer-specific feature requests, was time taken away from features for the market. Simultaneously, we ensured that our demo exactly matched our product capabilities, so that there was no room for miscommunication around the actual product experience. As soon as we communicated these tradeoffs to our sales partners and corrected the relevant parts of our process, everything ran much more smoothly.

5) Once Demand Picks Up, Invest In Scale

Once we began to find product-market fit, we saw the writing on the wall that we were not going to be able to keep up with demand if we continued down the same path and decided to invest heavily in scale. This included everything from process scale, to code scale, performance, and stability. Every single bug today comes with a greater cost than it would have before. Our customers have built Pave into critical parts of their Compensation Planning process, and any downtime quite literally prevents them from doing their job. The stakes are higher, so we had to mature as an organization to deal with this greater set of expectations.

• We paid down technical debt. We enforced strong typing with TypeScript throughout our codebase. Previously, as newer engineers joined, they struggled to understand the code and contribute because there were no types and no documentation. As we began strongly typing our code, we discovered and fixed many long-lasting bugs that were previously reaching our users that we just did not know about. The typing also served to self-document our code, enabling new engineers to start contributing much more quickly. On top of that, we introduced more alerting and monitoring tools (shoutout Datadog and Sentry!) to help us find bugs in staging before they ever reached our users, or resolve them faster if they did make it to production.
• We identified and understood our target market. We aligned on our Ideal Customer Profile across the organization, from Product, to Engineering, to Sales, and to Customer Success. We committed to staying focused on this profile every time we considered a new feature and avoiding investing time into prospects outside of this market.
• We stopped writing new “custom code” (i.e. code that was specific for a certain customer ID) and even removed numerous existing instances of it. There is a cost to writing and maintaining any new code, and when that code only applies to one customer, the benefits do not justify the added burden on engineers. By adhering to this principle and paying down the accumulated debt, we reaped all the benefits that come from a simpler, cleaner code base.
• We automated our way out of manual work. This one is so important to us that it made it on to our Engineering Charter! If it took us an hour to do a task, and we knew that we had to do it at least 10 times, we built automation for it. We built internal tools to enable non-technical folks to change our product configuration for customers, drastically reducing engineering time for onboarding. This allowed engineers to focus on using our time to build new value. We used Retool to rapidly build and iterate on this internal UI and get it to our non-technical team members, which was a significant time-saver for us because of all of the out-of-the-box UI elements and auth-gating functionality. Eventually, we plan to make this product configuration customer facing, to empower our customers to make the changes they need on-demand instead of having to ask Pave.
• We scaled our processes. Once we understood the industry and product use case better, we did not need every engineer talking to every customer. Instead, we had our account managers provide synthesized updates of what our customers wanted to see and had just our PM interview a handful of companies, representative of our ICP. We also wrote extensive documentation of all product configurations and how we support them to help onboard new employees to Pave and allow them to start contributing quickly.

Conclusion

Today, we have strong product market fit, a repeatable sales motion for our product, and we are domain experts in compensation. It takes 1–3 hours of engineering time (soon to be 0!) to launch a customer and now we can be focused on step-function changes to our product that will allow us to target new markets with new types of customers. We are excited to start focusing on longer term, big picture initiatives like truly making our compensation planning tool frictionless and weaving in intelligent insights.

If I were to sum up this piece in two principles, it would be: obsessively focus on your customers and validate demand before investing in scale. Hopefully, you leave this piece with valuable lessons on how to take your product from 0 to 1, no matter how complex it is or how much existing expertise you have in the space.