I had a discussion with a colleague yesterday on how to determine the priority of features on a given service. We quickly arrived at the topic of assessing business need, i.e. value, of the features. This is a conversation I’ve had many times, with many clients and thought it might be worthwhile to document some of my thoughts on this.
If you are building “shrink-wrap” software you can estimate the number of units sold and multiply by the price to get annual revenue. From there you can work backwards to establish your financial metrics. (ROI, NPV, IRR, PV, EV, AC,T,I,OE, etc.) But what about when you are building Software as a Service? This is not a simple question to answer. Regardless of the level of difficulty, it is one that many of us will need to answer in order to effectively grow our organizations. While I don’t have a one size fits all answer here, I would like to toss out some tools, ideas and links that may help each of us answer the question for ourselves.
Know Your Value
For starters we should have a good understanding of the value proposition(VP) for the service. The VP will speak to why clients will choose your service over the competition. The VP will look something like:
“For sales teams seeking to reduce time-on-sale by as much as 25% our CRM application will provide full sales process management at half the price of the competition”
“Our internal CRM application will allow our sales team to reduce time- on-sale by 25% and cost only 50% of an off-the-shelf package”.
Here is some additional reading:
Understand the Features That Support Your Value
We add features to attract new clients, keep existing ones, or generate new sources of revenue. We should be doing this in alignment with our VP. We should not be adding features simply because we’ve conceived of the idea. Given that, we should start by asking ourselves “How important is this feature relative to our VP?” Let’s start by using the following 5-point scale for each feature:
- Direct VP feature.
- Component part of a VP feature.
- Compliments a VP feature.
- Nice to have.
When analyzing the features that support your VP, remember that only 6% of the work on software projects is value added and 64% of all software features are rarely used. (Thanks for the numbers Ryan!)
Price your Value
After you have the VP and the features to support it, you will need to work with your sales and marketing organization to understand what they feel the market will bear, in terms of price, for each unique service. They should also have an estimate on the number of users that will subscribe to the service. Jason Rothbart talks more about this here. Combine this with an innovative monetization model and you have some annual revenue numbers you can work with.
You may also be in a project that has the role of supporting the business. If this is the case, an estimate of the value to the business should still be generated. You may choose to adopt the model that if the service saves the organization 1 hour during a 40 hour week then 2.5% of the annual revenue is attributable to the project. For a $40M company this is $1M annually!!!
If there are no answers to these questions, you may be in the “build it and they will come” mode which is very difficult to generate value metrics from. Try using one of the above models to create an estimate and see how it compares to reality when everything is said and done.
Finally, you should consider what monetization models will be used by your service. Will you only generate revenue from paid subscriptions or will you adopt a freemium model? Will there be paid advertising from within the UI of your service? Are there client stakeholders that are willing to help fund the service? All these are examples of monetization models that will have an impact on revenue and need to be considered as part of the analysis.
Given the speed of today’s market, including the market lifetime in your analysis is also important. Every service has a limited lifetime due to advances in technology and usefulness to the client base. Typically the market lifetime curves are bell shaped (Figure 1) since full market adoption is not gained immediately and decays slowly due to technology and market pressures.
Figure 1 – Typical Revenue Cycle
How long will your service be able to generate revenue in its current state? 6 months, 1 year, 2 years? If you assume the lifetime to be 2 years and the revenue curve to be bell shaped with the max subscribers in the middle, you can make some fairly good estimates. The answer to this question will play an important part to developing the Value Schedule.
Bringing It All Together
Let’s assume that we’ve determined we will generate $1M over the next 2 years on our service. In order to generate this revenue, we will need to add continuous value and bear continuous cost over the next 20 months. Let’s further assume that we will be on 2 month release cycles over these 20 months giving us a total of 10 releases.
Using our 10 releases and our $1M in revenue we can simply calculate the value per release to be $100K. (Ignoring any discounting)
Now if we look at the first release and assume that we have 25 features all of which we have ranked using our 5-point scale from above we can estimate the dollar value per feature. The trick is to normalize the value based on the rank. The formula is shown in Equation 1.
Equation 1 – Feature Value Equation
Using Equation 1 in our example we can now generate a Value Schedule which will give us the dollar value of each feature.
While not the answer for everyone and realizing I’ve left out some detail, I hope the tools I’ve presented here will be useful to you while you are analyzing your next project. I would love to hear what you think!