I'm not sure why I haven't written specifically on this topic before because it comes up as an issue with so many teams. For many product managers, managing stakeholders is probably the least favorite part of their job.
People approach creating products from many different perspectives. Some seek out customer pain and dedicate themselves to solving their problems. Others follow the technology and strive to deliver solutions that are just now possible. Some like to follow competitors and deliver better solutions in a fast-follower model. Others are simply trying to find a way to make some money so that they can sustain their business.
Every week I continue to find product teams laboring away on old-style product roadmaps that have been painstakingly negotiated with management and stakeholders, sometimes for several quarters in advance. I have written several times about the problems with this approach and why it so seldom results in the business impact that the organization was hoping for (see The Opportunity Backlog and Product Roadmaps).
The term "pivot" is probably one of the most overused and abused terms in today's product teams. If you're not familiar with the concept, see Your Business Plan Is Wrong.
In my last article, I discussed how we manage public commitments in an Agile, Dual-Track environment. In that article I talked about those public commitments that are needed to run a business, such as when a customer can count on getting some capability, or when a development partner can plan on testing, or determine what will be available for the upcoming holiday season.
The past several articles have discussed the nature of Continuous Discovery and Dual-Track Agile. In this article I'd like to discuss another dimension of working effectively in an Agile environment, which is how we manage commitments.
In my last article I wrote about the trends of continuous discovery and continuous delivery. At the end of the article I pointed out that while I love these techniques because overall they are much better for our customers, and for our ability to rapidly improve our products, there were a few important consequences that had to be dealt with. In this article I want to take about the impact of continuous delivery on product marketing and our marketing, sales, and service organizations.
I have written recently about how product teams do product discovery in parallel with product delivery. I have also written about how teams sometimes like to time-box their product discovery work.
Recently I wrote about Apprentice Product Manager programs, where companies recruit and groom high-potential product managers. Quite a few people asked me about this program and the type of curriculum that I have provided for my own teams in the past. In this article, I thought I would talk about one of the most basic forms of training I have provided these people, "Product Manager Charm School."
When I first start working with an Agile product team, one of the most common situations I find is where the teams have long and frustrating Sprint planning meetings because backlog items are poorly defined and not well understood; they have slow velocity as well as poor design because details are still being worked out during the Sprint; and the amount of waste and rework is very high because backlog items have not been validated.