How do you build an actor in such a way that it's considered virtual?
Let's talk about costs. What is cost in software development? Cost can be many things, but let's boil it down to two core aspects: time and tooling. The cost of time is generally multi-faceted; you have the cost of time to think about the new feature, the cost of time to develop the new feature, the cost to test the new feature, and so on. The cost of tooling is pretty straightforward: how much are the tools that I need? You can also lump in developer salaries, because when you think about the cost of tools, the developer is a tool needed for a feature. I know it's a bit dehumanizing, but it's the reality of doing business.
When we look at all the costs that go into feature development, like most industries, the initial cost is always upfront. You have to pay salaries, feature development costs, and then there's the initial cost of delivering the feature on a new or existing platform. Generally the delivery isn't too expensive, but every once in awhile, that's the most expensive part. Looking at all of the costs ahead of us, how do we understand the value of a feature? That is, how do we make money on a feature?
To really understand the value of a feature, it's important to know your baseline deliverable. For example, as a ropemaker, my baseline products are ropes. What features do my ropes have above the fact it's a rope? Well, it can be tied into sturdy knots. That's a feature. My ropes come in many colours. That's not a feature, that's an attribute. My ropes can survive being wet. That's also a feature! It's important to understand ahead of time what the difference between features and attributes are in your deliverables.
So back to the question, how do we understand the value of a feature? Well, it's important to understand the value the feature brings to the customer, not the business, and this is very important. If having my rope handle knots that come undone easily because I want reuse of my rope for customers, but the customer was maimed due to an accident when the knot slipped, that's not a lot of value to the customer, just to me, the business owner. However, if I don't really care about the lack of degradation when my ropes get wet, but the customer cares because they're going to use my ropes in shipping where they'll be soaked consistently, there's lots of value to the customer.
Okay, so but how do we understand the value of a feature? You have to look and see what needs this feature fulfills and how important that need is. That will tell you how important that feature is - i.e. the more important the need the feature fulfills, the more value to the customer. We know the importance, but what is the value? The value is determined not only by importance, but the criticality of feature failure. How much will the failure of this feature cost my customer? If the answer is, a lot of money, then it's likely safe to assume you can drive a hard bargain. The next question is how much is reasonable to charge for this feature?
Now, I am not a business major, I'm a technical guy. That will always be a hard question to answer, but the good news there are options, and we can look at them programmatically. Programmatically in the methodical sense, but yes, there will be code, never fear.
There are lots of cost models for software. Let's take a non-comprehensive look, shall we:
- Free: Linux
- Freemium: Winrar
- Flat Fee: RegexBuddy
- Consumption (Pay as you Go): all public cloud providers
- Tiered: VMware vSphere
- Subscription: Netflix
- Feature Locking: ???
I mean, just...what the fuck, right? That list is way too long. Some of them are obvious, but feature locking? What the fuck is feature locking? Well, my friend, feature locking is basically giving a core product, but you have to pay for features! Some great examples: buying children's toys but they don't come with batteries, buying an Xbox but it doesn't come with a controller, buying a car but it doesn't come with tires, etc. Software is often no different. You see this commonly in mobile software, especially games. Oh, here's the base game, but if you want this core feature that is really a necessity, you need to make a 99 cent purchase. ahem
So what is the right way to charge for a feature? Well...there are lots of right ways, and then there's the way I see it. I think there's a cleaner way to charge properly for a feature.
Feature As You Go™
Let's talk about why I think Feature As You Go is the right way to charge for features. I think there's two features (hurr durr) that really matter in this cost model:
- Feature Premiums
The core model is really about Consumption. I don't believe a customer should ever pay for a pool. They should pay for what they actively consume(d) and nothing more. Diving into that, now we get to look at Feature Premiums. Feature Premiums are percentage premiums above and beyond the core product price, on a feature-by-feature basis. For example, if the base product does X, and you want Feature Y, you have to pay a percentage premium for the feature. By leveraging Feature Premiums with a Consumption model, you get the most important part: market fairness.
Within the greater corporate market, there's a very distinct difference in B2B customers: Commercial and Enterprise. In the Enterprise segment, you have these massive companies with near unlimited budgets that often want to make sure they have whatever they need, so they'll likely buy best in class of whatever solves their problem at whatever scale they need. Looking to the Commercial space, these are generally much smaller companies, but there are a lot of them. Like a lot of them. They don't have unlimited budgets, but they need either the same things Enterprises need, or some subset at reasonable prices. If Commercial companies needs aren't as grandiose, and generally a subset of an Enterprise's needs, why go after the Commercial space?
“I'd rather have a million people give me a dollar than one give me a million."
The founder of St. Jude's Children Hospital, Danny Thomas, said that. While he was talking about public engagement, the model is still quite valid. Let's change it a bit:
I'd rather charge a million people $1 than one person $1m because if I have to start charging $2, now I have $2m
Looking at market fairness, from the software vendor perspective, I want to make sure I am properly reaching both Enteprise and Commerical segments. The sanest way to do that, outside of discounts, are consumption-based feature premiums. That way both companies get exactly what they need at the scale they need it, without paying often extortionist licensing costs for capacity and features they may never use.
Let's take a data-driven approach to this, as well and make sure we can understand the impact of feature premiums when it comes to profits. So let's set up some theoretical software with feature premiums and do some math.
|Base Per-Unit Consumption Price (no features)||1 Currency Unit|
|Feature Set X||10% Premium|
|Feature Set Y||15% Premium + Feature X Requirement|
|Feature Set Z||20% Premium + Feature Y Requirement|
So we want to put Unsinn Platform up for consumption at 1 Currency Unit. Seems reasonable. Now, the Feature Premiums make sense, but why do they have a requirement on the previous features? This is a fairly common model, especially in platform-land. It's very hard to deliver higher-order, higher-value features without taking dependencies on the lower-level features which enable them.
So let's look at some theoretical scaling models, and talk about it a bit. Here's 1000 Units deployed to the Unsinn Platform.
You are looking at a Feature As You Go price comparison. The level of consumption isn't inherently interesting, but it's the price difference between customers who aren't use any features (or a subset of all features) against the customers that are using all features. On a per billing cycle basis, you can see that we're charging 517.48 more Currency Units per 1000 Units from customers who are using all features vs those using the baseline product. Looking at the middle set of customers who are using some subset (Feature Set X and Feature Set Y), we're still charging more than just the base product. While that price difference is smaller, it's still more than the baseline feature set.
Now, I bet you're thinking, why does it matter who is using which Feature Set? Well, let's harken back to Commercial vs Enterprise customers. While Commerical customers are much smaller, you can see many more of them than in Enterprises. Let's take a look at more scale.
Now, I know this graph looks similar, but take a look at the axises. At 1.3M Units, you can see the price difference really comes into play. You're still making ~686K Currency Units from customers who use all features (re: Enterprises), but you're also not inherently alienating your mid-market customers because you're still giving them more options than the base product through gated Feature Sets, and making them pay for what they use. This is the inherent value add in the Feature As You Go model: customers pay for exactly what they need and how much of it they use.
For shits and giggles, let's look at 10B Units and how we can still manage to capture the revenue generation from Enterprises.
At 10B Units in circulation, per billing cycle we're seeing an extra 52M charged to Enterprises who are using all features, but once again, we're still capturing Commercial customers who are using some subset of features.
SHOW ME THE CODE
It's actually pretty straightforward.
If you try and run the code above, it's really not optimised, and it used 24GB of RAM to run as-is. It's also important to call out I made a lot of gross generalizations about the market, but I really wanted to demonstrate the revenue differences and potential when it comes to Feature Premiums.