How to Create a Kanban Board for Product Management

Project Management

A Kanban board is a workflow visualization tool that displays work items as cards moving across defined stages, from initial entry to completion. Originally developed as a manufacturing management tool by Toyota, Kanban boards have become ubiquitous in software development and increasingly valuable for product management work itself — not just for development teams, but for managing the full range of research, planning, communication, and decision-making activities that define a product manager’s daily work.

Understanding how to design and use a Kanban board specifically for product management — rather than just for development teams — unlocks significant workflow visibility and bottleneck identification benefits that improve both PM effectiveness and team coordination.

What Makes Kanban Valuable for Product Managers

Product managers typically juggle many parallel workstreams: active discovery research, features in development, stakeholder communications, roadmap reviews, customer conversations, and launch preparation — all simultaneously. Without a visual system, this complexity is managed through to-do lists, calendar entries, and memory — a system that makes bottlenecks invisible and makes it difficult to communicate current workload to stakeholders who make requests without understanding what else is in flight.

A Kanban board for product management makes this parallel work visible: stakeholders can see what the PM is actively working on, where things are blocked, and what’s coming next. It also reveals where the PM’s time is actually going — which often differs from where they believe it’s going, and is essential data for managing workload sustainably.

Designing a Product Management Kanban Board

The stages of a PM Kanban board should reflect the lifecycle of product management work items:

Backlog / Inbox: All work items identified but not yet started. This is the unsorted queue where new requests and ideas land before triage.

To Research / Define: Items that require discovery work before they can be planned — user problems to investigate, strategic questions to answer, competitive dynamics to understand.

In Discovery: Active research and definition work. The PM is conducting interviews, analyzing data, or working through the problem space to understand it well enough to make good decisions.

Ready to Plan: Discovery is complete; the item is ready to be translated into roadmap commitments or backlog items for the development team.

In Roadmap / Planned: Items that have been prioritized and added to the active roadmap or near-term backlog. Engineering knows about them and can plan accordingly.

In Development: Features the engineering team is actively building. The PM monitors progress and is available for questions, decisions, and scope clarification.

Launching: Features approaching release, with the PM managing launch coordination across marketing, sales, and customer success.

Done / Measuring: Features shipped; the PM is measuring outcomes against expected results to close the learning loop.

WIP Limits: The Most Powerful Kanban Practice

Work-in-progress (WIP) limits constrain how many items can be in each stage simultaneously. When a column is full, no new items enter until something moves forward. This constraint is counterintuitive but powerful: it forces finishing before starting, which reduces context switching and surfaces bottlenecks.

For product managers, WIP limits might mean no more than three items in “In Discovery” simultaneously — which forces prioritization of which research is done now versus queued. This prioritization discipline produces better research and better product decisions.

Key Takeaways

A Kanban board designed specifically for product management work — with stages that reflect the PM’s actual workflow, WIP limits that enforce focus, and visual representation of all parallel workstreams — creates the workflow visibility that enables better work management, more honest communication about capacity, and earlier identification of bottlenecks that would otherwise remain invisible until they become urgent problems.

Share this article