I should have written this article many years ago.
Starting around 2004 and 2005 I began seeing an increasing number of teams moving to Agile, and of course the first thing they needed was training and often some coaching.
However, more often than not, I had to go into these companies after the training and try to clean up the mess that the trainer left behind.
This article is a little bit different, but if you make it to the last paragraph, I'm hoping it will help better explain where I'm coming from.
I'm always badgering teams about moving faster. Yet I continue to meet people and teams that not only move very slow, they don't understand the relationship between speed and innovation, or speed and quality. In fact, many people still think those goals are at odds. I attribute this mainly to a deeply rooted Waterfall mindset.
Note: This article is a collaboration between myself and my long-time friend and colleague Jeff Patton. We often work together to help product teams.
In my last newsletter I wrote about Stakeholder Management. That article seemed to strike a chord with many people.
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.