Better Product Managers, and Product Management

There is no contradiction in saying “listen to your customers” and “you own the product vision”.

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!

One of the product management books I frequently recommend is Blue Ocean Strategy: How to Create Uncontested Market Space and Make Competition Irrelevant.  When you’re looking at creating a product roadmap, it forces you to take a broader perspective than the immediate tactical “copy what our #1 competitor is doing”.

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.

When your customers complain about bugs or usability issues, you should fix them. When your customers ask you for new features, 90% of the time you shouldn’t put them on your product roadmap.

Why?

(more…)

When everything is a P1, nothing is a P1.

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?”