Pricing Your (SaaS) Product for Government

Pricing strategy is one of the most under-appreciated elements of a SaaS business. Many SaaS companies struggle with how to price their product. It’s a particularly tricky element in the govtech space given the unique and burdensome process of public procurement. This combination of uncertainty and a unique buying environment usually results in founders randomly determining their pricing and vowing to revisit at a later date. That’s a bad strategy.

What’s unique about pricing in govtech?

The visit-it-later pricing strategy is common for founders in all SaaS verticals. It’s much harder to take that approach in government for two reasons:

1. Government contracts are public record. This transparency means that other customers and your competitors have access to your pricing strategy at all times. This makes price changes, time discounts, cash discounts, and every other used car sales tactic much harder in this market. It’s a forcing function for price consistency and articulation. It doesn’t mean you can’t change pricing, it simply means changes in pricing need to be applied to the entire customer base, otherwise you envitably get the question; “why is that city paying less than me?” This puts an enormous amount of pressure on getting your initial pricing strategy more right than wrong. Pricing for government is much less iterative than say, pricing for SMBs. As we will see later, publicly available contracts can be beneficial for startups in the space when you determine your pricing strategy.
2. The number of customers in the govtech market is largely fixed. Most industries, especially enterprise SaaS and consumer SaaS have enormous turnover in their customer base. There are 550,000 new business started every month in the United States. That means, for an enterprise SaaS company, the customer base has new blood all of the time. The allows for companies to constantly test and iterate on their pricing models. In contrast, the number of cities and counties is around 22,000+/- and largely stays the same. Combine the stagnant number of potential customers with publicly-available contracts and the result is an environment much less than conducive to constant changes in price.

How should you price your product?

The price of your product is your signal to the world about how they should value your product. Overtime, price and value start to separate as the best products provide far more value than what they cost. However, at the moment of purchase, the price sets an expectation of value for the buyer. Buyers in all markets, but particularly in the govtech market, evaluate products on a relative basis. How does this product compare to what I am currently doing? How does the price of product A compare to the price of product B? If your price, and therefore the value signal you send, are arbitrarily determined you risk sending a signal that is incompatible with value.

In my experience, pricing your product for government boils down to four questions:

1. What is your product replacing and what’s the cost (direct or indirect) of the current solution?
2. How much agency is required to influence the buying process?
3. Is your product truly out-of-the box or does it require localization?
4. Once onboarded, can a customer self-serve or is a customer success representative required to extract full value from the product?

*These four questions must be answered together as they are very much interrelated.

What is your product replacing and what’s the cost (direct or indirect) of the current solution?
Many govtech products are replacing human workflows or consultant services. The answer to this question likely lies in publicly available information. If you’re replacing human workflows, you can generally get a sense of costs (i.e. salaries) for the people / roles performing that work in the agency. In the case of consulting services, the contracts, scope of work, and price are all available online. This information can serve as a guide to determine the existing costs for the “solution” your product provides.

The general rule of thumb for SaaS products is your product needs to be 10x better than the existing solution in order for your customers to justify abandoning the old solution and adopting your product. This 10x improvement can come in two forms; a)1/10 of the price of the existing solution or b)10x better output for the same price. I’ve found, for whatever reason, most startups tend to lean towards the former, charging less for a new product and attempting to win business on the basis of a lower price. Only you can determine if that’s the right pricing strategy, but I would caution companies to first explore what would need to be true if they charged the same amount and provided 10x the value.

How much agency is required to influence the buying process?
This is the question most companies overlook. Choose the statement that best describes the level of effort required to sell your product:

1. My product can be sold without any human intervention. ($10)
2. My product can be sold with minimal human intervention (chat-based sales support). ($100)
3. My product can be sold via web demo with no in-person meetings. ($1,000)
4. My product can be sold with a single in-person meeting. ($10,000)
5. My product can only be sold with several in-person meetings. ($100,000)

This is a question that requires govtech startups to be very honest with themselves. I find first-time govtech founders tend to think they will be able to sell their product with no in-person meetings, and end up severely underestimating the agency required to get a sale. This approach ends up being a double whammy. They price the procuct with that assumption in mind, end up doing several in person meetings to obtain the sale, and the result is unit economics that aren’t sustainable.

As you can see at the end of each statement, my rule of thumb is add a zero to your price with each subsequent level of effort. These statements represent effort, time, and often expertise required of your salesforce. Those factors will ultimately determine your cost of acquisition and whether or not you can endure as a business.

Is your product truly out-of-the box or does it require localization?
This is a question about level of effort for your customers to find value. Again, choose the statement that best describes your product:

1. My product is out-of-the-box and requires no localization.
2. My product requires minimal localization done by the customer.
3. My product requires some localization done by our team and some by the customer.
4. My product requires significant localization done by our team.
5. My product requires significant localization done by our team and the customer.

Generally speaking, anything that requires extra effort on behalf of the company, needs to be reflected in a price increase. A common example of this is set-up fees. While it’s uncommon, I personally believe the opposite should also be true. Anything that requires extra effort on behalf of the customer, should result in a price reduction. Let’s call this the anti set-up fee. If both parities are required to do work, this should also be considered in the form of time delay for the customer to extract value. A great example of not considering this is companies that sign 12-month agreements with customers and then require 4-months of set-up time, leaving themselves 2/3 of the contract term to actually provide value. This puts enormous downward pressure on customer success teams to deliver full value in a shorter period of time.

Not all govtech products require localization, however, anything involving the use of local data (parcels, permits, open data, etc..) almost always requires some degree of localization. Many enterprise SaaS companies push this localization onto the purchaser (i.e. salesforce pushes setup onto the buying company). Often times, government agencies don’t have the capacity or bandwidth to localize your product for their own use. In fact, many agencies are buying your product to avoid extra effort. In an industry dominated by consultants, requiring the agency to localize your product often feels like the thing you are trying to replace in the first place, human workflows.

Once onboarded, can a customer self-serve or is a customer success representative required to extract full value from the product?

The last factor to consider in determining price is the level of effort required to help your customer realize the value of the product. Again, the following statements represent a continuum of support:

1. My product is simple enough for a customer to onboard and use without assistance.
2. My product requires tool tips, but no human assistance.
3. My product requires human assistance, but only for onboarding.
4. My product requires monthly calls / meeting with customers + real-time help channels.
5. My product requires 24/7 support.

In my experience, I’ve seen two extremes play out in the govtech market when it comes to customer support. Companies either think their product doesn’t need support (when it does) or provide a suffocating amount of support (reducing the value of the actual product). Providing the right amount of customer support is often tricky and specific to a given product. The key here is understanding the cost structure of the required support and properly reflecting that in the initial price. Too many companies offer commodity pricing with a product that requires a ton of support, which puts them out over their skis on their unit economics. It’s almost always better to over-assume support needs early in a product lifecycle and price appropriately.

If there’s a single lesson from this post, it’s be intentional about your pricing strategy. Spend time on it just like you do your product strategy and sales strategy. Don’t let a lack of interest or curiosity about pricing be the reason you run out of cash just as your product is starting to find fit in the market.

Interested in getting a curated selection of the two most important things to read in #govtech every few weeks? Sign up here.