If your engineering team hasn’t already moved to some form of Agile methods (like Scrum or XP), then it’s likely they’re at least considering it. Agile really does attack some key problems that have plagued software teams for decades. But many product managers and designers, and to a lesser extent QA staff, are initially confused by Agile, unsure of their role in these methods. To be clear, these methods absolutely require these roles, but I attribute the confusion to the origin of Agile methods, and I’ve found that when I explain the origins, it helps to illuminate the problems that Agile was designed to solve, and what challenges remain.
Very often I’m asked how product managers should be measured. I have long believed that the only true measure of the product manager is the success of his or her product. While I still believe that, it’s not a very satisfying answer, as it’s not clear what the best way to measure a product’s success is. Is it revenue? Profit? The number of users? Page views? All of these indicators can be useful but they don’t really provide the big picture.