Steve Johnson
sjohnson@pragmaticmarketing.com

What is the product management role in prioritizing product defects versus new features? We have limited development resources and can only do so much in each release cycle. We have dozens (or hundreds) of product bugs in the tracking database. We have pressure for new requirements from our sales force and execs. Should we fix defects or add new features?

Or to put it another way, Should we keep our old promises or make new ones? Should we deliver on the promises we've already made to our customers, or should we make new promises to get new customers?

(You can see where this is going, can't you?)

If there are limited resources, and you can't do both, which do you choose? Bug fixes every time. Why? Because it is 17 times more expensive to win a customer back than it was to get him in the first place. If development can't do both, tell management. It is not our leg of the race to run, not our problem to fix. That's why we have managers in Development. It is our job to report this dilemma in the business, though, so the Cxx folks can address it.

When customers call in with a problem, technical support rates the problem by severity. My preferred rating is:

• SEV 1: the product is not working
• SEV 2: major product functionality not working
• SEV 3: doesn't work as documented
• SEV 4: enhancement request

SEV1 and 2 (product failures) must be fixed--if they can be duplicated in the field in more than one customer site. (I'm not talking about the one person who can make it fail "if you do this" or the QA test failure that can never happen in the field.)

As for SEV3 (doesn't work as documented), we have already articulated how the product should function via the original market requirements. There seems no need to re-articulate which of these requirements really must be met. After all, requirements are either necessary or not. So the defective code must be fixed to meet the already stated requirements. Here's a quick workaround: the user and support documentation could be updated to be consistent with the product's actual functionality. Microsoft does this well in their online support Knowledge Base, saying in effect, we know about the problem and we don't know when or if we'll fix it. Nonetheless, if the product doesn't work as documented and if the original requirement is truly valid, then we should change the product to work as documented, and not the other way around.

SEV4s are the only "defects" that need to be considered by product management. But SEV4s should never be fixed in the current release. Instead, they will join other enhancements and product ideas in the next planning cycle.

It can be very simple: product failures are fixed in this release; product enhancements are considered for a future release.

Yet in many firms, product management is involved in daily product operations, determining which defect should be fixed first and balancing these against new business requirements. Spending time in this way prevents product managers from learning more about the market. In our writings and seminars we emphasize product management's role in truly understanding the market, yet many product managers remain ignorant of their customer base and potential market.

Why are you spending time off the chart? Internal meetings prevent external visits. Remember: nothing important happens in the office. Who is listening to the market while you're attending internal meetings?