AT&T Wireless is in trouble. Years of optimizing their business in favor of their shareholders over their customers has led to a customer revolt that is being noticed by the media. They are losing customers and, as a result, a critical partner is losing customers as well.
As a product manager, this is a worst-case situation: your product is sub-standard, customers are upset, partners are upset, and corporate strategy doesn't give you the resources you need to solve the problems. While a problem the magnitude of AT&T's may only be solvable at the executive level, it is (unfortunately) not uncommon for a product manager to be in a similar situation at a product level. You, Mr. Product Manager, need to fix it.
This is the time when you need to put all of your leadership training to work because it is going to take a lot of influencing to get everybody on board. Once you've psyched yourself up, it is time to roll up your sleeves and get to work!
Planning
In preparing for battle, I have always found that plans are useless but planning is indispensable. - Dwight D. Eisenhower
My experience with planning has been much like Ike's: Valuable to flesh out problems you might encounter and ways you might handle contingencies, but quickly becoming irrelevant once engaged on the field of battle. The value in planning is in determining what your capabilities are, what contingencies can be put in play, where the mine fields are, and, most importantly, what the end goal is.
The end goal is really what you are looking for here. What needs to change from where you are today and what will the positive and negative impacts of those changes be? For instance, if you are suffering from poor quality, spending time fixing defects will increase customer satisfaction and potentially reduce customer abandonment; however, it may also cause you to fall behind your competitors. It is important to recognize both the positive and the negative in order to paint a realistic picture. Doing so will give you the data to validate you are doing the right thing (we're not managing by gut feel, right?!) and adds credibility to the plan. That credibility, in turn, will help you get support from others.
Now that you've determined what the end goal is and mapped out a path to it, it's time to gather that support.
Outside the Product Team
Dealing with problems is products is never fun. It also interferes with strategic goals and can make the sales cycle more difficult as your competitors take a lead. Anything that hurts the sales cycle will not be viewed favorably by executives. If you don't handle these cases, you can find your plan being shot down before it has a chance to get off the ground. If things aren't bad enough that everybody is screaming "fix it" (and if they are, you should have started before now!), you need support to get this done.
Remember, the data you gathered illustrates why it is important, but most people still make decisions based on emotion. If your data is supporting this action, you can often find support for your objectives from either customer support or your account execs. While support is useful, if you can get your AE's on board, you have the ability to show how problems in your product are going to cause a hit on the bottom line as upgrades and additional purchases by existing customers goes down.
Support is gathered one person at a time. Get a bunch of people in a room and you'll go nowhere. Talk individually, and you can overcome resistance.
Inside the Product Team
Depending in your team, this can either be the easiest or the hardest part. Often, it is the latter.
It's easy when your team is sharp, follows good practices, is well managed, cooperates, and wants to put out a great, high quality product. Of course, if that were the case, you would probably not be in this situation.
I've seen QA teams who didn't understand the product they were testing. I've seen engineers who felt they knew what was best, no matter what the data said. I've seen sys admins who cared more about process and paperwork than about the customers using their web sites.
These are hard problems to solve; you could fill whole
books
with ways to solve them; there is no way I'm going to try it in a single blog post. What you do need to do is polish off your leadership cape and get back to work. The product team must be convinced of the importance of reaching the end goal; this includes managers and contributors both!Once everybody is convinced, you need to identify where the problems are. You will often get pointed in circles, indicating multiple problems (the QA team above also had an engineering team that was less than stellar at writing unit tests). Then you need to work with the respective managers to come up with a plan to resolve the problems. Finally, don't underestimate the impact of the "my team is perfect, everybody else sucks" attitude. That may be the hardest problem to fix.
Rework the Plan
By this point, you'll find many of your assumptions in the original plan were wrong (even if the end goal remains the same). Now it's time to update the plan based on the newly understood reality and start executing. You need to keep everybody focused and ensure you understand the priorities of things to be fixed.
Results
As always, measure your actual results against what your expectations were. How did improving quality affect important metrics (whatever those are for your product)? If your expectations were wrong, why were they wrong?
Aside from the actual product impact, strive to make meaningful, long-term change. Not only should your product be better, but your product team should be better. Otherwise, you'll find yourself in the same situation in another three releases.
And you know you don't want to go through that again!
Image credit: Jim Girardi
