You will get lots of requests for features from your customers (and from your sales team, and from execs within your company). Most of them, if you implemented them as-is, would be at best a waste of developer resources and money.

But it’s rarely an option to just ignore them, or keep de-prioritizing them to next release cycle – many requests for solutions are obscured insights into problems.  It’s your job as a product manager to think about those problems and figure out which ones are compatible with your longer-term strategy.

Here’s how you say “no” and make it stick:

1. Acknowledge the feature request (using the requestor’s own words)
2. Explain the problem that lead to this request.  (may need to ask the requestor to clarify their request, but this is your synthesis)
3. Describe the cost (in developer hours, lost opportunity cost, investment in obsolete technology, etc.)
4. Show lack of connection to the product/company vision
5. Acknowledge consequences of simply ignoring request
6. Define actionable next steps (turn it into an opportunity)

Download the template (with example features)

This framework puts the focus on the product vision – the equivalent of asking everyone, “What are we here to do? Does this help us do that? No? Then why would we do it?”  (Cue Herb Kelleher story about no damn chicken salad sandwiches.)

It also highlights problems rather than features (proposed solutions).  Features can often be incompatible with a strategy even when the problem is very relevant.  It’s our job to listen.  Tackle that feature prioritization list and start saying no!

To understand “blue ocean strategy”, look at the Nintendo Wii.   Nintendo looked at what the competitors were prizing highly (performance, tech specs, highly detailed graphics rendering) and what they were essentially ignoring (low learning curve/”pick up and play”, real-life group play) and flipped those:

Here’s how I applied it to a real product roadmap exercise.  When looking at my current company’s place in our industry landscape,  I started with a traditional SWOT analysis.  But SWOT, I think, is a better tool for seeing where you are than seeing where you should go.

So I looked at our competitors and made a list of all the elements they bragged about, or where they claimed superiority over a competitor.  For each element, I drew a continuum – instead of just using “low” and “high”, I used more descriptive terms.  Basically, a Blue Ocean-like strategy chart flipped on its’ side:

The attributes are going to vary from product to product (these have been changed a bit from my original document), and a more mature market is going to have tighter clusters.

Interestingly, my current product line is the first one I’ve worked on where the “ease of use” / “expert” continuum isn’t relevant.

With all of the consumer products I’ve worked on, that is usually a big differentiator: are you targeting consumers who want to learn the whole system in 5 minutes, or consumers who pride themselves on learning details and being experts?

There are always limited resources, which means as a product owner you can never fight on all fronts.  But with some good analysis, you can choose your battles wisely and win them.

Why?

- You already have it – they just can’t find it. In every single usability test I’ve ever watched (for my products or others), at least one consumer has asked for a feature that already existed. Most of the time, the information architecture has failed the consumer so that they never found it.

- You already have it – and it’s not that great. Alternatively, the feature could provide sufficiently low value that consumers don’t realize they’re already using it (or tried it, abandoned it, and forgot). I remember reading a number of “voice of the customer” requests for email alerts in a product I worked on. Upon further exploration it became clear that many of them were already receiving email alerts – but received so many that they were ignoring them

- About 5 people will actually use it. What percentage of your audience uses your product regularly? Of them, what percentage is significantly invested in your product that they think up new features? Of them, what percentage take the time to compose an email or post with their suggestion? Most feedback comes from a self-selecting power user audience who is willing to leap substantial obstacles for more functionality.

- You’re adding complexity along with features – and often hidden costs. The folks at 37signals have a great post about “every time you add something, you take something away.” Your customer may not realize what is making their product experience worse, but they can feel the decline. Internally, the hours spent writing functional specifications and code are visible and planned for, but the extra time spent testing, documenting, demoing, updating sales, and providing customer service often aren’t.

- But most importantly: you’re probably missing the real opportunity to solve their problem. The users above who asked for email alerts didn’t actually need email alerts – they needed to make sure their bills were paid on-time. Receiving an email, they figured, would remind them. When they made their request, they probably weren’t thinking of their already-overflowing inboxes.

Eight years ago, I owned a Rio mp3 player. It held about an hour’s worth of music, and if you’d asked me what I would improve about it, I would’ve said it “hold more music.” Other people like me probably did suggest that, because Rio made more expensive mp3 players with 2-4x more room for songs.

I wanted mine to have more space because I was tired of listening to the same songs over and over at the gym. I didn’t change the music very often because the process of loading different songs onto it took long enough that I kept putting it off. With more storage space, I wouldn’t have to go through the loading process as often. The real problem was that listening to music took a lot of work.

One of the process improvements I’m most proud of introducing is laughably simple – ordinal prioritization. As an organization, we were quite good at separating the critical requirements from the important and nice-to-have requirements. The problem was, when we classed requirements as P1, P2, P3, and below, we were unknowingly withholding the even more useful information from our overseas development teams.

Simply put, if we as an organization could only complete one requirement, what would it be? If we could only complete two requirements, what would they be?

By lumping together all “critical” requirements into one designation, we lost that information. We also lost valuable time in the change request process – if a new feature request came up, we needed extensive discussions to identify what could be “bumped” to make room for it.

Ordinal prioritization forces some lively debates, and generally requires signoff from an executive sponsor. The criteria for what makes a #1 a #1 and not a #4 will vary from organization to organization. For us, it was “Will this feature have definite quantifiable revenue impact in landing deals?”, “Will this feature have definite quantifiable usage impact (which drives more revenue?)”, “Will this feature significantly differentiate our products from that of our competitors?”, “Will this feature fix something which is causing significant user experience issues, support issues, or deployment issues?”