Product Development Balanced Scorecard

The biggest challenge for anyone responsible for software product development in an ISV is getting the right functionality developed at the right cost in the right timeframe.

In a later post I may blog on the blunt tools of “de-scope or de-lay” to manage releases, but for now I'll focus on the functionality side.

This is always a hot topic as there is never enough time to do everything and you can easily be pulled from pillar to post from almost every area of the business and externally (from marketing to presales, support to projects, customers to prospects).

It’s almost impossible to please everybody particularly with a single release, but here is one way to almost get there.... The Product Development Balanced Scorecard. I developed this specifically to address the area of product management and in an attempt to keep as many stakeholders happy as possible.

The concept is based on the Balanced Scorecard developed by Dr Robert Kaplan and Dr David Norton as a business performance measurement framework. The key is achieving balance across the 4 quadrants.

I have categorised functionality based on its key benefit to the business and also aligned to the stakeholders/end users. All functionality should fit into one of the quadrants below. Some functionality can sometimes fit into both. In this case you would allocate it to all those relevant.

Q1 - MARKET:
Functionality which is entirely new (rather than an enhancement) and/or targeted at a new market (could be geographical, vertical, horizontal or commercial) would come under this quadrant along with Market Trends/forces (e.g. Technology, Standards) etc. Such work would often come from market analysis, often be considered strategic and an investment in future revenue.

Q2 – PRESALES
Once you are in the Market, you still need to win the business. Developing some Unique Selling Points and “Sex ‘n Sizzle” in the product can make the difference between winning and losing. Often many suppliers can deliver similar functionality and so winning is about having something that stands out from the crowd. Working closely with presales will inform you of what is needed in this quadrant. This is not to be confused with core functionality (e.g. what is expected) but about demo’ing and delivering something eXtra.

Q3 – SUPPORT
All software products need to be Implemented, Deployed and Supported. How much effort required in each of these phases is as much to do with the product design as product functionality. By careful design (and if necessary redesign and further development) you can reduce the time to implement a solution (improve revenue recognition) as well as significantly reducing support effort either by designing out potential for issues and/or fully building in diagnostic capability. The net result will be happier customers, reduced support costs, improved revenue delivery and profit.

Q4 - CUSTOMER BASE
Everybody agrees that your customer base is your life blood and treated well do all the presales and marketing you need. You need to keep them happy to retain them and reference them. Every customer will have some niggle or wish list, however minor, that if developed in (or in some cases out) via an enhancement will turn them into a raving fan. Make sure you listen to your customer base and identify these gems. As well as turning the customer into a fan and a reference you will also be able to recognise upgrade revenue as they move to that release and ensure your customers are on the latest codebase. In many cases customers won’t upgrade for any other reason (including Q1 and Technology refresh!).





Ok, so these are your quadrants. Now you need to balance them. Every Development Plan should categorise each feature against the Scorecard. You can then add up (in both cost/effort and number) the items in each quadrant to ensure it is balanced.

It is important to look, not just at the number of days, but also the number of items. For instance if you have developed 150 days of functionality for the customer base, but this represents only 1 distinct item of functionality you may have problems getting your customer base to upgrade unless you can be very sure that they all will really benefit from it (which is rare in my experience). So in the example above (and graphically below), whilst the cost is largely balanced, the number of items is out of balance.

As with all statistics, analysis and scorecards, they are a guide and there are exceptions to the rule. However, if used properly this scorecard can help keep all your stakeholders happy. Indeed it can often be used to show the stakeholders how you plan or have given them a fair slice of the development budget.

Nick