Writing

My Perilous Journey Through SaaS Pricing

Sean Chou · 2022

This is my story of how we navigated our way through a difficult journey on SaaS (software-as-a-service) pricing. To be honest, even though this was not my first startup, I was unprepared for just how complex it would be. It felt as if we were on a quest for a mysterious Yellow Brick Road that would hopefully lead us to the Wizard who would answer all of our questions. What I discovered was that there is no yellow brick road, or any road, for that matter. There is no Wizard. Just an endless quest where you either blaze your own trail or give up trying. To be sure, we stumbled and fell quite a bit; perhaps even more often than we were actually standing up and walking. But we always picked ourselves back up. We never gave up.

Historians write that the German soldiers in WWI did notice a difference between U.S. Marines and U.S. Army Soldiers. According to Historians, German Field commanders sent messages to their headquarters that went something like this:

We are fighting the American Marines. They fight like no other people we have ever fought. We are winning the fight, but the Marines do not know that they are losing. Even when we shoot them, they continue to attack. Please advise.

-- USMC folklore

When we began Catalytic, we set out to create technology that would be transformative to companies big and small. Small was important to me because big companies have had a big advantage historically in their ability to implement transformative technologies simply because they had the resources available. One of the main blocking points in my mind to small company adoption was pricing. And so, pricing was top of mind from the very start of Catalytic.

Caveats

Before diving in, let me put some caveats out there. I was a co-founder and CEO of Catalytic for the entire journey. As such, I believe I am well positioned to have impacted, seen, and reflect on our pricing decisions and their impact. That said, I want to acknowledge a few things:

The Basics of Catalytic

To better understand the pricing models, it will be helpful to have a basic understanding of the Catalytic product.

Catalytic is a cloud platform for companies to create Workflows that coordinate people and automate common office activities. To use it, you would use our no-code Builder to build a Workflow that is made up of Actions. Think of a Workflow as a template for a process. Every Workflow has a trigger that governs when it starts. It could be manually started. But more powerfully, a Workflow can be triggered by an event such as an email, a certain time or date, a webhook, or something occurring inside another system such as a new deal in Salesforce.

When a Workflow starts, it creates an Instance that manages when and which Actions to start as well as all of the data that is generated as a result of the Actions completing. There are over 300 different Actions that run a huge variety of different types of activities so it's too large a concept to fully cover here, but it ranges from things such as sending out emails, creating documents, number crunching, and calling Web APIs. When the Actions are all completed, the Instance stops.

The key concepts to know for the purposes of pricing include:

Our Journey to Price Discovery -- Full of Slippery Slopes

The features I hoped for in our first pricing model was that it would be accessible (inexpensive), be transparent, and "feel fair". I also wanted to build a pure software company with minimal or no services, with mostly self-serve customers. After years of working in a B2B (business-to-business) model where prices were opaque, varied greatly from deal to deal, and started at very high prices, I was yearning for change. I felt the limitations of the traditional enterprise B2B model and how it prevented us from wide adoption.

Model 1: User-Based, A Safe First Take (Time +0)

Our first pricing model, rolled out Sept 8, 2017, was:

It was based on nothing more than looking at SaaS companies that we admired and a hunch.

A journey of thousand miles begins with a single step. -- Lao Tzu

We signed up a modest handful of smaller companies under this pricing construct. It was inexpensive, transparent, and easy to understand. We had a public Slack channel where everyone could discuss and opine on our pricing model because I felt we would benefit from a hive mind and also to allow everyone to feel ownership of the final model.

By November, we had collectively noted a number of challenges:

Model 1A: Abuse Prevention and Volume Discounts (Time +5 Months)

To address these issues, we introduced two constructs. We modified the definition of a license to be for "1 user and up to 1,000 standard actions / month". This was intended to prevent customers from expanding usage without adding users. We also added a volume discount based on the number of licenses with a maximum unlimited tier at $500K per month (which was approximately 14,285 licenses).

By the end of January, we had started to engage much more heavily with large companies and ended up doing more custom pricing "to get the deal done." We removed our pricing page, which moved away from my goal of transparent pricing. But I rationalized it as a temporary measure while we were "figuring out pricing".

Ingenuity was apparently given man in order that he may supply himself in crises with shapes and sounds with which to guard himself from truth.

-- William Faulkner, Light in August (1932)

In the first quarter of 2018, we faced a number of issues with our pricing model:

Many companies, especially large companies, struggled with variable pricing. Large companies had budgeting cycles and procurement processes, and variable pricing just wouldn't work for most.

We had expanded our functionality to include a number of data processing-oriented features and had started to look at data and ETL (extract, transform, load) companies as comparables. They often times had pricing like $20 / million rows created or other pricing where high volumes were both accommodated and expected. This made our 1,000 actions / month look far too stingy as getting to 1 million actions would require 1000 licenses or close to $50K per month.

We were also looking at companies that were "task" or "action" oriented, often in the IPaaS (integration-as-a-service) category. One such startup gave away 50K actions per month for free, and charge $0.0050 / task for the next 50K before halving for the next tier. Compared to those models, we were still charging multiple times more.

Finally, an industry called RPA (robotic process automation) was starting to gain significant traction around the concept of automation. Their pricing model was largely tied to the hourly labor wages due to their roots in the business process outsourcing industry. So an RPA bot might cost $500 / month and be capable of "working" 24/7 the entire month. It was a wonderfully effective (albeit dystopian) meme for the RPA industry as it moved the needle from negotiating over a unit of work to negotiating over the cost of an employee. The business case for RPA buyers shifted to replacing $60K / year workers with $6K / year bots. Relatively speaking, our pricing model would put us way above or way below depending on the use case, but customers, being savvy buyers and primed by RPA consultants, would usually selectively trot out the ones where we were well above.

At the same time, we were tracking our costs and, on an action basis, our infrastructure costs per task was about $0.01 / action. Our overhead costs however was the real challenge as we were growing our team faster than we were growing our revenues.

Model 2: Consumption-Based on Action Usage (Time +9 Months)

Faced with these challenges, we began a great internal debate about our pricing model. Driven by the RPA tactic of comparing against labor costs, we debated about gainshare models where we tied our revenue to headcount reduction. But I hated the idea of building a company around automating away people when we began Catalytic as a way to make people's work lives better.

Around Q2 2018, we eventually settled on a model where we equivocated an action to an amount of labor, and tried to package in a way that felt like an RPA bot. Our rationale was that we would charge 1/10 of an average office worker's output. Based on our own (not overly scientific) time studies, the average time savings for an action was 30 seconds. If an average office worker put in 160 hours per month, the equivalent would be 19,200 actions. Using these data points, we came up with a model where an action was $0.025 / action. But you had to buy a "bot" of time as a unit. So at this point, we introduced a pricing model that was:

It was simple for sure. But we ran into problems with the model right away.

First, it was confusing to customers and didn't map well in actuality to either a person or prevailing RPA bot pricing models. Actions were too varied and while it would be easy to see one Action might save several minutes (i.e. creating a document), it was difficult to justify other Actions (i.e. finding a Date in a string).

Second, as we created more data-oriented actions, a number of workflows would often process 1000s or more actions to do basic spreadsheet style calculations that would take a person 5 minutes to do. The time savings metric, largely due to the data processing actions, began to lose meaning. Multiple categories of actions would get confusing and difficult to track. Finally, our infrastructure costs were the same so there was a significant margin issue emerging that we were just ignoring for the time being.

Based on our current customer examples, there is low correlation between the amount of time saved and the number of actions performed. If we think of a virtual worker as performing similar amounts of work as a person, the average of our current examples would be around 10,000 actions completed per month, but there is a high level of deviation from a minimum of 200 to a max of 60,000.

-- Catalytic product manager (April 9, 2018)

Third, this set off a negative flywheel where, as the price went up, the savings for the necessary ROI would go up, and the complexity would go up. That put us in a position where the initial use cases were often very complex. While our platform was reasonably easy to use (or "no-code") for simpler use cases, complex use cases could quickly become difficult for newer users. This in turn created a ripple effect where we needed to provide professional services to do the building for our customers. Initial use cases were often selected from the use cases rejected by the RPA team as "too complex" or not suitable. Well, it turned out that they often weren't suitable for any currently available technology requiring too much "AI magic" (grrr, best left for another article).

Model 3: Action Thresholds and Services (Time +15 Months)

In response to these dynamics, we leaned into professional services -- accepting that between the complexity of use cases and the still relative immaturity of the platform and documentation (even simple use cases were not yet at a state where users could onboard without our assistance), there would be no other way to get our platform into the hands of customers. I rationalized thinking if we just provided the initial push, we could teach them how to fish and not have to build up significant professional services.

We kept the same basic pricing mechanic but started to create a services offering to help customers get started. By November 2018, we had created an official pricing schedule along these lines:

Notice that we set a new floor of 4 bots of price. But we do give 5 bots of Actions. This was our attempt to address some of our higher costs, although in retrospect, it was not a very good solution.

As you may have come to expect by now, there were a number of new problems we quickly faced.

By December 2018, we set out to standardize the sales process. We created a pricing tool for sales and the lowest quote was $12K. However, practically speaking, most quotes would be over $50K as we were pushing a "center of excellence" service for $50K and professional services at $2K / day. We had also brought in a number of people from RPA consulting, where services were the proven way to get established with customers, and it seemed to be the only way to get customers to buy at our new price point.

Our "entry price" had gone up quite a bit so now we had shifted away from smaller companies and smaller deals. Again, I rationalized this by telling myself most B2B companies have to shift to larger companies and we can circle back to the smaller ones once we get enough traction. That said, we did have some success here where we landed a number of larger deals. However, a fair number of our initial deals had a lot of services and some other pricing mechanics which would come back to bite us later.

One of the pricing mechanics that I will discuss here was to charge a fixed fee for the services only upon completion of the project. As a venture funded company the cash flow impact didn't worry me. However, easy to see yet we still did it, this created easy scope creep and long "implementation" cycles, as well as the need to bring on more services resources so we could parallelize implementations and customer acquisition.

SEAN: Our customers are basically getting VC subsidies for R&D.

VC PARTNER: Sean, that's fine by us. We are in the business of subsidizing growth.

With larger companies, especially in insurance and finance, we started to get a lot of questions and demand for "private cloud". This sent us down a rabbit hole of pricing out private cloud options, as well as discussing whether it was private tenant vs. private AWS cloud vs. private cloud vs. on-premise. Our initial estimate for what was probably closest to private AWS cloud was surprisingly high to me at about $10K / month, but that turned out to be probably way too low.

We also introduced a new capability for a special kind of action (which we initially called a hosted action) that would appear as a single action but in reality could do a tremendous amount of processing. While most customers didn't need many hosted actions, many customers were dependent on at least one hosted action that was being developed specifically for their use. This feature took us down a path where engineering resources were also acting as professional services.

With the further increasing of the entry price and introduction of engineering services (hidden behind hosted actions), we accelerated negative flywheel, taking us further away from our original mission. I rationalized this as necessary for the larger deals and features that we would eventually productize.

We spent the rest of the quarter and the first quarter of 2019 with this model in theory, but, in practice, cutting a lot of one-off deals. During our 2019 Sales Kick-Off, we had a brainstorming session where one of the teams proposed an employee-based pricing model (not user based). This was intriguing to me but I didn't immediately act on it because, to my mind, there were a number of issues - namely, how would the boundaries of the employee headcount be determined for larger companies? A large company surely wouldn't buy a product from a startup wall-to-wall.

Model 3A: Standardized Service Offerings (Time +19 Months)

In March of 2019, our product still needed a significant amount of hand-holding, so we wanted to make it easier to buy services, which we hoped would make it easier to buy our platform. As a result, we introduced the idea of "service packages". The packages would, in theory, focus customers on what we felt were our strong suits at the time. We offered up 3 different packages as well as our first foray into a population-based pricing model:

Quick Start Package - Workflow Automation

Quick Start Package - Unstructured Data Extraction

An "Experimental" Unlimited Use License (our initial nod to employee-based pricing)

While the packages were easier for customers to buy, they were quite problematic in execution. Implementations were all taking far longer than expected, and a number never reached conclusion. Delivery was poor due to a combination of poor expectation management, our own overconfidence in our ability to solve hard problems, and the frequent need to build more software as we went along.

The packages also ended up being problematic because we defined them based on the potential to differentiate from competitors rather than what we truly "easy but powerful" for our as-is platform. This led to high-value use cases but also high-complexity solutions that often ended up requiring engineering resources. Very few, if any, customers sold under this model ended up happy or expanding.

Step right up, step right up, step right up,
Everyone's a winner, bargains galore
That's right, you too can be the proud owner
Of the quality goes in before the name goes on
One-tenth of a dollar, one-tenth of a dollar, we got service after sales

-- Tom Waits, "Step Right Up" (1976)

Model 4: Enterprise-Focused Pricing (Time +20 Months)

In April 2019, we built a pricing model catering to large companies. We felt we needed to do what we needed to do in order to get a first win. So we added a Pilot Project concept which was a low dollar commitment that would allow customers to see what we could do. Then, our thinking went, it would move into production with a price point similar to latest pricing. And finally, there would be an unlimited use package available for enterprise-wide use.

Pilot Project

Base Production Pricing

Enterprise Pricing

We ran off this model for only a short while. Q2 ended up being a bad quarter (one of the first of many more in the next year). We never really saw evidence that a low-cost pilot would accelerate entry, and if the length of projects at the time was any indication, I'm not convinced it would have put us in the best light. We would have also paid for an expensive building resource for 3 months in return for $1,500 and, quite possibly, no subsequent contract.

By this time, we had convinced ourselves that we needed to sell almost exclusively into large companies who could end up being large deals (roughly defined, in my mind, as at least mid-six figures). We would almost need to in order to justify our low number of deals, low volume at the top of the funnel, and high expenses.

Model 5: Apple, Bushel, Orchard (Time +23 Months)

In Q3 of 2019, we made significant changes in sales with the idea of building a sales machine. With new sales leadership and a much expanded team in place, we began to revamp the entire sales process including pricing.

Building on the idea of selling something small, expanding, and then getting the full enterprise, we used an analogy of a customer first buying an apple to get a taste, then buying a bushel to have a larger quantity available, and then finally buying the whole orchard to have unlimited quantities available. And thus, we ushered in our next pricing model that I think of as our Apple, Bushel, Orchard model.

But first, as we worked out a number of details, we pushed out an intermediate pricing package focused entirely on large deals:

Clearly, we were going even further upstream pricing-wise and we were making a bit of progress but in isolated circumstances that would ultimately prove to be non-repeatable. At this point, we were really value pricing using a combination of helping the customer identify an initial use case that would justify the price and providing sufficient discount (or extra resources) to make the ROI work out. The allure of enterprise software is needing fewer deals to get to larger ARR (annual recurring revenue). The pitfalls - which we were seeing in spades - were longer sales cycles, more expensive resources to sell, and a loss of autonomy as large customers' voices grow louder.

We had also shifted almost entirely to us building instead of customers building -- to the point where, on July 25th, 2019, we had a 90 reply long Slack discussion on how to handle and promote self-service building!

In August, we realized that our customers were frequently asking for specific integrations to their systems so we start to develop a price list for those as well:

Over the next few months, we grappled with the apple, bushel, orchard pricing concept. What would be an apple and what would be a bushel? Basing it off the idea of having different product lines, we proposed to think of our modules as different products. By this point, we had been circulating the idea that we had six different "modules" of actions:

We created a model where we could price per module or provide bundled modules, and then we set out to embed this into the product since we would need to be able to control access.

For those who say to fail fast, let me say that, at least with this pricing model, we failed fast. Even as the features were being (prematurely) baked into the product, we realized we were going to face some problems. The biggest was that we were actually putting ourselves in at a disadvantage by not allowing customers to experience the full power of the platform. By having access to only one or even a few modules, a customer would be less likely to expand because they didn't realize the other capabilities. We also realized that the correlation between customer problems, solutions, and modules were not very clear cut, and that in the majority of cases, a solution benefited from having access to all modules.

Without having sold a single prospect under this model (I'm not even sure if we presented it to be honest), we moved on to the next one.

Coffee is for closers only.

-- Blake, Glengarry Glen Ross (1992)

Model 6: Population-Based Pricing (Time +24 Months)

By September 2019, we had basically set aside the previous month of work and reverted back to evolving the population-based pricing model. The first quote tool that we created was for companies larger than 10,000 employees:

This pricing model was entirely focused on large deals, and the problem was that most of our deals were not closing in this range. It was helpful for a very small number of existing customers that were ready to expand into an enterprise account. But almost all required a Faustian bargain with heavy services and engineering commitments.

Before we even rolled out this pricing model, we realized it would simply not work. The pricing was too high as a starting point. Few prospects would be willing to start at such a high price point for an unknown outcome. The few that were willing still required lengthy upfront and ongoing services before getting comfortable. If we really dissected the revenues and expenses, a fair amount of it was services revenue.

The one useful construct that we did discuss on this pricing model was that boundaries could be established by departmental ownership of processes. So if an HR department consisted of 1,000 employees, they could purchase a license for 1,000 employees and create processes for the entire company as long as the process was "owned" by the HR department. This definition was certainly challenging to enforce. Once we revised the pricing model to start at lower employee counts and price points, what we saw was that wall-to-wall enterprise wide deals were possible in smaller companies (sub 100 employees) with sufficient discounting, but we had a challenging time pricing any large company as we encountered departments, sub-departments, regional departments, and so forth finding out that even within large companies, there would be frequently business units of a dozen people.

During March 2020, the whole world went off the rails with the COVID pandemic. Our sales were not picking up and our top of funnel was not strong. We started an initiative to make trials available for free. This would prove to be a very interesting exercise in helping us understand the challenges of positioning and onboarding. Getting the right person to sign up, and setting expectations was a struggle. And onboarding users in a hands-off manner was not very effective because we had been operating under the assumption that our own people would help initially set up and do some side-by-side training.

Model 7: Population-Based Pricing, For Real (Time +30 Months)

In April 2020, after a few months of one-off pricing loosely based on the latest pricing model, we took what we had learned and created a new pricing strategy that gave customers four options:

Standard Limited

Standard Unlimited

Enterprise Limited

Enterprise Unlimited

In addition to standardizing customer success services, we also created a number of paid services packages:

Even as we rolled out this pricing model, we felt it necessary to note to the sales force that it was a guideline, and not a hard-baked rule.

By April of 2020, about 2 1/2 years after we rolled out our first pricing model, I decided our policy of transparently discussing and deciding pricing was no longer productive and shut down the Slack channel.

After running with this model for a few months, we found a couple of consistent concerns:

Model 8: Population-Based Pricing, Streamlined (Time +33 Months)

On July 9, 2020, we rolled out a new pricing model incorporating lessons learned:

Unlimited

Workflow-Based

We continued to offer the Kick Start and White Glove service options.

This pricing model definitely had its share of issues, but it also had some strengths. On the plus side, the unlimited model was very appealing to customers who were brought into the idea of citizen development. And since, from this point on, we pressed harder and harder into no-code citizen development, this differentiator served us well.

However, it still had a number of problems that I felt led to a longer sales cycle and higher CAC than necessary.

The Workflow-Based option was especially problematic:

The Unlimited option also had its share of problems:

Both models were still too expensive as entry points for many customers, who were often times either unfamiliar with automation and needed evangelizing, or perhaps worse, were experienced with automation but skeptical from past struggles.

Additionally, price, value, and our expenses were completely uncorrelated leading to customers that paid little using a lot of our infrastructure costs, customers with that paid a lot using far less (but also perhaps getting a lot more value). While it likely wasn't possible to align all three, it seemed important to us to at least align revenues to expenses.

Trials were also a mixed bag. When used as part of our sales process, they were a success. One of our sales reps had close to a 100% close rate once he got the prospect started on a trial. It was both a tool to qualify and build conviction. On the other hand, we had over 400 trial sign-ups with less than 10% actually building anything, less than 3% building and running anything, and 1 conversion. I believe this was due to a combination of factors: 1) we didn't align users expectations well upfront, 2) we didn't guide to getting started with easy workflows (opting instead to go for high value), and 3) we hadn't invested in product onboarding. I could write a whole other lengthy article on our story around trials. But suffice it to say that I could see that trials could be powerful if we managed to dial in attracting the right people and better product onboarding.

Another important realization at this point was that we needed to optimize our messaging and initial use cases for, first and foremost, easy to build on Catalytic and, only then, moderate-to-high value processes. Previously we took the approach of trying to maximize value and bending Catalytic to be able to accommodate. However, as we analyzed our customers, we realized that there was the strong correlation between happy customers and customers that were self-service builders. It was a day and night difference. With few exceptions, every customer where we had leaned in heavily on with services or engineering was unhappy, while almost every single customer that had their own builders were happy and used the platform much more. We analyzed what customer builders were doing and realized that there were strong patterns in what they used. In order of usage, it was:

This was not too dissimilar from our six modules concepts. However, there were important key differences. Customer builders used what was easy and managed to stay out of trouble by not building overly convoluted and technically challenging solutions. They were managing to find the appropriate use cases, rather than trying to tackle everything.

We began to adapt our own messaging to build on the idea of promoting what was easy to do on Catalytic and letting customers find the right use cases. We stopped highlighting text analysis because the solutions frequently required very technical users, if not engineers, and often produced unimpressive results. We stopped offering browser automation because, like the RPA stories we frequently heard, browser automation was indeed technical, fragile, and required constant maintenance. Even integrations we began to diminish in our story telling so as to not conflict with IPaaS vendors.

By reducing our feature footprint, we could reduce our product roadmap. And perhaps more importantly, we made our product easier to understand, and reduced the number of people who would resist us.

This is no time to make new enemies. -- Voltaire

Model 9: Consumption-Based, Evolved (Time +50 Months)

With all of this in mind, in December of 2021, over 4 years after our first pricing model, we created our final pricing model before being acquired. It was, in many ways, a return to our roots. It was also tied heavily to and dependent on investing in product onboarding. The model provided for three different cases:

Explorer Plan

Premium Plan

Enterprise Plan

These 3 different plans covered a wide variety of situations allowing for the full customer journey starting with someone initially skeptical and needing to try it out all the way to becoming a strong believer. We had seen plenty of customers become strong believers but we hadn't yet figured out a way to repeatably address the earlier part of the customer journey. The Explorer Plan covered the individual learners, allowing them the time to learn and build, to become an advocate. The Premium Plan covered the early adopter and also made customers self-select use cases that would fit the ROI. And the enterprise plan would be the most cost-effective solution at scale.

We never got to fully roll this pricing plan out, and we still had a number of product onboarding enhancements that we would have needed to fully dial it in, but it was the end point of a very long journey with a lot of lessons learned. It addressed a number of the issues that we had (leaving some still open such as small companies being able to drive up large infrastructure costs, but that was still an edge case). However, I expected that there would still be some problems.

I expected issues with sales since the smaller deals wouldn't make any sense for a sales person to pursue. In my mind, I imagined us having sales focused on premium plan users who were starting to hit their caps and/or focusing on channel partners.

I expected issues with the Explorer Plan users running out of tokens. I imagined we would make it easy for users to get more tokens, and that the main value add of the lower tier Premium Plan would be predictability and better customer support.

I expected that we may have to tweak the Token quantity over time as we monitored usage. We picked numbers that were roughly based on actual usage, but it was hard to know where things would actually end up.

I expected that some customers would have anomalous months, or that they'd have a situation where a runway workflow consumed way more Tokens than they were prepared to pay. I imagined that we would have a forgiveness policy that customers could invoke occasionally (annually?).

Finally, I expected that, in addition to the onboarding enhancements, we still had a lot of work on product instrumentation, controls around limits, and a marketplace / gallery.

Lessons Learned

So after all this, what would I say I learned? Mostly, I learned that pricing is far more complex than I ever imagined. I learned that pricing, sales, and strategy are inextricably linked, and that it's a brutal knife fight where no one leaves uninjured. It was the ultimate school of hard knocks. Here are some of the lessons that have been burned in my mind as a result of the years-long battle.

Pricing is strategy

Maybe that's an overstatement, but, if I were to do it again, pricing is one of the main things I'd focus on and personally own. It has a huge impact on everything else from the way you build your product to the way to you go to market to the way you hire people.

Unfortunately, I started us off on a wobbly footing from the start by not sticking to my initial beliefs -- the ones that our earliest employees signed up for, the ones that we began the entire company around. Sticking to our model wouldn't have guaranteed a better outcome, but it would have allowed us to remain more focused and, more importantly, execute against vision. Instead, I think we started to chase after fast revenue and a high valuation.

I don't mean that I wouldn't have made any pricing changes. But we swung from SMB and PLG friendly pricing to full blown, traditional, consulting-led enterprise pricing. That's too much of a swing, and the GTM (go-to-market) behind them are so fundamentally different. The people to make each succeed are fundamentally different. And, for me, my heart was only ever in one of them.

Decide, and there is such a thing as too much transparency

I have had a long career leading demanding, high-performing people, and good people push back, as they should, because a leader can't get it right every time.

But here I think I let the internal debate weigh on my decisions too much. On one hand, our pricing model needed to evolve and evolve quickly. On the other hand, every time we set out to make changes, the doubts in the room, understandable after so many changes, got to me. In retrospect, I should have limited the discussion to fewer people, and made the decision sooner.

There is no perfect pricing model

At least I don't think there is a perfect pricing model. Some are better than others, and some are downright clever as all get-out. But most will have flaws and it's better to make small incremental adjustments over time than to make big sweeping changes in search of the perfect model. In retrospect, I should have accepted the flaws in our early models and focused on fixing them instead. We would have focused on surviving with a lower ARR, lower growth initially, but the potential for exponential growth later.

Pricing can capture value or be a utility, but not both

To frame this up, capturing value means that we could try for a gainsharing pricing model where if the customer saves $100, we get paid $10. Being a utility is just like electricity. As consumers, we pay per watt regardless if we are powering a life-saving machine or if we are powering a music player for ambience.

Although I knew from the outset we couldn't capture both, in retrospect, looking at our history, I think we still tried. Or at least, we increased our price point to a point where we were trying to capture value for larger companies with higher ROI use cases. That ultimately led to investing in more consulting-minded people, or perhaps it went the other way - hiring more consulting-minded people led to going after capturing value. This just goes back to my point about "Pricing is strategy".

In retrospect, I should have kept us focused on utility pricing. It's really the only pricing strategy that can lead to widespread adoption, which was core to our mission. Capturing value can be incredibly lucrative, but it serves a different purpose and requires different people. We had a conflict internally between the two mindsets.

Pick the right comparables

Our pricing strategy, like most, was driven in part by competitors. The challenge we had, and I think a common challenge for platforms, is that competitors seemed to be everywhere. We had a bad tendency to say a company was a competitor because we had functionality that could do the same thing. That ended up being a dangerous mindset. Everyone appeared to be a potential competitor. And as we felt we could do more and more, we were also more likely to antagonize someone in every sales situation that would feel they already had a solution (typically the owner of the solution). This also led to feature creep, which is incredibly easy with a platform, increasing complexity and further confusing buyers who, even if they wanted to say yes, often struggled with getting us in the door because we certain features overlapped with incumbent software.

This spilled over into pricing as well. Tempted by high valuations in adjacent categories, and clouded by our judgement that we could do the "same thing, but better", we started to evaluate pricing for too many categories and too many different units of measure, models, etc. came into the mix.

In retrospect, I should have focused our competitive landscape on a single category. We knew early on that we really belonged in one but we felt it was boring and wanted to be part of a faster growing category. Instead, we should have done the "reinventing an old, abandoned space" strategy.

Productizable is not a product, and definitely not GTM

Almost everyone already knows that a software company should not build custom stuff, but we managed to find a way to rationalize it, which is I think unique to creating a platform.

When a feature was needed that we didn't have, we would often build it thinking that it would be "productizable". This started small and in ways that were indeed productizable, and did get productized. These were often small features or highly reusable actions useful to nearly every existing customer. But then it continued to grow and we ended up with a small team building actions for individual customers that were definitely productizable, but would require a separate GTM effort to get new customers. In other words, we were building for potential, future customers. In retrospect, I should have at least limited these to perhaps one at a time, and ensured that we had an actual GTM motion behind each one.

Making product and GTM investments take time and money, and not ensuring that they were always lined up with each other was one of my biggest mistakes. There is no such as thing as "just move a button" any more than there is "just run a campaign".

High prices lead to high CAC lead to more consultative selling lead to more enterprise

This is obvious in retrospect. But it is a feedback loop. We raised our prices because we wanted faster revenue which led to higher CAC. It also led to the need for a more consultative sell because no one plops down six-figures for something that isn't proven. If I'm wrong, please email me that person's contact information.

Once we had a high price, expensive consultative sales, expensive marketing and outbound, it becomes hard to go back down on pricing. As a startup founder, I rationalized the move to larger deals as temporary but it is really a one-way road. The only exception for us was pivoting moment driven by poor performance, COVID, and significant layoffs. This both gave us the opportunity and forced upon us a reset.

Pricing and commissions drives sales behavior

This is obvious as well. But the question is what are the various mechanics that have to be considered. Sales people are in the business of making money and will be your friend or foe in finding the weak points of your pricing model. They shouldn't drive your pricing model, but they will have the most (potentially the best and possibly also the worst) feedback.

As an example, we had a commission plan that gave a small increase for multi-year deals. As an ARR-based company, this did very little for us other than, in theory, help with churn. However, customers often tried to add a termination clause of some sort, if not for convenience, then tied to some activity that they could easily cite later - lack of progress, end of year, etc. So by incentivizing multi-year deals, we were inadvertently driving sales to push for multi-year which created sales friction and, to add insult to injury, added yet more friction when customers would negotiate to essentially undo any potential benefit to us from it!

Aligning commission plans is notoriously difficult but pricing plays a big role.

As another example that we were just starting to have to contemplate. What happens when you introduce a free plan and/or a low-priced plan? How will the outbound and sales team respond? How do they stay incentivized, or better yet, get excited by it? Or if you have a free plan, how do you attract the right sales people to get the bigger deals?

Don't bake into the product what is still experimental

Ultimately pricing should be baked into the product. And if I were doing it all over, I may have incorporated pricing right into the product from the get-go simply to specifically hamper my ability to range widely on pricing.

That said, one thing we learned from our module fiasco was that we weren't really ready to bake it into the product. When we adopted the last pricing model, Model 9, we kept that in mind and built up everything outside of the product first. We figured that we could bake it into the product only after we felt confident it was a model we could work with for a "long time".

Let customers help match price to use cases

We spent too much of our time thinking about how to price for customer use cases. Instead, we should have focused on creating valuable functionality, clearly communicating the problems that our platform could easily solve, and priced with a margin goal in mind. Then we should have allowed customers to find the right use cases, adjusting our roadmap accordingly, and let the market adjust our pricing.

Conclusions

As I look back on our journey, I realize that, while we could have made fewer mistakes, trial and error is an inherent part of the journey. Where I think I introduced a lot of friction was the fact that I had a prior successful enterprise startup experience so the enterprise motion was familiar and comfortable to me. However, my heart was focused on a PLG motion yet I lacked the experience. And I never built a team with experience in PLG or selling to smaller companies, so the gap between my vision and our experience led to unnecessary mistakes and friction.

That said, hindsight is truly 20/20 and I don't know that any of the changes I would have made would have ultimately made a difference. There's so much more to a startup including the people, culture, product, GTM, customers -- all of which I could tell many more stories.

I am happy that we had the opportunity to build Catalytic, and I am satisfied with the outcome. We set out to conquer the world and, to that goal, we fell short. However, in six years, we went from crude scribbles and slides to a robust product processing millions of Actions on a daily basis. We built a business from zero to significant revenues with many world-class companies as customers. We built an awesome platform that has been transformative to a number of companies big and small and changed many individuals' careers for the better. Of these accomplishments, the entire Catalytic family - my co-founder, employees, family, investors, friends, and other supporters - should be proud.

I am proud to have been part of it all.

All writing