When you are building a B2B SaaS product it’s very hard to know what the appropriate price for your product is. Even if you magically found the correct one, it might not be the correct one next month when you made the product better and you are providing new values. That’s why you need to be constant experimenting with prices on your app.

When I started my career I was afraid of raising prices, of having to justify why they went up (I wasn’t even aware of grandfathering). When I started to learn that most entrepreneurs set their prices too low, my partner and I decided to set the price too high and then lower it if it was necessary. Without realizing we painted ourselves to a corner.

We didn’t want to just lower prices, we wanted to experiment with prices (switching from per-user to 3 plans, things like that). The problem was that anything we would come would cost a different amount for each customer. For some customers it would go up, and that wasn’t a problem, because we would grandfather them in. But for some customers it would plummet.

There were two options for those customers:

  • Lower their prices according to the new plans and lose the revenue.
  • Don’t lower their prices and risk them being very angry about overpaying.

Because we were a bootstrapped startup living month to month, every time we discussed this we would get stuck in a cycle of what-ifs one or the other situation. Eventually one day we made a rule of forbidding talking about pricing (trying to get some work done, because we would spend days and days discussing pricing).

Eventually I found myself wishing that instead of starting with a high price and lowering it for experimentation, that we started with a low price and raising it for experimentation. We would have experimented much more. There’s another obvious solution which is not depend on the sweet revenue of those high prices. But even though it’s simple, I don’t think it’s easy… like sitting in front a pizza and not having a slide. Yeah… right!

Next time I want to increment prices over time and even then try to give myself room for experimentation.


Leave a Reply

If you want to work with me or hire me? Contact me

You can follow me or connect with me:

Or get new content delivered directly to your inbox.

Join 5,038 other subscribers

I wrote a book:

Stack of copies of How to Hire and Manage Remote Teams

How to Hire and Manage Remote Teams, where I distill all the techniques I've been using to build and manage distributed teams for the past 10 years.

I write about:

announcement blogging book book review book reviews books building Sano Business C# Clojure ClojureScript Common Lisp database Debian Esperanto Git ham radio history idea Java Kubuntu Lisp management Non-Fiction OpenID programming Python Radio Society of Great Britain Rails rant re-frame release Ruby Ruby on Rails Sano science science fiction security self-help Star Trek technology Ubuntu web Windows WordPress

I've been writing for a while:

Mastodon

%d bloggers like this: