Product Team Failing With Kanban? You Are Not the Only Ones

What do all highly productive people have in common? We love a good list. I typically keep a notebook (physical or digital) open throughout the day, jotting down to-dos that pop up in conversations and meetings. And while I think every list maker can agree that crossing off the last open item is a wonderful feeling, there is always more to get done than time allows.

You need the right tools and processes to get meaningful work done. You also need to understand why you are doing it in order to prioritize what is most important.

Several years ago I wrote a blog post about how it seemed like every product team was implementing kanban. Back then I thought intentions were good, even if the results were mixed. (Which is usually true in any type of transformation — in this case, to ship better software more often.)

Teams often look for a methodology that they can layer on top of what they already do. And I think that is one of the reasons that kanban was such a popular way to embark on a so-called agile transformation. With no fancy roles to learn or certifications to obtain, most people can grasp the basic concept behind it and you can apply it to projects in motion.

Work items in kanban are represented as cards that the team continuously picks off and completes. Rinse, repeat — ad infinitum. The promise is that you can avoid multitasking and overloading the team by adhering to work-in-process (WiP) limits. Those limits give you an assurance that the team will have just enough work for the time allowed. Maximum efficiency as you check each item off the list at a time. But how do you decide what goes on that list and whether it will bring the most value to customers?

Kanban is a fine way to manage work but it cannot answer what that work should actually be.

Our understanding of and expectations for product development have evolved. We are finally seeing product development for what it is: the future of any business. It consumes significant resources, drives the most future value, and needs the most attention. Today many industry-leading companies are making deep investments in an end-to-end approach to product development — with a focus on rapid innovation, defined value metrics, formal product teams, purpose-built tools, and integrated workflows that operate at scale.

So yes, I still believe that a kanban board alone is ineffectual for a mature product development process. Let me share a few more of the cons that I see:

Disconnected from strategy

Product development is highly strategic. In order to deliver the most value, you need to clearly see how specific features support business and product goals. Typically there is a chasm between the high-level roadmap and the detailed user stories that stack up on the kanban board. Tracking how you are progressing against those goals impacts the product, your customers, and team motivation.

Missing the long-range view

Kanban is inherently tactical. That is not necessarily a bad thing. In fact, that tactical focus is what makes a kanban board a compelling tool for production. But the team can lose out on learnings that come from looking ahead and behind when they are entirely focused on the now. Using models to plan our process improvements is a component of kanban, but it requires exceptional clarity and time investment to do so.

Struggling with estimates

Kanban relies on consistent estimates. Its origins are in factory assembly — linear work. Product development is not one-size-fits-all and it certainly does not follow a straight path. This is the most consistent frustration point I have heard from product teams who feel like kanban failures. Some end up losing limits entirely and managing the board by gut feel. How is that scalable?

Churning with cross-team confusion

Product development is a cross-functional effort. Depending on the complexity of your product, you might have large development teams organized around different areas of the product. Some people adopt portfolio-level kanban to help with visualizing those teams’ interconnected work. What about the other groups who contribute to a successful go-to-market release?

Isolated in innovation efforts

Kanban is about work in progress. It is useful for tracking work that has been vetted and prioritized. But every product development engine needs constant fuel — feedback, ideas, and opportunities to innovate. The kanban method is not designed for this and so organizations end up spinning off separate innovation efforts that are isolated from the rest of the product team’s efforts.

You cannot take a raw concept through to go-to-market and beyond with a few cards and swimlanes. Kanban alone is insufficient for product development.

Now, I can imagine all the kanban aficionados cracking their knuckles and preparing to type out a treatise in defense of the method — delivered straight to my inbox. So before you hit send, let me conclude with a statement that might surprise you. I think a kanban board is an effective and powerful way to harness the power of a talented team and get work done. We even have kanban-like functionality in both Aha! Roadmaps and Aha! Develop. Our team uses these boards too.

There is a caveat though. It is the same caution I give to anyone looking to follow a prescribed methodology. It is also why we continue to push for a value-based approach that prioritizes strategy, cross-team cohesion, and tracking the actual worth of what was built — from concept to delivery.

A workflow method like kanban only supports one part of the overall product development process. Kanban can fit within that structure as a way to get priority work done. But it cannot serve as the structure itself.

Does your team deserve more than kanban? (Yes.) Let's find a better way together.