Linda Bonanno's Weblog

Having held both product management and product architecture roles I’ve had a lot of experience determining product requirements. One thing that I’ve learned is that there are never enough hours in the day to implement everything that you’d really like to deliver to your customers in the time frame expected. Releasing a product can be compared to a 3 legged stool. You have the requirements or content, you have the amount of resources available (people and machines to do the work), and you have the amount of time it will take. One or more of these has to give in order to ship a product.

In this economic environment adding resources is unlikely – companies can’t afford to add to their payrolls. Many are reducing them. Adding too many resources really doesn’t help anyway. We’ve all seen the impact of too many new hires – everything actually takes longer to get done because of the ramp up time and the rework.

Typically a release is scheduled to occur at a set time as well. Many industries have large trade shows at which you want to demonstrate your product’s new features. Sometimes you have a large potential customer with a tight deadline and that will drive a release as well.

The one thing that is left is winnowing down the product features or content. How do you do that? Well, you have to prioritize and decide what is “good enough”. This can cause a lot of friction in organizations.

A lot of arguments over “good enough” are a symptom of a fragmented corporate culture. Disagreements about what is really necessary come about when the various teams involved have completely different understandings of what the customer’s needs and wants are. This usually happens when information coming directly from customers either wasn’t obtained at all (so the teams were making it all up on their own), or the information wasn’t disseminated throughout the organization in the form of priorities.

Questions to ask in prioritization:

• Is the functionality an integral part of the product as a whole? Is it a way to showcase the product and sell it? Is it the “hook” to get customers with?
• How frequently will the customer use this particular feature or bit of functionality? Always, frequently, often, sometimes, rarely, never(!!!)?
• If this feature fixes a problem, how likely will it be that the customer hits it in their use of the existing product?
• How difficult is it to access this feature or functionality? Number of screen traversals? Clicks? Custom programming or scripting? Does this make sense based on how often a customer will use it?
• Do competitors have this functionality? If so – is it a major selling point of their product? Is this a feature that the company wants to compete with? (or is this not an area of focus?)
• Are there standard performance requirements for the functionality that must be met? (UI, networking) If not, what will the customer tolerate? What will delight the customer? How hard will it be to delight them vs satisfy them?
• Is this a feature multiple customers are begging for? (might be a reason to give them an unpolished version for feedback)
• Is this a feature that your biggest and best customer (or potential customer) really wants?
• Is this a problem multiple customers are complaining about? (and how vehemently? Might be a reason for some extra polish)

Product roadmaps and feature prioritization are living documents. As you learn more about your customers and competitors your product has to change and grow. Make sure you concentrate on the right things first.