Before I studied Finance, I had always wondered how an investor or CEO managed companies at such a "Macro" level. Financially, how could you determine if HP or Dell were better companies? Chevron or BP?

One critical aspect is to understand the use of Financial ratios. There are a core set of ratios which help to govern an organization's performance, then lots of expanded ratios which have developed over time. A decent introduction to the core sets of ratios can be found here.

For product teams inside of software companies, one ratio I find to be critical is Revenue:R&D spend. This is where I start annual budgeting exercises and where I establish context for how an R&D group is doing relative to its peers.

Start by examining Revenue:R&D for your peers. You may come up with ratios as high as 6 or as low as 1 depending on industry and stage of development. For example, if you work in a large, established software company then you would expect the ratio to be high, as this indicates the company is able to write software and convert it to revenue efficiently. If you are working in a growth company, the ratio might be quite low, indicating the company is investing heavily for future returns. In the case of a growth company, the lower Revenue:R&D ratio is likely to be offset by a high valuation. The higher valuation demonstrates expectations of returns on the heavy R&D spend.

Sometimes the ratio can be deceiving. For example, in my old company EMC, we made both hardware and software. Vastly different Revenue:R&D Spend for software versus hardware, and this had to be taken in to account when doing an analysis. Some important points:

If you are looking for a place to start insofar as competitive analysis, pick a company like yours and compile a list of competitors. Here is an example.

So let's talk about software product teams and how important this ratio is.

in every SDLC there are a core set of functions which need to be accounted for. In most cases this would comprise your R&D spend. If we take out licensing deals, consulting, expenses and the rest and focus on staffing for right now, I think of the following roles:

Now, two questions always come to mind for me:

It is useful to explore both lines of thought . The Revenue:R&D ratio I mentioned earlier can help you determine how much budget you should actually have for R&D. Let's assume you have a revenue target of $31 million and an R&D ratio of roughly 2.4. This would mean you should spend $12.9 million on R&D. At the very highest levels (i.e. SWAG) you can use Pareto (80/20 rule) to assume 20% of that budget will be for expenses and 80% will be for staffing. So this leaves you with roughly $10.3 million for payroll expenses.

So how do you know what you should spend on Payroll and in which categories? One approach I've used successfully is to consider the ratio of supporting functions to Engineering. The math can be illustrated in this way:

Now, you can't just apply these ratios to your budget. You have to normalize them against hiring 100 engineers:

So this would break up my $10.3 million spend for staffing if I used the above ratios:

This is where it begins to get very interesting and where we talk about question 2 above: how much budget do you need? Say you needed 150% of this amount to accomplish the goals on the roadmap for the next year. In some cases you can ask for more money, but in other cases you have to innovate. For example, maybe you need to move items off shore? Maybe you have to license software versus building software? Utilize more open source?

What you need is entirely relative to how good you are at writing software, how smart you are at using what is already in the market and controlling scope. If you base your company in San Francisco and hire all local staff, you will require more funding than if you base your company in Nashville and utilize geographic arbitrage with an equally skilled, but lower cost set of resources in Eastern Europe.

The topic of innovating and doing more with less is quite broad. Look for a post on Geographic Arbitrage soon.