We'll respond shortly.
(it seemed appropriate to have a cheesy marketing image here)
I’ve been talking with a lot of Product Managers making the transition to adopting agile methodologies. An interesting theme has emerged that I wanted to address. To paraphrase:
It’s hard to influence the product I manage because several of my superiors each want to make their own decisions. How can I help them understand the product development process?
First off, it’s important to remember that you won’t be able to “convince” your boss[es] to adopt your methodologies for story creation and prioritization unless they understand why your approach addresses pain. Being a good PM involves a lot of listening; step one is figuring out what [by your boss’s perception] has improved in the transition, e.g., time to market, code quality, customer happiness. If you don’t emphasize those wins and product development seems to be running smoothly, they’ll naturally shift focus to other problem areas instead of adhering to your new world.
Make sure that the product priorities are public and agreed upon. This makes it harder to shove a pet project into the pipeline without everyone noticing. Keep a parking lot as a visual indicator that these ideas are significant and that you have heard what they think. It’s also key to make sure that their ideas are publicly captured to promote visibility. Jon posted recently about the importance of a portable parking lot that lets you carry it into IPMs.
Not everything should make it to the parking lot, however. Try to reserve this space for ideas which are important but not urgent and ideas that don’t fit into your short- and medium- term strategy. Joel Spolsky has a great article that touches on this:
Every product attracts new feature ideas, and you can’t implement ideas as fast as you can think them up, so you write them down, and this list is called the feature backlog. A lot of the ideas on the backlog are bad ideas, and you merely wrote them down to avoid hurting the feelings of the people who thought them up. Backlogs make everyone feel good. The trouble is that 90% of the things in the feature backlog will never get implemented, ever.
Managers are perceptive enough to get to where they are, and will catch on if you simply put everything in the Icebox and give it a Viking’s funeral.
Develop a “Fitness Function” that represents the top priority. Each workgroup in Amazon must build a “fitness function,” a customized equation that combines the most important metrics for a particular group into a single “fitness number.” If this number isn’t going “up and to the right” consistently, the group is in trouble.
If you can get buy in from your bosses that this represents the most important elements of your product’s evolution, you can require that they put money on the table (in terms of resources, backing, etc) for any initiatives/features they want to push. You can also force them to pick the thing in progress (or in the backlog) that needs to drop in priority as a consequence. Make sure they understand that the feature they are bumping had an anticipated lift to the fitness function that their feature needs to fulfill as well. In other words, the more you can justify everything that you put into the backlog, the harder it is to insert something that is unjustified.
This kind of measurement is predicated on capturing metrics for the most important conversion steps. It’s okay if you aren’t doing much (or no) tracking. Knowing that it will take time to get all of your analytics in place, put together a plan for tracking the most important pieces.
Managing up is one of the hardest jobs a PM faces in a transitional organization. Over-communicating and over-empathizing will go a long way towards building a healthy dialog about product with your boss.