Tuesday, January 5, 2010

A Product in Trouble


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

3 comments:

Ryan Strynatka said...

Great post - you've raised many of the *really* tough problems that come up in Product Management, along with some sound strategies.

One other consideration for products in trouble: take a deep look at why the product is in trouble. It may become clear that it is time to start thinking about "life-cycle maintenance" mode. Retiring products is tough, but can be the right thing to do in some cases...

Larry said...

Such a teaser article; yes you could write volumes on this topic. Only problem is each situation is unique and there is no one play book that will work.

The relatively easy part is to identify the issues and possible solutions. If you listen closely everyone around you will be telling you them. The devil is in the details and getting the individual/teams aligned on implementation.

The best way to do that I have found also is as you described. Tackle each one [stakeholder] individually and then begin to build support. Determine who is truly calling the shots. Often times and executive is just a figure head. Who is behind them pulling the strings. That is the person you want in alignment.

Realize the plan is going to morph as you go along. You may even have to revisit some stakeholders several times. Ultimately you can get them, or the decision makers, in a room where they can see the heads nodding in agreement.

While it would be nice if this was like on TV and it wrapped up in a half an hour, its not. Plan on spending time pushing this through. Ultimately that is what makes product management so rewarding (IMHO).

Travis Jensen said...

@Ryan: You are absolutely right. One of the first steps you need to take is to evaluate whether the product in trouble is worth saving. Many times, companies will spend money trying to save a product that should be retired instead.

@Larry: As I wrote the post, I wasn't sure how to communicate the iterative nature of the whole process. Those conversations will continue until the product is out of trouble, which may be one or more releases later. House could probably get it done sooner.