7 Dimensions of Limiting Freemium Products

Pricing your application is always an issue of hot debate, with much interesting literature and guides in the space. While there are only a handful of macro models out there, or as Shelly Palmer puts it: “I pay, you pay, someone else pays”, there are variety of ways to combine and segment for various audiences.

The increasingly popular “freemium” model, brought into the mainstream by pundits like Chris Anderson, delivers a free version of your product that enables users to try it out, and then charges for up-sells in the form of services, support, or premium features.

While the basics are easy to understand in this model, getting the details right is quite tricky, as it gives rise to a number of questions: What do you limit? How much is too much to give away? What is a “premium” feature?.

While Anderson gives a little guidance (see slide 17) on how to do this, by advising that premium features should be “time limited, feature limited, seat limited, customer limited”, it’s a little too simplistic for my liking. These are challenging decisions that require you to make some important decisions on how you shape your customer experience and prioritize development initiatives, so it seems we should be thinking deeper about these ways to limit the free version, while creating the right incentives for upgrades to the paid version(s).

Let’s look at some of the key dimensions that you can use to limit your application.

Seven Dimensions of Limiting Freemium Products

1. Capacity: For applications that require storage or bandwidth this makes a lot of sense, along with limiting based on users. You can also imagine any kind of throughput metric (e.g. downloads, uploads, # of items) would also fit the bill here.
2. Capability: Limiting the ability to accomplish certain “jobs” is another way to go. Often applications will try to cordon off “power” or “enterprise” use cases in its free version.
3. Specificity: Particularly in data-centric applications (e.g. analytics), limiting the granularity of reporting is another alternative. Another instantiation of this dimension is personalization, in the sense that it’s used to provide more relevance to an individual user…not to be confused with our next item.
4. Customization: This dimension could take the form of any of enabling users to save settings and preferences, adding their own images or custom fields, provisioning vanity URLs, or providing source code.
5. Timeliness: Changing the latency of information is another way to limit applications, especially those that are information driven (e.g. time delaying stock quotes).
6. Usage rights: Often you’ll see non-commercial use of the application be free, whereas increasing levels of commercial activity be charged for. Sometimes this is enforced via limiting features or adding watermarks to images to ensure usage rights are adhered to in the free context.
7. Expiration Date: As Chris Anderson points out, providing the entire application for free for a limited time is another method that can be employed.

Choosing which dimensions to employ
While there are no hard and fast rules for which dimension you pick to limit your application — and in most cases it will be a combination of dimensions — here are some guidelines.

• Deeply understand the problem your application solves: The goal of freemium is to enable a compelling, but limited, use case for your customers. So, having a clear hypothesis of what that problem is from the outset will enable you to select the right dimensions to employ. Of course that’s likely to morph over time, but picking a reasonable starting point will help guide your decision.
• Keep it simple: For a freemium model to work effectively to scale, customers need to understand the value you provide through using your free version, and therefore how their experience would considerably improve by upgrading to the premium version. So, making the upgrade very clear is important, and the more dimensions you layer on the harder it will be to translate those features into creating value.
• Don’t be paralyzed over “giving too much away”: If you have something customers want it will be clear, and if you don’t it’s a moot point. Its harder to succeed than fail, and if you’ve adhered to the other principles I’ve outlined, you’ll get to market with your minimum viable product, such that there is a backlog of stuff that you could put in, but more importantly it’s what you learn from your initial launch that will help guide further feature development.

Hopefully this provides some clarity – are there other dimensions I’ve missed? Are there other resources here that you would recommend? Feel free to comment and share your expertise.

Like it? Share It.
Shortlink: http://bit.ly/limitingfreemium