Entrepreneurial Value for in-house development

"We can't measure the monetary value of a Feature". A common complaint, and oftentimes mere ignorance. It's economically disastrous for an organization that spends money on software development!

Here are a few simple, effective ways of making the value of development transparent even when developing complex in-house systems:

Core goals

Before we start, we need to understand that there are fundamentally two different reasons for developing software. While occasionally, these goals can be combined, they are usually distinct, and one of them takes priority.

Revenue increase

Some components allow the company to generate more revenue - acquire new customers, sell additional goods, etc. For those components, measuring feature value is very straightforward: The value is the difference in revenue that can be attributed to the implementation of a feature.

In these cases, the value of a feature can be found on the "Assets" section of the balance sheet - the difference between old and new assets.

Expense reduction

For established processes, most of the work is aimed at increasing efficiency through performance optimization - saving time or resources (e,g., packaging / fuel etc.) to reduce expenses.

In these cases, the value of a feature can be found on the "Liabilities" section of the balance sheet - the difference between old and new liability.

Equity generation?

Argubably, there may be features that turn out to neither generate revenue nor cut down on expenses.

Many people argue that "you got what you got", and proceed to treat such features as assets - claiming that they are becoming shareholder equity that doesn't show up as cash flow.
I, myself, would argue that this is not the case.

From a technical perspective, such features need to be candidates for removal - in software, every feature has code, and every line of code increases the product's complexity, and complexity correlates to the amount of work required to deliver future value -- hence, such features, though seemingly innocent, are technical liabilities!

Determine feature value

After the above is established, we will not discriminate anymore whether a feature's value is determined by an increase in revenue or reduced expenses. Instead of providing specific techniques or methods, this section focuses on thinking patterns that help in determining the value of feature.
These patterns can be selected or combined based on circumstance.

Value Stream thinking

Understand the operational value stream you are contributing to, and the place you hold in that value stream. Your contribution to that value stream is the leverage you have for development.
For example, when your value stream produces a revenue of $10000 a day, and after the implementation of the feature, it's still $10000 a day ... how much did the feature add? Maybe it reduced operating expenses. If, however, they are still the same, the feature did zilch.

Theory of Constraints is a great method of figuring out whether it's even theoretically possible for your feature to add value: if you're not working on the value stream's current or next constraint, chances are slim that you will add value to the organization!

Make of Buy thinking

There's an economics proverb, "If it's known, and you can earn money with it, someone is already doing it." In many cases, there's already a vendor solution that does the same thing you would be developing, and that vendor has a price tag attached to their solution.

While you still can't know if that's going to be the actual value of your feature, the NPV is capped at whatever this vendor is asking. So, for example, if you could buy a cloud solution that solves your problem at $199 a month, we ignore discount rates and cash flow, calculating NPV for a 5-year period, we'd end up with the feature being worth no more than $12k. So unless you can deliver it cheaper, you may not want to build it.

Service thinking

If you remember the beginning of the Internet age, AOL was a service born when companies realized that they had capacities available that others would pay for. Internet giants like Google and Amazon have since successfully replicated the model of selling a solution to their own problem to others as well. You already paid for it - so every cent you make with a sale is net profit! What is stopping you from capitalizing on the idea? If you're doing it right, there's even a chance you can make more money off selling the feature to others than the value it has within your own organization! More than one software company was borne out of scratching one's own itch.

Even if you're producing something "in-house", always ask the question, "Who else has this problem, and how much are they willing to pay to get it solved?" - if the answer boils down to, "Nobody" or "Nothing", then chances are that you're solving the wrong problem.