Product Development Process and Application of Little’s Law

A queueing system is a model with the following structure: customers arrive and join a queue to wait for service given by n servers. After receiving service, the customer exits the system. A fundamental result of queueing theory is little’s law. This article shows how the Product Development Process and Little’s Law are best friends, if you let them. You can also view all 40+ articles on Queueing Theory.

Theorem: for a queueing system in steady state, the average length of the queue is equivalent to the average arrival rate multiplied by the average waiting time. in other words,

L = λW

Little’s Law is a fundamental principle in business, mathematics, and has applications to many real-world problems. One of those real-world problems is in product development.

First, a definition:

• WIP/TIP: Work-in-process of Things-in-process. For the purposes of this article, they are synonymous. Being “in-process” means the work or things have entered a state-of-affairs but have not yet exited. The “work” can be anything: materials, components, sales orders, software code, software testing, projects, customer inquiries, checks, phone calls to return reports suppliers to qualify, repair orders, or emails waiting to be answered, etc.

For product development, we can use a transformation of Little’s Law, like the following:

[(Throughput) = (Things-in-Process) / (Average Completion Rate)]

What this equation tells us and what experience has shown time-after-time, is that the number one driver of Product Development Cycle Time are the “things-in-process”. There is no quicker way to reduce the cycle time by which your company can get a product from concept-to-delivery than through first prioritizing all the projects or products and focusing on the ones that make strategic and tactical sense, and killing the lower priority projects.

You might be thinking: “True, but couldn’t we also increase the average completion rate”? You’re right, but the impact of doing that is much lower than reducing the TIP — that is, influencing the average completion rate is rather difficult and is often a function of available resources, scope creep, market demands and changes, etc. Here’s the bottom line: the number one driver for shipping products quicker is by focusing on the important ones and killing the unimportant ones.

Product (Project) Selection Prioritization Matrix

One easy but effective way or prioritizing a list of projects or products is to group-rank them based on variables. Below is an example of a prioritization matrix that I’ve used in the past:

Here are some general steps:

1. List all the projects/products
2. As a group of core stakeholders and decision-makers, agree on a selection criteria, or list of variables on which to judge each item on the list.
3. As a group, score each item against each variable. Use a likert scale that makes sense.
4. Multiply the various scores across to get an overall score.
5. Rank the projects and sort from highest overall score to the lowest. Then, review to see if the ranking makes sense.
6. If done right, then the important initiatives rise to the top and the unimportant ones fall to the bottom.
7. Decide as a group, based on available resources and strategy, where the cut-off score will be. Cut, then discard the items below that score and focus on the ones above that score. I don’t suggest you table or postpone items below the cut-off, because realistically they will be discarded.

Conclusion

To drive throughput, you can influence the size of WIP/TIP or increase the average completion rate. A balanced approach is good, but you’ll gain a higher yield by focusing on reducing WIP/TIP. In order to do that, you must decide as an organization what to focus on — on items that will bring the biggest return to your customer, shareholders, and the company.