Why the ‘Reusable Checklist’ doesn’t work

It was one of those lunch conversations about what should be improved in the world of business, which ultimately lead to the topic of how companies manage their processes. My lunch buddy spent some time looking into this a couple of years ago — apparently not much has changed since. Why?

Process = set of tasks to be completed in a particular order

What became evident to him back then, was that there are two types of processes depending on how they’re being managed by a company.

Type A) Business processes that are being managed in enterprise software.

Type B) Processes that are being maintained in an Excel spreadsheet or Word document.

As our conversation went on, we both believed that there must be a better way of managing these Type B processes.

Our observations in the past revealed that teams are wasting too much time with repeatable processes — in particular, the administration aspect of it. Additionally, we saw that larger companies are struggling to maintain standards and keep the quality high for processes that are being executed time and time again — potentially in various locations & often including more than one person.

Based on these observations and additional interviews, we assumed that especially team members in mid-sized and large companies who do not have full responsibility for a process but participate in it would have a stark interest in being more efficient.

Naturally we thought of checklists

While an Excel spreadsheet or a task management application might be sufficient for processes that require only one person to complete a set of steps in a particular order, it bears some difficulties when multiple people are involved or when various instances of the same process run in parallel.
In that case, it can be tough to keep the overview of ongoing processes or to make sure that the person responsible for the next step is taking care of it in due time.

There must be a better way of managing processes with shared responsibilities that run several instances in parallel.

As Atul Gawande described — in his book ‘The Checklist Manifesto’ (2009) — how checklists can be used for greater efficiency and consistency in professional life, we intended to use the checklist as a format as well.

Of course, we’re not the first ones to think about this; Ev Williams stated his wish for a reusable checklist application back in 2012.

With a bit of research, we found about a handful of checklist applications that allowed for creating templates and running several instances in parallel. We went on and tested each one of them. Somehow they all felt heavy and hard to wrap your head around. We didn’t come across a user experience that was satisfying.


It’s not easy to describe what didn’t feel right about the existing applications, so we decided to try some mockups ourselves to get a better understanding.

We showed the initial designs to some of our friends to find out whether they would understand the difference between a template and an instance thereof.

They did not, the mockups were terrible.

Eventually, after a couple of iterations, the mockups were good enough for people to understand the difference between a template and an instance. Here is what they look like:

Creating a checklist template

Available checklist templates that can be assigned to someone

Team overview of active processes

Working through a process

We used InVision to create a clickable version of these mockups and shared it with some more people.


Encouragingly it was easy for them to think of a process for which it would make sense to use such an application. The examples provided by the testers confirmed the assumption that this would be a team application. Assigning responsibilities and due dates for individual steps were wished for specifically.

A fair share of testers wished for a dashboard that shows all ongoing processes as well as individual steps across all processes that required their action. Additionally, people that worked in large companies had a stark interest in having an audit trail of all processes.

Interestingly some testers intended to use the feedback feature to not only improve existing processes but also to work out processes that are still in development.

So it was time to take it a step further.

Building an MVP

We decided to gain additional insights from one specific process which is being managed by multiple people. To do so, we took a look at the position change process of an HR team from a global commodity company. The initial interviews gave us a good understanding of how they run the process.

The main part of the process is being managed in an HR SaaS application. However, the team uses an additional checklist to make sure that nothing gets forgotten — basically, copying & pasting information from the SasS application into emails and shared google docs. Then these emails are sent to the person responsible for the next step of the process, which makes it inconvenient for the team leader to keep track on where each process stands, and for a labor intensive process to manage.

Still in MVP mode, we decided to set up a shared spreadsheet which included the process checklist and the information necessary for every contributor to complete the assigned steps. Then we added a script that automatically triggered an email to the person responsible for the next step once the former was marked as done. The shared spreadsheet allowed everyone to have a proper overview on all instances of this process.

Strong signal

The outcome of our MVP test wasn’t as encouraging as we’ve expected after the mockup testing. The adoption rate of this shared spreadsheet within the HR team was low — very low.

Apparently the pain of handling such a process through multiple shared docs and email was not meaningful enough. Therefore, we concluded that there’s no significant need in the market for such a checklist application.

Did we jump to this conclusion too fast?

Well, one could think so. However, we didn’t find another process within our personal networks to test the MVP again. So we took a step back to understand what all this meant. After some further discussions and interviews, we realized that there are indeed two types of processes:

Type A) Processes that become part of a domain-specific software solution (e.g. a vertical like an HR SaaS application).

Type B) Processes that are not complex enough to become part of a vertical and are, therefore, being managed through spreadsheets and the like.

However, the hassle of managing these Type B processes in current ways through email and shared spreadsheets is simply not big enough for people to seek an alternative.

In the end, this leaves no room for a generic checklist application. Now we do know why not much has changed since my lunch buddy looked into this, years ago.

Nevertheless, we’re looking forward to our next lunch conversation.

Do you have some additional insights? Did we miss something? Did we do something wrong? Let’s talk.

Like what you read? Give headbits a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.