Product development metrics
Product development metrics give companies insight into how efficiently they build products. Product metrics typically fall into two categories: Strategic, which measure the output of the organization as a whole over a long time period, and tactical, which measure teams, individuals, systems, and projects over a short time period. Both are essential for product measurement.
Why are product development metrics important?
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:
- Strategic or tactical: Strategic metrics measure the overall production on a long timeline, such as the number of patents filed over several years. Tactical metrics gauge shorter term productivity or individual output, such as the number of software bugs per release or lines of code per developer.
- Input or output: Input metrics measure the resources that are fed into product development organization such as additional headcount and research and development (R&D) budget. Output metrics measure what’s produced, such as the number of products released
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:
- Limit the number of metrics
- Keep the metrics simple
- Avoid metrics that would be impractical to collect
- Prioritize metrics that have a direct revenue impact
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.
10 product development metrics
Strategic product development metrics:
1. Research and development (R&D) as a percentage of sales
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
2. Total R&D / product headcount
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
3. New product sales
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
4. New patent generation
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.
- Total # of patents filed
- Total # of patents pending
- Total # of patents awarded
- Total # of patents rejected
5. New products released
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.
- Total # of new products in consideration, estimation, or planning stages
- Total # of new products in active development
- Total # of new products released per year
6. Average product ROI
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
Tactical metrics
7. Story points retired
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.
- # of story points retired in a given sprint
- # of story points retired per team member
8. Team velocity points
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
9. Sprint burndown
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.
10. Errors per 1,000 lines of code (KSLOC)
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
Good product development never ends
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.