Many engineers used the Taylorism factory management system to achieve better operational results within their jobs. This allowed them to understand the bottlenecks of their production lines, identify efficiency opportunities, and operational waste reduction.

What is the Taylorism factory management system?

To those who are not familiar with it, Taylorism is one of the earliest attempts to apply science in engineering and manufacturing processes, developed by Frederick Taylor (this book is a great source if you want to know more).

While we do not function as a manufacturing industry or factory in the digital world, several lessons and principles from that management system can improve product management and software development operations.

Although I am no expert in Taylorism there are a few exciting methods and frameworks I discovered while studying this management system. One of those is “Overall Equipment Effectiveness” (you can learn more about that here), which is basically a way to overview how we spend our time by analyzing what adds value to the company's end goal and what does not.

Generally, this is applied to machines and equipment but was also used in roles like engineers, doctors, and other functions.

So how does Overall Equipment Effectiveness work?

To illustrate this, let's analyze a doctor's overall effectiveness. A doctor brings financial value to the organization by attending to patients in a hospital. We could deep dive into a calculation to understand how many patients go per time with a single doctor, but in this case, we're only looking at how much effective time a doctor has to work with the patients.

  • A doctor gets paid for 1920 hours per year (assuming the doctor works 40 hours a week). This is 100% of their time.
  • We know, however, that any human being needs a vacation (176 hours) and sometimes has sick leave (let's consider that to be 5 days, so 40 hours), reducing the time available to 1704. We already have a reduction to 89% of the total time.
  • This would be considered the doctor's total practice, but not all of his time has booked patients, so we reduce time again. Let's assume 10% of the time, bringing it to 1512 available hours and 79% capacity.
  • We also have to consider canceled bookings, which removes more considerable time from the doctor's work time - subtract another 10%, leaving us with 1320 hours, at 69%.
  • That leaves us with time with patients, but not all patients need a doctor - about 15%, and we go down to 1032 hours, with 53%.
  • In most cases, doctors also have to perform non-patient work. It could occupy anything from 20% to 40% of their time. Let's be optimistic and consider a reduction of 20%, bringing us to 648 hours at 33% efficiency.

Operationally, this gives us broad insights into where we could possibly start looking at more detail. Say, for example, we want to work on cancellations and reduce them through incentives or cancellation policies to discourage them.

UK’s National Health System (NHS), as an example, sends the patients a text message reminding them of the appointment date and "If you do not attend this appointment it will cost the NHS £132", as a way to mitigate cancellations (thanks Chris Compston for the example).

We could also start looking at work unrelated to the patients and see what could be delegated to other people or even automated. Through some further study of flow (maybe a next article here), we can find bottlenecks in the processes or interactions between areas and find improvement opportunities.

What does Taylorism have to do with product management?

Like medicine, product management can also be analyzed through the lens of Overall Equipment Effectiveness - how much work time actually adds value to the customer? What are the time stealers?

I did the same exercise but with a product management focus (numbers have been estimated, so don’t take them by the heart!), to understand how this tool can be applied by product ops. With the actual data in hand, we’re able to have a comparable view of the time cost of the activities and start making more informed decisions on what to work on next. As an example, there’s a great opportunity to increase efficiency by reducing the number of meetings or even by automating some of the admin tasks.

We can even add an extra layer here and start working with some very basic financials. We can see in the previous example, out of €50.000,00 annual salary, 60% of it goes to meetings and administrative work - which can work as an interesting OKR for your next project.

But how to get this data?

The biggest challenge of this is to be able to quantify how much time each activity generates value to the business and end customer. It can be hard to reach a consensus about what truly adds value since the perception varies from person to person.

A possible way to obtain this data is by establishing a defined time frame to "shadow" a product manager and run through a series of questions to determine whether the activity adds value or not. User experience research has excellent methods to observe and map this data, like conducting a contextual inquiry. It's also essential to reflect your data back to the team and understand how they interpret it.

Although the tool is quite useful, it does not come without challenges: people might not be comfortable with being “measured” and it can be quite hard to determine what is actually useful or not, due to the fact we’re capitalizing on intellectual work (factories have an easier time, since it’s linked to the production of a physical and tangible product).

For these reasons, it’s crucial to be transparent about your intent with this data right from the start, be sure to protect the people being observed by making them anonymous and keeping them in the loop while unfolding this data. Most of the time, these inefficiencies arise from values and product culture within the team.

Conclusion

As a product operations team, we're always looking at how we can get more out of our work for the investment we make - with so much going on in product development, it’s often quite hard to decide what to work on. Overall Equipment Effectiveness is an interesting early output that you can use to capture improvement opportunities within product development workflows - you can even use it to establish a baseline and compare to next iterations results, even financially.

This also helps us ask better questions regarding the work. If we have a lot of time lost due to rework or scope change, does it mean we have to start looking elsewhere? If I’m having an output problem, is the case to increase the time or to start investing in other fronts, like asynchronous communication? 100% capacity to do only work that’s valuable to the end-user is impossible, but we should always be asking questions to get close to it and avoid “working to work”.

Remember the objective of this is not to look at product managers and say “be more efficient, do this and not that”. But rather to use it as a mirror to reflect back to people doing the work, understand what actually adds value and what can be reduced, to give more time for product managers to think strategically. It’s about enabling product managers to perform better. If they are already doing great work with €10.000,00 per year (assumed), imagine what they could do with fewer meetings?

Bonus: you can use this template to have an easier time setting this up!

If you’re looking for more insight and inspiration - check out our hub for all things Product Operations, designed to be the go-to place to get your learnings on the function.