If you’d know me personally, you’d know that I love a good list. Making lists helps me to outline my thoughts, see connections and help prioritise. Three years ago, I wrote about “The Checklist Manifesto” by Atuwal Gawande, which is a great book about the importance of checklists and the ingredients of good checklist (see Fig. 1 below).

Fig. 1 – Key learnings from “The Checklist Manifesto” – Taken from: https://marcabraham.com/2015/07/01/book-review-the-checklist-manifesto/:

1. Why checklists? – As individuals, the volume and complexity of the know-how that we carry around in our heads or (personal) systems is increasingly becoming unmanageable. Gawande points out that it’s becoming very hard for individuals to deliver the benefits of their know-how correctly. We therefore need a strategy for overcoming (human) failure. One the one hand this strategy needs to build on people’s experience and take advantage of their knowledge. On the other hand, however, this strategy needs to take into account human inadequacies. Checklists act as a very useful as part of this strategy.
2. What makes a good checklist? – Gawande stresses that the checklist can’t be lengthy. A rule of thumb that some people use is to have between 5 to 9 items on a checklist in order to keep things manageable. The book contain some good real-life examples of how people go about starting their checklists. For example, looking at lessons learned from previous projects or the errors known to occur at any point.
3. How to use a checklist – I believe that the key thing to bear in mind when using checklists is that they aren’t supposed to tell you what to do. As the book explains, a checklist isn’t a magic formula. Instead, having a checklist helps you at every step of the way, making sure you’ve got all the crucial info or data required at each step. Also, a checklist is a critical communication tool, as it outlines who you need to talk to (and why, what about) at each step of the way. Gawande also highlights the value of the ‘discipline’ that comes with having a checklist, the routine that’s involved in having a checklist. I’d add to this that a checklist can be a great way of identifying and mitigating risk upfront.

I’ve since read Leander Kahney’s biography of Jonny Ive, Apple’s design honcho. The book contains a quote about Apple’s New Product Process (‘ANPP’):

“In the world according to Steve Jobs, the ANPP would rapidly evolve into a well-defined process for bringing new products to market by laying out in extreme detail every stage of product development.

Embodied in a program that runs on the company’s internal network, the ANPP resembled a giant checklist. It detailed exactly what everyone was to do at every stage for every product, with instructions for every department ranging from hardware to software, and on to operations, finance, marketing, even the support teams that troubleshoot and repair the product after it goes to market.”

I perked up when I read how the ANPP resembles “a giant checklist”, detailing what needs to happen at each stage of the product development process. Apple’s process entails all stages, from concept to market launch. The ANPP is understandably very secretive, but I believe that we don’t need to know the ins and outs of Apple’s product development process to look at the use of checklists when developing and managing products:

Checklists aren’t the same as Gantt Charts! – It’s easy to confuse a short checklist with a Gantt Chart. Over the years, I’ve observed how people can derive a lot of certainty from creating and viewing detailed Gantt Charts or roadmaps (see my previous thoughts on this topic here). In my view, a super detailed checklist defeats the object. Instead, I encourage you to have short checklists that highlight both basic and critical steps to go through when developing / launching / managing products.

Checklists are evolving – Checklists are evolving in a sense that they’re likely to be different per product / team / project / etc. I find, for example, that each time I work with a new team of people or on new product, the checklist reflects the specific steps that need be checked, tailored to the team’s way of working or the specific product at hand.

Checklists are a collective effort – I’m currently onboarding a new UX designer into my team, and he’s keen for us to look at the ‘design checklist’ together, as he’s got some suggestions on how to make it work better. This might mean that the existing design checklist (see Fig. 2 below), underpinned by my preferred dual track approach, might be binned or adapted accordingly. Both are fine, as I expects checklists to be formed by those people who are responsible for checking the different list items. I’ve seen people treat their individually developed checklists as a decree … which others had to following blindly. My simple reaction to that kind of approach: no, no, no, no.

Fig. 2 – Sample ”design checklist”:

Democratise the sign-off process (1) – Often, quality assurance people come up and drive the best checklists. However, the risk I’ve observed, is that these QAs or the product managers become the single sign-off point for the checklist in question. I go into companies and look at their SCRUM and Kanban boards which have cards stating “Pet sign-off” or “Jackie sign-off”. I recently spoke to product managers at a company where the CEO wanted to sign off each feature.

Democratise the sign-off process (2) -Whilst nothing seems wrong with this approach at the face of it, there are two reasons why I feel uncomfortable with this ‘single sign-off’ approach. Firstly, to me, a hallmark of a truly self-organising and empowered team is that everyone feels empowered to ‘sign off’ on the end result (and its individual components). Secondly, I’m also worried about what happens if the designated sign-off person isn’t available. What happens if Pete and Christina are off ill or in never ending meetings? What if the CEO isn’t available for sign-off? Does the feature or product not get released to market? In short, I’m worried about creating another bottleneck or ‘single point of failure’ or forfeiting speed to market.

Don’t forget the basic steps – How often have you’ve been in a situation where you’ve just launched a new product or feature and realised that you forgot to test the styling of the images, content and calls to action? Sense checking things like these sounds like a basic step, but it’s one that’s easily forgotten in the excitement (and haste) to launch. Having basic steps like ‘check content’ included in your ‘pre-launch checklist’ will make sure that things don’t get overlooked (see Fig. 3 below).

Fig. 3 – Sample ”hygiene checklist”:

Include critical steps, lessons learned – I’ve found checklist to be a good way to incorporate key lessons learned on a continuous basis. The risks with post-mortem sessions or retrospectives is that lessons learned don’t get action and tend to be forgotten. Including a learning into a checklist is a simple but effective of way of ensuring that a learning sticks. For example, “training the customer support team” (on a new product, user flow or feature) was a critical step that I used to forget consistently. By including this item in a ‘go-to-market checklist’ helped me and my team in making sure this step wouldn’t be forgotten about anymore.

Put your checklist on a wall – Finally, I’d recommend making your checklist as visible and shareable as possible. You can stick your checklist on an office wall or, if the team aren’t all working in the same space, in collaboration software products like Confluence and Trello (see Fig. 4 – 5 below).

Fig. 4 – Put your checklist on a wall – Taken from: https://www.superestudio.co.uk/wall-checklist

Fig. 5 – Add your checklist in Trello – Taken from: https://www.addictivetips.com/internet-tips/trello-an-online-pinboard-for-task-organization-collaboration/

Main learning point: As long as you don’t confuse them with highly detailed project plans or roadmaps, checklists can be a valuable tool in making sure you and your team don’t overlook key steps when developing products!

Related links for further learning:

1. https://www.interaction-design.org/literature/article/apple-s-product-development-process-inside-the-world-s-greatest-design-organization
2. https://qz.com/183861/any-company-can-copy-the-keystone-of-apples-design-process/
3. http://www.theequitykicker.com/2014/03/06/apples-new-product-process-long-checklist/
4. https://www.quora.com/What-is-Apple-s-product-development-process
5. https://blog.toggl.com/gantt-chart/
6. http://datainsightsideas.com/post/18502350035
7. https://en.wikipedia.org/wiki/Single_point_of_failure