The dreams of product managers die in the gap between what customers say and what they actually do. Product ideas gathered from customers are crucial. But they are not universal proof of what they actually need. In a similar vein, complaints from users often compel product teams to react at the expense of hitting long-term goals. That is lazy product management.
Product managers must diagnose customer complaints to fix the root of a problem — not just soothe a symptom on the surface. They must also scrutinize requests through the lens of a products’ strategy.
Applying this philosophy hinges on having a thoughtful product roadmap with specific, measurable goals (“Grow users 4x in 2015,” “Acquire X market segment that engages with channel Y”, etc). Clear objectives, articulated via a product roadmap or another way, helps you evaluate customer requests judiciously — before you stack them on your pile of features to be implemented.
Natasha makes some good points in this post, if you capture customer ideas at all, then you need to know how to prioritize them, which she covers later in her post:
When you have ideas competing for limited time and money, it’s important to act cautiously. At the same time, you can’t afford to get paralyzed by analysis. So, you need a quick way to separate obvious hits from near misses. Try the below framework for prioritization to help you focus your efforts on concepts that matter most.
For one axis, consider the positive impact of a feature related to the goals for an upcoming release. With the second axis, consider the level of ambiguity in either the definition of a feature or how it may be implemented. Then, as a team, plot the items on your list in one of the following categories:
Do it These product features are glaring pains or exciting opportunities to be taken advantage of. Beyond their obvious benefit, these features are also well understood. Their value to the product line and business is clear and quantifiable.
Queue it This category is for items that have high business value. However, your product team is fuzzy on how the feature will be implemented. That ambiguity may be due to technical or business uncertainties. For such items, your team may need additional evaluation before they promote them to the “Do It” quadrant. These features are candidates for your next release.
Trash it Sometimes, a feature request is well understood, and your team agrees that its functionality offers little or no value. In this case, the request should find a home in the “Trash it” quadrant.
Triage it Let’s consider a feature that is shrouded in mystery. Set aside time to further analyze it. While some of these items progress to “Trash it”, this is not always the case. Occasionally, upon further analysis, you find that the item is of great value — and will be promoted to the “Do it” quadrant.