The Other Side of Product Management

There are many jobs that a product manager may do, and while most focus the vast majority of their time gathering requirements and selling the products to the sales team, I contend that another equally important role is necessary. This role involves selling the engineering team on the value the new features or changes in the product will have for the customer (and ultimately the success of the group). In other words, for a product to be successful, the engineering team must be motivated to implement the product manager’s feedback. Many projects have failed or been plagued by engineering feature creep because the team did not have confidence in the information stream coming from the product manager(s).

One way to motivate engineering groups is with statistics and objective data showing the value to the customers. Ideally, revenue projections per feature would be great, but this is on par with predicting the weather. Another approach is showing raw historical data on the number and names of customers who have requested a feature; furthermore, having historical revenue data for what each customer paid would be a welcomed bonus. Information like this would provide teams with some objective justification as to why priorities have been set and take the obscurity and mystique out of a proposed new feature set. Unfortunately, this information rarely seems to make a backlog or requirements document. It could be as simple as keeping a spreadsheet with the top 25 features and noting the customers who requested each feature. In addition, it seems like a good sanity check for the product manager to validate intuitions and cross check with others in the company.

3 thoughts on “The Other Side of Product Management

  1. Thanks for the feedback. I have since posted this comment to the above blog entry.

    Roger, I agree that facilitation should make up the bulk of the information flow; however, it would also help to show which customers caused the basis for existing features. Instead of using customer A and customer B, engineers often want to have some basis for the features being proposed, especially when prioritzation occurs. For instance, the question about why certain features are being proposed in front of other features seems like a good place to implement some objective data. Maybe a post on the negative effects of showing objective data might help sway me.

  2. […] Mike Lunt calls this The Other Side of Product Management. If one side is “gathering requirements and selling the products to the sales team,” then the other side is “selling the engineering team on the value the new features or changes in the product will have for the customer (and ultimately the success of the group).” He adds that for a product to be successful, the engineering team must be motivated to implement the product manager’s feedback. Many projects have failed or been plagued by engineering feature creep because the team did not have confidence in the information stream coming from the product manager(s). […]

Leave a Reply to Roger L. Cauvin Cancel reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s