How To Be A Good Product Manager

Tips on product management and product marketing for product managers. By Jeff Lash

Track customer requests appropriately

Posted on February 12, 2007 by Jeff Lash · 2 Comments

Like this post? Help to spread the word...

If you want to be a bad product manager, respond to every feature request that comes in from the market. If one customer is asking for it, there’s probably dozens of others whom you are not hearing from would benefit from it. If you want to be customer-focused you need to listen to all of the customer feedback coming in and respond to all of it. When there’s a posting on a message board about a specific potential feature, make sure to either get working on that feature and/or reply and let people know when it will be available. You don’t want customers requesting things you don’t plan on delivering, do you?

If you want to be a good product manager, track high-level customer needs and requests and prioritize them over the long term. You’re going to receive more requests for new features, changes and enhancements than you can realistically respond to or even capture at a granular level. Reacting to each individual request will take up all of your time and leave you with a product with no discernible focus and a hodge-podge bunch of reactive features without clear benefits.

You need to make sure that you have a good way to collect and track requests from customers as well as internal ideas so they can feed in to your product roadmap. Individual customer requests are not as important as the aggregation of all of the customer requests. Be careful to not just tally votes, though, as the number of times a feature is mentioned does not correspond to its importance or priority.

In Getting Real: Forget feature requests, 37signals team discusses their method for managing (or not) requests from customers:

When you launch your products, customers will send you hundreds or thousands of feature requests. … So what do you do with all these requests? Where do you store them? How do you manage them? How do you track all these requests? You don’t. Read them and then throw them away. … You don’t need to track or remember everything — let your customers be your memory. They’ll remind you.

This may be a bit “extreme” for your company, but the point is valid. Tracking customer requests is less about tallying the number of times each specific item is mentioned and more about understanding general trends and areas where there is potential for delighting customers. While you may want to take the 37signals approach and throw out all feature requests, your corporate governance and project funding processes may dictate otherwise.

Regardless of how you approach it, make sure not to react impulsively to every individual customer request. Instead, develop a plan for collecting and managing customer input — along with other sources such as internal ideas, technology enhancements, and corporate strategy — and use that to drive future enhancements and your long-term product roadmap.

How To Be A Good Product Manager features tips on product management and product marketing, written by Jeff Lash (@jefflash on Twitter), Vice President and Group Director for the Product Management and Portfolio Marketing research and advisory services at SiriusDecisions.

Like this post? Help to spread the word...

2 responses so far ↓

  • Carfield Yim // Feb 14, 2007 at 3:27 am

    Very good inspection!

  • Harry Nieboer // Feb 25, 2007 at 3:20 pm

    A clear naming convention helps to decide what’s in the next release, and what’s not.

    e.g. whent your next release is called “Usability release”, wou would not want to include new functionality in that release.

    Actually, the convention fits nicely in the way releases should be handled within RUP. For every release a problem statement and a product position statement are developed AND agreed upon between all stakeholders of the project.

    The problem statement is a solution-neutral summary of the stakeholders’ shared understanding of the problem to be solved.
    The product position statement is the “mission statement” for the system to be built (the solution). The product position statement is a vehicle for communicating a brief definition of the system to all stakeholders (definitions from safari).

    The problem statement and the product position statement are excellent tools to use in the CCB (Change & Control Board) who decides on including or excluding new features in the (next) release. Both statements are documented in the RUP Vision document.

    If you have a hard time defining these statements, you will definitely have a hard time with scope-creep. Now you see why!

    For more on this subject, see: http://hij2mc.wordpress.com/2006/08/21/handling-feature-creep-on-your-next-release/

Leave a Comment