What Every Busy Product Manager Needs to Know About Prioritization

Brian O’Connor

Product managers develop ideas by reading industry reports, speaking with customers and prospects, and attending conferences. But then they must field ideas and feature requests from executives who drop in, marketing departments that want new features to promote, sales teams that promise a feature to close a deal, and more. These ideas for new features don’t trickle in with a manageable flow; they crash in like a tsunami and leave product managers feeling overwhelmed and understaffed.

Every product manager knows that feature prioritization plays a vital role in determining how successful a product will be. And with product managers facing a long list of to-dos, most prioritization is done with gut feelings, many of them seek a better, more data-driven way to make decisions that won’t add time to the process.

But here’s the tricky part of the prioritization equation: in 42 interviews with product managers, the most common frustration was not how to stop these suggestions from coming in, it was how to prioritize the feature suggestions they receive. The answer isn’t always clear from the start, and the company’s current prioritization process leaves stakeholders asking, “Where’s the beef”?

Enter: the following four step process that can help you show your stakeholders how and why you make decisions about upcoming product features.

Step 1: Quickly separate good ideas from everything else.

First, stop treating every request equally. Some feature requests aren’t very good, and everyone — except for the requester — knows it. So why do we insist on fully analyzing each request when some can quickly be dealt with?

I’ve found these three questions can quickly, and in a data driven way, separate good requests from the bad::

Is it valuable to the market?
Anything might be valuable to a particular customer. A project manager must therefore make sure that the product is built for the market, not the customer.

Is the feature feasible and does it pass conceptual integrity.
Can this feature actually be built? If it can be built, can it maintain the product’s coherence?

How much work it will take to build this?
Is the resulting functionality worth the investment of time and budget it will take to build it?

Each of these three questions will filter the request through a mix of qualitative and quantitative analyzes. These questions aren’t perfect, but they’ll save time so you can more thoroughly analyze your team’s best requests.

Step 2: Link remaining ideas to overarching product and corporate strategy.

This may sound remedial, but in reality linking individual ideas to the big-picture of product and corporate strategy is incredibly nuanced and difficult because most product and corporate strategies aren’t well articulated. The prioritization of your initiatives will be easier if you know how closely each supports your mission as a company and product developer.

If you’re anything like the majority of companies in the world today, your corporate or product strategy might look something like the following:

Example corporate strategies:
Expansion into new industries
Selling through different channels
Financial targets including sales growth, margin percentage

Example Product strategies
Improve engagement
Improve awareness
Customization for specific verticals

Any new idea in development needs to clearly advance at least several of these strategies, and the expected advancement should be quantifiable.

Step 3: Allocate time for more frequent communication.

Here’s a situation that might sound familiar to you: someone asks, “Where’s the feature you committed to deliver?” and inevitably, you don’t remember what feature they’re even talking about! The truth of the matter is that product managers often miss opportunities to communicate. And in a world in which it takes the average person seven times hearing a message for it to sink in, that’s a missed connection that needs to be remedied.

The challenge lies in communicating a feature’s status seven times without being a bore. The solution is to communicate with your team more frequently through monthly, weekly, and quarterly newsletters and business reports that talk about features, the market, major wins, and status updates about your customers. Then meet weekly, monthly, and quarterly with key stakeholders to share updates and new information. This may sound like a lot of communication, but all the information exists in your inbox.

We’ve heard the litany in favor of persistence time and time again: Rome wasn’t built in a day. Editors rejected Harry Potter 12 times. Google pitched 350 VCs before one said yes. Changing how you prioritize and communicate feature requests is hard work. Don’t let the hiccups you have along the way prevent you from moving forward. If your product management team is struggling to prioritize a mountain of feature requests, don’t hold back. Get started today with as perfect a plan as you can and accept the fact that you’ll work to make it better over time.

(90)