Much of software development is wasted on projects that add little value. The process usually looks something like this:

1. There is a product engineering machine that needs to be fed.
2. Product managers prioritize projects against strategic goals of the company.
3. Engineering teams get the product specs, start building and launch the feature.
4. Good process hygiene is having a post-mortem, but it’s usually focused on the engineering execution not whether the feature was a good return on investment.

Rinse and repeat.

Engineering time is seen as a fixed quantity to utilize. To make matters worse, startup executives have an incentive to expand teams since growing a team is a key success metric for getting the next job.

‍

A different way

What if we view building software more like building a factory or buying a company. Those are major capital investments that receive intense scrutiny and require thorough financial analysis before proceeding. 

How many software teams can confidently answer if a project has an adequate ROI given the company’s cost of capital? What is the budgeted cost of building and maintaining a given feature? What incremental value will it create? Over what time frame? How did past projects perform in terms of actual costs and impact? Is the product engineering team actually good at allocating capital and resources?

Most teams will struggle to answer these questions.

What would a more rigorous approach look like? Applying a venture investing approach to software development could lead to better project selection and capital allocation. There are many similarities: you allocate capital into high-risk projects with hard-to-predict outcomes. There is uncertainty over the time and capital required. And most projects fail to have a meaningful impact on the future of the business. Just like many startups fail.

‍

Software development is like venture investing

In venture capital, calculating the Internal Rate of Return (IRR) is a common way to evaluate an investment. It tells you how fast your investment is growing each year given the money you put into the project. And it’s agnostic to the size and timeline of the project making it a good tool to compare projects of varying scope.

Let’s apply this to software development by taking a feature that is built by 10 developers over 6 months (plus product, design and overhead):

[link to model - feel free to copy and play with]

‍

Handling uncertainty

Just like venture investing, building a return analysis requires building a view of the future. The main assumptions will be:

1. Initial cost to build the feature or product: engineering estimates are notoriously difficult to get right. It requires experienced engineering leaders who know the code base and skill level of the engineering team well. And then can execute effectively to achieve the plan on time.
2. Financial impact: this should generally be measured in a margin improvement (since an increase in earned margin dollars are needed to pay back the development costs). Margin improvement could be driven by a revenue increase and/or cost reductions. Cost reductions are often easier to estimate since the existing cost structure is observable (“it takes us three people to do this manual process and we can reduce that to one”). A lift in revenue is often harder to estimate, especially if the new feature doesn’t even exist in the market and there is no analog. 

The point of this exercise is not to “get it right” (it rarely will be), but to focus the discussion and pre-work on the key assumptions that make or break the project’s IRR. What can we do to validate the key assumptions? Are those assumptions reasonable given our past experiences and data? Are there experts we can talk to get an outside opinion? If we’re wrong, what is the potential downside?

‍

‍Measuring success

Every software team should be held accountable to the outcome of its investments. They should look back at each major feature and see if it was successful and what went wrong. The financial return analysis should be revisited and an actual vs budget view presented. Did we deliver the feature on time and budget? Did revenue/margins increase as projected? If not, why? What could we have done better in the prework phase?

‍

Reward the winners

Not all projects will be successful. But just like venture investors, the teams that deliver success more often should be rewarded (get more resources, command larger budgets, bonuses, promotions etc). They are taking (expensive) resources and are turning it into shareholder value. That’s worth a lot. Share the upside.

‍

“But this is too much work!”

Benjamin Franklin’s take: "Give me six hours to chop down a tree and I will spend the first four sharpening the axe”.

Sure, this exercise is a lot and not worth doing for every little feature. The more time and resources you’re looking to spend, the more rigorous the process should be. Just like companies have different approval tiers for expenses, software projects should go through more rigorous analysis the more resources are used.

‍

‍The result of this approach should not be to stop taking risks. But to build the muscle for financial rigor and becoming exceptional at selecting projects that generate returns in excess of the company's cost of capital.

‍

------

Appendix:

Summary comparison between investment metrics:

ROI: Ideal for simple, short-term profitability assessments.

IRR: Best for comparing long-term investments or projects with varying cash flows.

NPV: Best metric for determining value creation, factoring in time value of money.

Payback Period: Useful for assessing risk and liquidity but less reliable for profitability or long-term value.

‍

‍