A helpful guide for figuring out what to do next

Presented by Adam Oxford

INTRODUCTION 

It’s been described as the “new button problem.” Your editor-in-chief wants a new button on the homepage encouraging sign-ups to the newsletter. The problem is that no one knows if adding that button will actually result in readers taking the intended action: Is it in the right place? Is the wording compelling? Would a different color be more effective? Is its call to action even something readers want to do?

But the boss really wants that button, even if it takes a lot longer than they realize to implement and uses up valuable page space and developer resources that could be doing something more productive.

You drop everything and set the team to work. 

The button may be a trivial example, and it’s easy to set up in the context of a valuable UX experiment. But what if the request is something more involved, like a new editorial section, an account management page for subscribers, or an additional payment gateway? How about a true crime podcast series or a platform for video explainers? 

Aligning newsroom goals with our readers’ needs and what we have resources for is the supreme art of the product lead. It requires technical competence, stakeholder management, and a keen eye on the top level objectives. This guide offers practical tips for receiving and prioritizing product requests with these tenets in mind.

IN PRACTICE

Use the tips and concepts in this section to cultivate a product culture in your newsroom

Use a ticketing system to collect requests for new features and products 

There are many ways to collect feature requests from internal staff, and one of the best — especially for smaller organizations — is to make use of the tools you already use. Your product and editorial teams might already have a project management tool like Trello, Asana, or Monday.com to manage workflows. Getting folks to add requests directly into a specific “ideas and issues” board is a low-effort way of capturing their thoughts. Some tools even have add-ons that enable form- or email-based submissions to be converted automatically into prospective tasks.

Gather feedback from your audience

The best sources of new feature requests are your readers. They aren’t always right, but they will always see things you don’t. Make it easy for them to send feedback about what they like, don’t like, and want to see in your products. A simple Google Form or a website popup can work well to gather opinions in a structured manner. Similarly, a word of encouragement to send thoughts at the bottom of an email can be effective. 

There are also applications such as Userback, which gather feedback from logged in users (such as staff) by enabling them to add private annotations to the live site.

Run a staff ideation session 

The gold standard for taking feature requests is the well-facilitated ideation session. Sticky notes and whiteboards are a great way to generate ideas and to encourage participation. But be wary of an unmoderated venting session in which people present a wishlist of things they want to change, which can be demoralizing and dominated by a small number of loud voices. A structured discussion that keeps things positive and brings in evidence for change is best. 

Try a templated approach, like the Lightning Decision Jam, if you aren’t sure where to start.

A&J Smart’s Lightning Decision Jam in Miro

Use the right tool to organize requests 

As new requests come in, how will you organize them? Can they be combined with existing work to be done? The product backlog is a collection of “things to do” that is typically owned by a project manager or product manager and housed in an app like Trello or Asana. Staying on top of the backlog requires regular revision and culling to keep it from spiraling out of control. 

Prioritize requests in a matrix

The principle of the backlog is that when someone finishes a job they grab the next task on the list and get started. But how do you decide which requests filter to the top of the pile? A well established approach for deciding is a priority matrix, in which requests are placed on a 2x2 grid according to the ease with which they can be delivered and the impact they will have on the organization. 

Anything easy to do that will have a big impact (Quadrant 1) should be top of the list, while any low-impact, resource-intensive work should be canned (Quadrant 4). Requests in Quadrant 2 or 3 should be investigated further using lean experiments to validate their value.

Remember though, impact can be defined in many ways. In this case, the question is “will it get us closer to our OKRs?”

Use the dot voting method 

Still not sure where to start? One excellent (and neutral) way of getting agreement between team members is to use the “dot voting” method. On a real or virtual whiteboard, display your requests alongside context about the user problem they solve. Then invite stakeholders to vote using dots. Each person gets three dots to place next to what they think is most important to start on, and the tasks with the most dots win.

Make review part of your innovation process

Review the backlog and current state of strategic goals on a regular basis. It’s best to make a plan to sit down with key stakeholders on a fixed schedule and stick to it. During these reviews, consider: is something more pressing in light of new information? Have you learned something about a low priority request that means you need to re-evaluate it for impact or time? Is there more information about a competitor’s strategy that needs to be taken into account?

TERMS

Definitions for product terms referenced in this guide are sourced from NPA’s crowd-sourced product glossary

Backlog

A list of the bug fixes, new features, changes to current features, systematic overhauls, or other development items a team is working on. These are often prioritized internally based on needs or resources.

Kanban

A workflow management style that prioritizes efficiency and continual delivery, over fixed releases of product. Tasks are placed in columns like Not Yet Started, In Research, In Design, In Development, In Review, or Completed to show work in progress.

Objectives and key results, OKRs

A goal-setting framework that describes what you want to achieve and how to do so. These can also be used to create linked goals, i.e. Objective: Increase newsletter engagement → Key result: Increase click-through rate from 3% to 6% by 1-year mark

RELATED READINGS / RESOURCES

How to prioritize feature requests - Product Marketing Alliance

A brief overview of planning poker - Atlassian

The hypothesis prioritization canvas - Jeff Gothelf

ABOUT THE AUTHOR

Adam Oxford

Over the last 25 years, Adam Oxford has worked as a journalist, editor, entrepreneur, trainer, manager and consultant for dozens of news media organizations in the UK and South Africa. Outside of that, he also ran a startup programme for social impact entrepreneurs in the legal and justice sector for seven years. He currently divides his time between helping small publishers with digital transformation and audience analytics, and working with civic tech organization OpenUp on media-related projects including the Africa Data Hub.