The project investment decision should be based on the future forecasting.
What happened in the past is just sunk cost.
People frequently make mistake by using the "current" state to determine the future investment.
The "current" is only useful if it can be used to predict "future" in the investment decision.
A product like XX, which is the core product in Suite WW and is in almost all installations and the product XX is a very mature product.
Does that mean that we need to allocate more on it?
It is only meaningful if we assume that the more customers are using it, the more engineers need to be allocated to maintain it. Unfortunately it is typically not the case.
Should the size of the team match the revenue that the product is bringing? It sounds reasonable. The cost and revenue typically do not match in the same year. If you use operational leverage, the break even point can be multiple years. You won't do any big, potentially high return projects if you only look at the current revenues. You will never do new projects.
The revenue itself is not always a good measurement since the nature of the number is "short term". A better financial goal is to maximizing the shareholder value. We should look at the long term ROI. The discount cash flow can support the goal much better.
The discount cash flow concept sounds simple but seems frequently overlooked.
For each project or proposal, what we can do is that for each bucket, we can calculate the following:
how much revenue potential and thus the cash in flow it will bring in,
plus the cost saving the project can bring to us,
minus the initial cost to create it,
minus the cost to sustain it.
All of them need to present as the current value then we compare these initiatives.
One difficulty for making investment decision for software products is about the existing commitments, such as those over commitments done by sales. On the other hand, there are also implicit commitments. When a customer bought a product in the past, they are not just buying the product feature that available at that time. They also buy products from enterprise apps vendor to assume that the vendor will take care of their future needs. They believe that the product has a future.
What happened in the past is just sunk cost.
People frequently make mistake by using the "current" state to determine the future investment.
The "current" is only useful if it can be used to predict "future" in the investment decision.
A product like XX, which is the core product in Suite WW and is in almost all installations and the product XX is a very mature product.
Does that mean that we need to allocate more on it?
It is only meaningful if we assume that the more customers are using it, the more engineers need to be allocated to maintain it. Unfortunately it is typically not the case.
Should the size of the team match the revenue that the product is bringing? It sounds reasonable. The cost and revenue typically do not match in the same year. If you use operational leverage, the break even point can be multiple years. You won't do any big, potentially high return projects if you only look at the current revenues. You will never do new projects.
The revenue itself is not always a good measurement since the nature of the number is "short term". A better financial goal is to maximizing the shareholder value. We should look at the long term ROI. The discount cash flow can support the goal much better.
The discount cash flow concept sounds simple but seems frequently overlooked.
For each project or proposal, what we can do is that for each bucket, we can calculate the following:
how much revenue potential and thus the cash in flow it will bring in,
plus the cost saving the project can bring to us,
minus the initial cost to create it,
minus the cost to sustain it.
All of them need to present as the current value then we compare these initiatives.
One difficulty for making investment decision for software products is about the existing commitments, such as those over commitments done by sales. On the other hand, there are also implicit commitments. When a customer bought a product in the past, they are not just buying the product feature that available at that time. They also buy products from enterprise apps vendor to assume that the vendor will take care of their future needs. They believe that the product has a future.
No comments:
Post a Comment