Input Management for PMs

Guy Barner
8 min readFeb 10, 2020

As product managers, we need to handle more feature requests than humanly possible. I mean that quite literally. We have limited capacity for handling information, and when we try to handle more than we can, we often just choose the latest or loudest input. In this post, I’ll share my approach to managing inputs, and recommend some tools and methodologies to help you do that more effectively.

Before you prioritize

Every trip requires a destination. Before you start prioritizing features, make sure you have two things: a vision for your product, and a strategy for how to get there.

This vision for the product is often very elusive. It seems that everyone should know what we’re working on, right? Well, not always. When I started my current role at litigate.ai, opinions on what it is we’re doing varied a lot. While some thought we should be focusing on one particular problem, others thought we should be building a comprehensive, end-to-end solution for lawyers. It took some work to get everyone looking at a single point on the horizon.

After everyone commits to the vision, we still need to agree on the best way to get there. What is it we’re looking to achieve over the next few months? Are we improving reliability for existing customers by investing in infrastructure and reducing bugs? Are we improving the UX by going into a redesign project? Are we moving upmarket? Try to keep it to about 2–4 main strategic goals, and try to attach a clear KPI to each, to make sure everyone is aligned.

What are feature request inputs?

Feature requests come in all shapes and sizes: sales and marketing are asking that you build new things, while support and customer success are asking you to improve existing functionality. If you’re doing B2B, many customers will ask for features that are a must for their specific use-case. Some of the louder ones will threaten to leave if you don’t build it. Then, you also have the founders’ vision for the product, a bug list that goes on for miles, and every now and then you even come up with an idea yourself that you think might work. Soon enough, you’re facing a feature request list that spans across hundreds of rows.

How do you prioritize such a list? Without a system, many PMs revert to shortcuts. Some PMs, as I said, will prioritize the feature they talked about this morning. This is called the availability heuristic, as coined by Nobel laureate Daniel Kahneman and his partner Amos Tversky (if you haven’t already, go read their book “Thinking, Fast and Slow”. It is an absolute must-read for PMs). Others will prioritize the features the CEO asked for. Many will just look at the list and pick the ones that “feel” the best.

I’d like to suggest a different approach. Without additional information, prioritizing a feature request from the CEO against one coming from a customer is a little bit like comparing apples to, well, slightly different apples. Yes, they’re both feature requests, but there is some information missing here: what does the CEO think about the customer’s request, and what does the customer think about the boss’ idea?

In order to make the best decision, you need to gather more data. This means taking each of those hundreds of requests, and adding all the information you can: who asked for it? What KPI’s will it affect? Does it fit the company’s goals? In practice, we’ll create a spreadsheet with all the features, and all of the possible inputs, according to your favorite prioritization methodology.

While this inevitably takes time, I consider it time well spent for a few reasons: first, because you’ll get a more rounded picture of your product by talking to various stakeholders; and second, because everyone will love you for taking the time to get their inputs.

If you’re worried about the amount of time this takes — you're absolutely right to be nervous. But there is a shortcut. Go over the list first and pick your top 30–50 candidates, and then ask the stakeholders if there are any other important features that you left out. This makes sure you take their important issues into account, and will get you good results in a lot less time.

Methodologies:

In this section, I’ll introduce and analyze some of my favorite methodologies for prioritization.

Goals & Objectives

In the start of this post, I mentioned you should never start prioritizing without having 2–4 strategic goals. One good approach for prioritizing features is to make sure you only include the ones that get you closer to the mark. This will force you to be heavily focused, but at the same time will mean a lot of things will get left out.

Another benefit of the G&O approach is that it constantly confronts you with your goals. You’re likely to have features you’re keen to put in the roadmap, but that don’t really meet any of your high-level goals. That dissonance will make you rethink your objectives. While you’d usually end up droping the feature, every now and then you’d realize you were aiming at the wrong mark, and change the high-level goals.

Use it if: always, basically.

RICE

Those who’ve worked with me know that this is my go-to. RICE stands for:

I won’t go too much into what this means, as it’s mostly intuitive and you can read about it in many other articles.

I will mention that the C-part is absolute genius. It means: “how much am I really sure about the other 3 criteria?”. Too many times we make decisions because we guess that a feature will be important after talking to 1–2 customers. RICE forces us to say “these are the features I need to learn more about before I prioritize them”.

What I love about RICE is that it makes you answer questions that are easily disregarded. When we like a certain idea, we usually don’t stop to think “how many of our users will this help?” or “will this really move the needle?”.

Each of us has a natural bias toward a certain type of features. Personally, I always like quick improvements. Other PMs I worked with were inclined to customer feature requests, or to huge projects. In reality, you ideally try to balance high-reach-low-impact and low-reach-high-impact features within your roadmap.

Use it if: you’re in growth mode. RICE is not very helpful if you’re early stage, where most feature ideas have high-reach-high-impact potential.

The stakeholder juggle

Get the top feature requests from all stakeholders, see what everyone agrees on, and then play short-blanket with the room you have left, and try your best to keep everyone happy.

You can guess by the tone of my writing that I’m not the biggest fan of this approach. I’d rarely advise to use it as the primary system for making decisions. It is, however, great as a complementary tool to make sure you balance the needs of the different departments, and to make sure you don’t neglect the needs of any specific department. Or, if nothing else, it can prepare you for the backlash from the people whose opinions are not reflected in the roadmap.

Use it if: you have a very dominant executive team with lots of ego.

Tools:

To make sure the ride is smooth and you can focus on prioritizing, make sure you have the right tools. This post has already stretched long enough, so I’ll try to be concise about this.

Productboard

To me, simply the best input management tool for PMs today. I’ve been using it for 2 years now and it just makes my job easier.

While input management is basically always performed in table, that type of table you use is important. Productboard helps you organize your feature requests, add all the inputs you need with custom columns and calculated score. But the main value is that it directly connects customer feedback to thise features, which mean you can complement your quantitative scores with qualitative insight, giving you a broader picture and great basis for discussion.

I’m a die-hard fan, but to me, Productboard are also true masters of product, and much of the benefit I get from them is just inspiration on how to do things right, from UX to feature updates.

Cons: if you’re on a large team, you’ll need everyone’s buy-in to use yet another new tool. I personally failed at this in one of my previous roles.

Airtable

The more flexible, affordable and easy-to-learn tool. Being basically a spreadsheet, Airtable is much more flexible in the types of columns and formulas you can use. it also has amazing built-in pivots that let you quickly see all of the features under a specific tag.

However, it doesn’t give you that end-to-end coverage that Productboard offers. It can great for prioritizing, but it’s not as good in connecting it to insights from customers or to communicating the roadmap internally and to customers.

Feature request form

Whichever tool you choose for prioritization, I’d urge you to formulate inputs using a feature request form. There are a few things you need for every input: Which customers asked for it? How important is it to them? What problem does it solve?

Freestyling feature requests will guarantee you’ll spend a lot of time going back and forth trying to understand the requests. Personally, I use a Google Form that automatically sends an email to my Productboard inbox.

Tools I would not recommend

Slides and email are common tools for input management that I absolutely do not recommend using. They are time-consuming, non-scalable, and do not give you good visibility to the required data.

If you’re using an Excel or Google spreadsheet, I’d highly recommend you upgrade to one of the above tools.

Defending your roadmap

Every PM knows that building a roadmap and approving it with all stakeholders are two very different things. The roadmap is basically you telling a bunch of executives what they can not get. That’s the real hard part.

Having not just a prioritized list of features, but all of the inputs, scores and customer insights in one place will help you justify your decisions to the rest of the company, and will kick off data-driven conversations instead of opinion-driven ones, ultimately making your job a lot easier.

My last few posts got a lot of reads and claps, which was a lot of fun. This time, though, I’d really love to hear back from you — what do you use for roadmapping? Did I leave out anything important? Let me know in the comments below.

📝 Save this story in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.

--

--

Guy Barner

A Product Manager with time to spare. Working on a super cool new project, visit us at tagbox.io