Of all the roles in a software or product development organization, I will argue the Product Manager’s (or Owner’s) job is the most challenging. On the one hand, the task of figuring out just what to build is complex and multifaceted. On the other hand, in any reasonably mature product organization, there is so much work that is going on and so much new demand, that the Product Manager can wish all they want in terms of product innovation and focus on the product roadmap, but failure and customer demand pretty much hijacks most of the Dev capacity in the organization.
Product Strategy and Roadmap: We need Innovation (with Detailed Specs, please!)
The product manager has serious responsibilities! They have to define the Product Roadmap and maintain it on an ongoing business. They are expected to come up regularly with innovative ideas that will help the company corner the next market! They have to provide clear and detailed requirements to the Dev team on time, and then they can then no longer change those requirements! They are expected to come up with new product strategy. And they are also expected to provide low-level specs on whether it should be just “Yes/ No/ Cancel” options on a pop-up or just a “Yes/ No”! – and where should the “Cancel” button be placed, if at all. And in many places, they are also the Program/ Project Manager charged with bringing out each release on time! Most of all, they MUST coordinate and collaborate with all the stakeholders to ensure that all good ideas are heard, all critical inputs addressed and customers kept satisfied!
If you are thinking ‘This is me they are talking about!” – then read on
Many Product Managers and their bosses make the mistake of thinking that they – the product managers – need to be an absolute expert in all the areas their products cover. They are expected to have deep knowledge of all of the functional/ business aspects their products cover. And they cannot make mistakes because of course, a mistake becomes a feature that is either incomplete (a “functional defect”) or incorrect or worst of all, never used!
Fighting for Capacity: Can we Focus on the Roadmap?!
On the other hand, the Product Manager is constantly competing with multiple functions in the organization, especially in small and mid-sized companies. Sales and Professional Services constantly bring in new customers/ prospects, without which of course “all those deals would be lost!” Support needs defect fixes and myriad change requests. The CEO is caught between a rock and a hard place – revenue first or innovation?! And, if all that is not enough to turn everyone grey, there are downstream challenges of overloaded Dev and Test teams, Ops dealing with variable infrastructure demand and on and on.
The Product Manager’s challenge is to understand their team’s (or system’s) capability and plan accordingly. They need to plan for both value demand and failure demand. They need to separate the wheat from the chaff – or the signal from the noise – and accept that they may never have as much capacity for what they planned in the roadmap, and that a lot of inputs from these varied sources are indeed part of the roadmap!
Product Manager – The Conductor!
The reality is that a product manager cannot be an expert in the wide variety of domains/ subject areas that they really need expertise on for doing justice to their product roadmap. But the good news is that they need not be!
Product Managers certainly need to have a strong understanding of their product domain and the business value it delivers to all its constituents, but they don’t necessarily have to have a monopoly on good ideas for the product. Instead, they need to recognize that good ideas will come from multiple sources and they must be able to harness those sources for all the ideas they can get and try out!
A product manager’s role is really more like a conductor who must orchestrate all the individual streams of ideas, suggestions, questions, change requests and defects (yes, every defect is an opportunity for improvement after all!), strive to find common themes and put out a cohesive, coherent symphony of a roadmap!
A symphony keeps everyone satisfied that their ideas are being heard, even if not all (or sometimes any!) are being implemented. They understand the what, the why and when just by looking at the roadmap. And most importantly, they have faith in a system that works to put out great features that the customers will want and use on a regular basis.
Enter Kanban – the Visualization, Collaboration, Prioritization, WIP-Limiting “Tribal Mashup” Genie!
Kanban has an amazing effect and impact on the entire product roadmap and prioritization process. The key aspects of why and how this is so are captured in the header.
Visualization – What you See is What you (will) Get!
The biggest issue most stakeholders have is they have no idea what is being planned and what is going to come next in the product. Using traditional methods/ tools for sharing product plans can be challenging to the product manager. Documents, lists, spreadsheets with prioritized features or requirements can be hard to comprehend holistically. Understanding the sequence of releases in which features will come out can also be hard to communicate through a filtered list by release – even if they are well defined.
A Kanban board can be designed to clearly communicate the process and the sequence through which new ideas, feature requests and suggestions move before they become well-defined user stories for the dev team to work on.
A board such as the above elegantly and unambiguously communicates to everyone the sequence of features to be released, their source and their current status. At the same time, it provides a clear picture of what the process is through which all such features must pass before they get into a specific release and detailed.
At Digité, we use a two-level board organization, where a higher level Roadmap Planning board is where new themes and ideas, as well as customer suggestions, get captured. These get decomposed into user stories that get detailed out and then scheduled in one of the upcoming releases for development.
Those features/ user stories that are to be done in the next and current releases are then moved to the Dev board, where they get picked up by the Dev team based on available capacity and any unplanned (failure) demand items – viz. internal and customer-reported defects.
Product Management manages the Roadmap board, Engineering manages the Dev board.
Prioritization – The Product Management Nightmare
The hardest thing for not only the product manager – but for the entire team – is to decide the priority of features and the sequence in which they must be taken up. It can be truly difficult to justify why some features must be selected over the others and taken up before those others.
I have yet to meet a Product Manager who has not had the discussion with their counterpart in Sales or a customer even where every request turns out to be high priority and had to be all at once!
You can hardly blame the sales guy or gal – they all DO look important – and they strongly feel they will lose a customer or a prospect if they didn’t get those features! This is where Kanban excels in helping all stakeholders to decide on the priority of work.
Kanban introduces some key concepts that allow product management to have a sane(r!) discussion with various stakeholders! Top amongst those are Cost of Delay, WIP Limits and Making Policies Explicit.
Limiting WIP!
Instead of asking stakeholders to prioritize tens and even hundreds of requirements, Kanban makes it very clear that any team, at any point of time, can only work on a limited set of things. Instead of looking at ALL the requirements that all stakeholders want, Kanban forces everyone to identify their TOP one or two requirements for the NEXT release and/ or the release after next.
Using a Kanban board and WIP limits on each column (or queue), a PM and Dev team can clearly communicate to everyone what the maximum number of items in each stage can be. In the example board above, the Kanban board can do that easily as below –
Each number on the column header communicates that you cannot have MORE than those many items in that column. So, you could have as many items that your situation allows or requires in the Identified stage – but you cannot have more than 10 items prioritized at any point of time. If for any reason, an 11th item is identified due to an important business deal, then something currently there must move out to make room for this new one.
Once a specific release is defined, you can narrow it down further based on your team’s velocity. It is useful to have the number of prioritized items more than that taken up in a release so that if, for any reason, you have to stop work on a feature or discard it, then you have a readily available set of features to choose from to replace the discarded item.
The WIP Limit at once helps your team reduce multi-tasking and improve the throughput of the team and makes explicit and visual, the policy that you formulate as a team on how much work can be handled at a time. Most importantly, it communicates to everyone that there is limited capacity to do work – and that they must respect that capacity when planning and prioritizing work! If anyone wants to push for a new feature, they must be prepared to take something out. End of that discussion!
Playing the Balancing Act amongst Stakeholders
Besides defining the schedule and sequence, a Product Manager is always challenged with having to ensure all stakeholders have a say in the product release plan. Besides Sales and Support, you could have Management, Customers and even Engineering (Dev) team’s priorities to consider.
Of course, you also have to guard against making your Kanban board to complex to handle by having too many policies to adhere to!
The Cost of Delay – What is the Opportunity Cost?
Kanban really helps the entire team prioritize features by focusing on the cost of delay of features. Using Cost of Delay function charts and Class of Service classification of each feature, a team can reasonably quickly and without emotion, discuss which features must be done ahead of others and without having to compute an actual cost figure.
Using the 4 basic classes of service, you can decide whether there is an immediate and high cost of delay (Expedite – such as a new deal breaker) or whether a high cost will result at a future by definite date (Fixed Date – such as a marketing event or a public holiday), while most work will have a Standard – gradually rising – cost of delay. Engineering work such as refactoring are usually considered Intangible. There may be no immediate cost of delay – but you know that if you don’t refactor for performance or stability or maintainability other such factors, sooner or later, you will run into significant business-impacting issues.
This example above from one of David Anderson’s training class illustrates how you might visualize and highlight different classes of features/ work items to show all stakeholders what kind of demand you have and how you need to balance between these various types.
More importantly, during feature prioritization meetings, everyone around the table can far more easily decide what items need to be prioritized for the next release or the one beyond that.
The crucial process that we at Digité follow is a Weekly Replenishment Meeting where Product Management, Sales/ Support, and Engineering get together to review various themes, user stories and enhancements, including customer/ support-driven items – and select the next set of 5-7 items to be taken up based on the perceived cost of delay of various items.
At the same time, we have also defined a rough capacity allocation for each release between Product Management, Sales/ Support, and Engineering work in order to make sure we don’t always ignore the Important for the Urgent.
Kanban – The Tribal Mashup Collaboration Tool
I love the term “tribal mashup” – I learnt of it when I was part of a panel that discussed Tribal Mashups and how Kanban facilitated it. I had learnt of the collaboration, visibility and systems-thinking approach aspects of Kanban. The term “tribal mashup” I thought really put it together for what Kanban does for complex and long business processes or value streams.
Kanban’s ability to look at systems and workflows holistically – and give all teams visibility on what each other is doing – makes it a critical tool for product management. Understanding how the overall system behaves and how much it is loaded is such an important aspect of release planning and roadmap development. There is no point having a good looking roadmap if your Dev and Test functions – or further downstream, Ops guys, are deluged with unfinished work – or interrupt driven failure-demand.
Depending on your development processes, roles and product release cadence, you can easily set up one or more Kanban boards – or multiple swimlanes in a single Kanban board – that encompasses the entire value stream from concept to deployment.
Doing so makes it possible for all teams to understand and appreciate the workload of each team – and also understand the upstream and downstream dependencies of/ on their own work.
This visualization, combined with an understanding of system-wide flow as well as key Kanban metrics such as throughput and cycle-time analysis brings about a dramatic change in team dynamics and attitude.
Kanban fosters a greater understanding within and across teams. It helps different “tribes” (functions) understand each other’s capability, strengths and constraints. It lays the foundation of high-collaboration environments. It helps to highlight both achievements as well as challenges/ constraints in the system. Kanban’s tools such as blocking a card or flagging it for specific reasons helps teams and individuals get the necessary attention and help when needed. The WIP limits place an urgency on resolving issues and blockers so that work can continue and flow is not restricted. The focus on Flow helps teams take on issues and resolve them and thus improve their collaboration.
As a result, the overall organization is able to focus on prioritizing what is important to be completed and ensuring that all teams are enabled to complete them. Overall organizational flow and throughput shoots up, while cycle time – the all-important ‘time to market’ comes down.
Kanban – A Boon for Product Management
A lot of the early implementations of Kanban have focused on either IT/ Ops or DevOps – where the benefits to Operations and Dev/ Test teams have been clearly brought out. Kanban has of course helped in other business functions such as procurement, legal, HR, marketing, creative, etc.
Upstream or “Discovery” Kanban has got a lot of attention in the last couple of years. It not only helps product management and product organizations foster collaboration and achieve high throughput, it also provides Product Management and senior management some key metrics on how much demand is there on product teams and how to channel that demand effectively. A lot of good suggestions and ideas come in to product teams. Selecting the right ones, discarding those that may not be showing promise are all key aspects of a product management function and Discovery Kanban can provide some insightful data and metrics into that process. More on that in a later post!
I hope you like this post. If you see some of the same challenges in your organization or if you have had success with Kanban dealing with them, or if you have any questions about Kanban for Product Management, please do let us know.
Mahesh Singh
Cofounder/ Sr. VP Product, Digité, Inc.