This post is about my software product Hyperion. You can read more about it here.
Once I decided to offer a generous free trial, the next step was to figure out the pricing. I was hoping to postpone the decision as long as possible, but this proved to be unrealistic. Potential customers (understandably) wanted to know what the pricing would be in future years. Even if Hyperion was free for the 2020 PIT count, they would still need to spend time getting acquainted with the software and training their volunteers. They didn’t want to do all that if they would then be priced out of using it in future years.
I didn’t want the lack of a price to keep people from trying the software, so I had to come up with one.
A lot goes into pricing. When you price your product above or below competitors you’re making a statement about the value of your product relative to theirs. This change is magnified when the difference in price is dramatic (2x or 1/2x the price).
When it comes to software, another thing to consider is the “cost” of the status quo. How much time or money are they saving when using your product compared to nothing at all? How much more revenue will they generate? There’s a strong status quo bias. You will need to build something 10x better than the status quo to get people to switch — not 2x or 3x. Many software products never take off because Excel works well enough.
Another consideration: how many customers do you want to have? If you want (for instance) a million in yearly recurring revenue, then you can do that in a few different ways. You could have 100,000 people pay you $10/year, or 1000 pay you $1000/year, or 100 pay $10,000/year. If you’re targeting mice ($100/year), then you better have a lot of potential customers, an economical way to reach them, and a streamlined onboarding process. If you’re targeting elephants ($100,000/year), then expect a long, high-touch sales process.
I started by looking at my major competitor’s pricing. It wasn’t posted on their website, but through several customer conversations (that I was having anyway) I collected a few data points.
I heard that the pricing was based on Annual Renewal Demand (ARD): an industry-specific metric tied to the funding the organization received from the federal government. Larger organizations told me the base price for the software was on the order of .1% of ARD per year. Smaller organizations told me it was more like 1% of ARD per year. I also heard that many organizations paid dramatically more than that base price for custom features and support. Last, I heard that the larger organizations resented paying as much as they did, but felt trapped because they couldn’t go back to doing a PIT count by hand.
I decided to price Hyperion using a similar strategy as the competitor (based on ARD) – pricing based on funding seemed reasonable and fair. I also decided to go cheaper. At the end of the day, I wanted my software to be affordable to all the organizations conducting the PIT count, and I didn’t want anyone to resent paying for it.
Ultimately, I used a three-tier pricing structure. 2k/year for the smallest organizations, 3k/year for most, and .07% of ARD for the largest. Based on what I saw, that would make Hyperion the cheaper option for organizations of any size. I also decided to make that price all-inclusive. I wasn’t going to charge organizations to implement features. If adding a feature was the correct decision for the product, then I would build it. If not, then I wouldn’t. I wasn’t doing the organizations a favor by adding a feature – they were doing me a favor by telling me what they would like to see in the product.