Product development metrics

Product development metrics, also known as product key performance indicators (KPIs), give companies greater control over the quality of the products they produce as well as the rate at which they produce them. Both factors are indicative of a company’s ability to compete in the market as well as its long-term financial success. For product teams, having access to product metrics is akin to watching a car’s speedometer: It tells them when to speed up, slow down, and resource as needed. There are two ways to categorize product development metrics:

Selecting the right product development metrics is essential. Companies have access to a vast array of digital information and the more judicious they are about limiting their focus to the few product KPIs that matter, the more control they have to achieve the right outcomes. Like a vehicle with too many controls on its dashboard, teams with too many metrics sometimes have trouble remembering which button does what. If those metrics aren’t tied to an outcome that matters, such as generating revenue, they might only serve as an unhelpful distraction. Here are a few criteria for selecting metrics:

With simple, focused, and deterministic metrics that directly influence revenue, product teams can better prioritize their time and make feature changes that improve the financial health of the business.

R&D as a percentage of sales reveals how much of a company’s income is reinvested into building new products or improving existing ones. Public companies are required to report R&D in their public filings, but it’s an important metric for product teams of all sizes to know. As a general rule, the more a company invests into product development, the more likely it is to build better products, earn customers’ loyalty, and out-innovate the competition. There is no widely accepted benchmark for R&D as a percentage of sales the way there is for. For some companies, 2-3 percent is a healthy level, while for others, 20-30 percent is low. If R&D as a percentage of sales declines or dips below than that of competitors, it may be cause for concern. Google, for example, famously outspent Yahoo! On R&D as a percentage of revenue and knocked the latter out of the internet search market. $ R&D spend / $ gross company sales

Headcount is the total number of employees engaged in the research and development of new products. Total R&D headcount is most useful when measured over time. An increase can be indicative of increased future product output while a decline can imply an imminent slowdown or trouble hitting deadlines. Total # of R&D or product team employees

New product sales is the gross revenue a company generates from recently released products. Also referred to as a vitality index, this metric is an answer to the question, “Is our R&D contributing to the growth of the business?” A company that had relatively low new product sales has reason to believe that it’s being supported by its older, more established portfolio of products, and that newer services aren’t adding as great a proportion of value. Most companies choose to define “new” as any product released within within the prior 3-4 years. If new product sales drops, it’s a potential indicator that the product development organization’s contributions are declining.   $ new product sales within the past X years

For larger organizations, it may be useful to track how many patents the company is producing. This is a proxy metric for potential new revenue streams and competitive advantages. Many companies treat patents similar to a sales pipeline — they strive to keep it topped off.

Similar to patent generation, large companies measure their pipeline of new products as those products are considered, enter active development, and are released. A decline in the number of new products being considered or developed signals a future slowdown in the number of product released.

Also known as average product payback, this KPI measures how much money each new product generates for the business as a function of how much it cost to develop. Profit margins vary wildly between businesses, but higher is typically better. ($ sales from a particular product within the past X years / $ cost to develop the product) / $ cost to develop the product

Teams that track the units of work they complete can treat that number as a performance metric. If they subscribe to the SCRUM theory of product development, they may refer to these as story points. It’s important not to confuse story points with task hours. Different teammates with different skill levels retire story points differently. A junior software engineer might need five hours to complete something that takes a senior developer thirty minutes to finish. Story points are simply an approximation of task difficulty. The number of story points retired is a proxy for how much work a team typically completes within a given period. For instance, a B2B software platform completing ten story points within one two-week work sprint to add a new service to their technology stack. If that team completes more story points this month than they did the month prior, it suggests they became more efficient.

Teams that track story points can measure how many points a team can retire within a work sprint. The team can then use this to estimate how long future projects will take to complete. If a project is worth 30 story points, and the team typically retires 10 story points in a 2-week sprint, they know it will take approximately three sprints, or six weeks, to complete. Average # of story points a team has retired per sprint

A sprint burndown is a calculation of the total amount of work that remains before a project deadline, whether measured in man-hours, story points, or some other unit of effort. Teams using SCRUM can create a graph that shows the story points remaining compared to the number of points they’ll need to have retired at that point in the sprint to be on track to complete the project on schedule.

Teams can measure the number of errors the product team commits per 1,000 lines of code as a benchmark to determine what they consider an acceptable rate of error, and whether the KSLOC rate for a recent code release was too high. When the KSLOC increases over time, it’s an indication that the product quality is decreasing. Alternately, a team could choose to measure the number of bugs per sprint, or the number of bugs per thousand lines of code.

# of errors / 1,000 lines of code committed

For many digital products, the product development process never ends. Teams are constantly improving and iterating on new version of the interface to make it even more useful to customers. Once the team releases the product to beta testers or real users, the development enters a new phase. The team gets their first real user feedback and can add a new tranche of product KPIs: user engagement metrics. These measurements, which include user growth, average revenue per user (ARPU), and lifetime value (LTV), offer product teams an even more complete view of their users and give them even more tools to build a successful product.