The Japanese word “kanban” means “visual board” or a “sign”, and it has been used in the sense of a definition of a production process since the 1950s.

I like it as an approach as it is simple to understand and implement, although ensuring you stay true to the methodology can be tough for some people. But what's it all about and what does this mean for a product manager?

What is Kanban?

Kanban is a production process that focuses on the definition and management of work through to completion. It allows you to visualize the work, maximize efficiency, and improve continuously.

In practice, it's most commonly associated with a "Kanban Board", which is a sequence of columns that represent:

1. Work to be done - The backlog of features that you want to build in the future
2. Work being done - The features that are currently being worked on by members of the team
3. Work that has been done - The features that have been completed and released

Example of a Kanban Board (copyright Kanbanize)

What does a Product Manager do in Kanban?

There's a short answer to this, and it's to write the user stories that appear in the 'work to be done' column.  

This effectively means all the tasks involved in getting to a point where a feature can be written up on a 'card' and placed into the to do column still need to be done by the product manager.

That includes speaking to customers, understanding the business, knowing your product, monitoring KPIs, and then distilling this information into feature stories that can be picked up and delivered by the team.

The task on top of this is to ensure that the 'work to be done' column (also called To Do, Requested, or Backlog) is prioritized, so that when the team finish one piece of work and come to pick up a new one then they can head to the top of the list and know that this is what has been prioritized as being next.

Basically, populate the list of things to do and put them in an order for the team to work through.

What are the benefits of Kanban?

The aim of Kanban is to limit "work in progress", with the view that if we're working on something we should focus on delivering that effectively before we move on to the next one.

With this in mind, it should also be a consideration for product managers who shouldn't be working on defining too many feature requests at any one time. This might require some personal management to ensure that you are focused on what you need to do, and not too much else.

To support this, in many organizations, the product team operate their own Kanban board that is separate to the team's Kanban board. This allows the product team to focus on their work to be done, which is to get to the point where you have a fully defined user story which can be picked up by the team.

In these instances, the columns on the Product Kanban Board would represent:

1. Work to be done - The feature requests or problems to solve that have come into the product team from whatever source.
2. Work being done - The features that you are currently working on defining i.e. you're discussing with the stakeholders to understand exactly what's needed and why
3. Work that has been done - The fully formed features that are ready to be transferred to the team's own Kanban Board as 'work to be done'

With Kanban, you miss out some of the ceremonies that are part of the scrum process, such as sprint reviews or planning, but there's nothing to stop you continuing to have the likes of daily stand-ups or retrospectives, as they perform a valuable purpose regardless of your production workflow.