Back

How to manage stakeholders in the newsroom context

News product teams need to deal with different areas, priorities and realities in a news organization. This tug of war can be challenging when managing expectations and concerns. Learn how news product professionals can better involve and manage stakeholders while delivering effective results.

managing stakeholders

INTRODUCTION

Your stakeholders typically rely on the work your team does in order to accomplish their own department’s mission – so it’s no surprise that they may have strong opinions about what’s most important for your team to prioritize. 

In the newsroom context, internal stakeholder groups frequently include the following: 

  • Assignment editors, who may want your team to contribute to a news project or story
  • Writers, photographers or videographers, who utilize your product to get their own reporting work done
  • Advertising departments, who want to ensure content is monetized appropriately
  • Revenue officers, who want to grow your publication’s subscriber base
  • Engineering teams, who want to ensure the product is performant and scalable
  • Company executives, who want a clear picture of how your product team advances the company’s overall mission 

Balancing the disparate needs of these different stakeholder groups – and also advocating for the best interest of your ultimate end-user, typically the reader – is one of the central challenges of product management. But involving your stakeholders in the product process and leveraging their expertise will ultimately ensure you solve the right problems, so it’s crucial to manage these partnerships well. This guide outlines steps and techniques to involve stakeholders in the product process and manage competing priorities. 

IN PRACTICE

Identify key stakeholder SMEs 

You likely have a clear picture of the groups of stakeholders who are invested in your product. But if you’re experiencing a flood of requests coming from a certain group with no clear owner, it’s helpful to recruit a colleague to act as a subject-matter expert (SME) stakeholder on the group’s behalf.

For example, if both photographers and copy editors rely on your product and each group’s requests tend to follow similar patterns based on the different types of work they do, it might be appropriate to recruit one person from the photography department and one person from the copy editing department to act as stakeholder SMEs. People who frequently pitch new ideas or give you product feedback are great candidates for an SME – if no one immediately comes to mind, ask the department head for recommendations. 

Your stakeholder SMEs can help to gather, consolidate and prioritize requests. This can be a leadership opportunity for the stakeholder and give them a chance to gain expertise in technology projects and the product management process. 

Later on, if you need to conduct user research with that group, your stakeholder SME can help recruit participants. If you introduce a new capability into the product, your stakeholder SME can plan for training and gather feedback. When you have roadmap review sessions, your stakeholder SME can share relevant updates back to their wider team. This level of involvement can be significant for the SME, so it should be formally arranged with their manager so their workload can be managed. But it’s more efficient and effective to have one strong, dedicated voice to represent the department’s needs rather than having dozens of department members who are minimally involved.

Define and publicize the vision 

Crafting a product vision can be surprisingly tricky, especially if stakeholders have different views about the direction you should be heading in. But holding those tough conversations now will help clarify prioritization decisions later on. 

A writing or journalistic background comes in handy here – you want the vision to be clear and succinct. It should inspire both your stakeholders and your own team. And the product vision is of no value if your stakeholders don’t know what it is – refer to it often in conversations with stakeholders, and put it on a central, internal landing page for your product. This page can later include links to key artifacts like your team’s roadmap, so the information is easy for your stakeholders to find and refer back to. 

In addition to an overarching product vision, you may want to explore writing (and socializing) shorter-term objectives and key results (OKRs). These typically describe specific goals you want to accomplish within a quarter or a calendar year, and help align stakeholders around near-term plans.

Involve stakeholders in prioritization

A value-complexity matrix visualizes features alongside an axis of complexity vs. value (Source: Reforge)

It’s important that your stakeholders understand the constraints you’re operating under – whether you’re leading an engineering scrum team and plan your work in sprints, or you’re leading an editorial design team that responds to requests for visual assets, you’re working with a fixed capacity – and you won’t be able to say yes to every request. 

If you’re getting a significant amount of requests from a stakeholder group, one helpful exercise that can bring them into the prioritization process is Value-Complexity Mapping. Have your stakeholder partners rank their requests along the axis of most to least valuable to them, and your engineering team (or whoever would implement the requests) ranks the requests on the complexity axis. This can help visualize what the most impactful items might be – those that land in the high-value, low-complexity quadrant should be prioritized higher than those that land in the low-value, high-complexity quadrant.

Once you’ve prioritized requests from one stakeholder group, surfacing the highest value requests to the other stakeholders can give you valuable feedback about what might be beneficial to them as well. Additionally, the Buy-a-Feature exercise can help encourage stakeholders to prioritize based on limited constraints. In this game, you assign a “price” to new features being considered for your roadmap (typically based on how complex they are – the functionality that will take the longest to complete is the most expensive). Then, you give your stakeholders tokens (like pennies or candies) and ask them to buy the features that they find most valuable. The discussion between stakeholders can be as informative as the final list they choose to purchase – do they negotiate to pool resources towards one expensive feature, or make trade-offs amongst themselves? 

These prioritization exercises can help identify what you work on first, but you still won’t be able to tackle all of the requests at once – and some will never happen. Be realistic with your stakeholders about what you can say yes to, and what you can’t. If a stakeholder is depending on a certain new capability that ultimately doesn’t align to your product’s vision or that you don’t have capacity to address, letting them know sooner rather than later will help build and keep trust. They may need to find an alternate solution or shuffle their own department’s plans, and the only thing worse than hearing “no” is getting false hope and then having to scramble at the last minute. 

Make your plan transparent

Roadmap illustration from the News Product Kit: ABCs of Product (Source: Miro)

Creating and sharing your team’s roadmap is the bread and butter of product management. Now that you’ve gathered and prioritized requests from your stakeholders, it’s critical to update them on your team’s progress and plans. 

Remember that your stakeholders are busy people and likely juggling as many ongoing projects as you are. Make it easy for them to find the info they need: 

  • Publish a roadmap in a place where stakeholders can bookmark it and refer to it later. 
  • Schedule a regular roadmap review with stakeholders where you demo recently completed features, update them about in-progress initiatives, and share the latest plans for what’s next.
  • Write a summary of the key updates and share with attendees so they can refer back to it later.

Share your learnings and progress 

A simple, internal-facing blog (like this one run by the UX Research team at ArcXP) can be a great method for sharing updates asynchronously with busy stakeholders.

You won’t be able to say yes to every request from every stakeholder. But sharing the results of what you have completed can be beneficial for all stakeholders – not just the one who made that request. 

An internal, informal blog or newsletter can be an excellent method to share what your team has recently learned or achieved. Product managers from a news background have an advantage here – the skills for writing an engaging, informative and memorable news story can be transferred to the act of summarizing key learnings from an A/B test or a round of user interviews with readers. These insights can help your stakeholders better understand the reader in unexpected ways that help their own work, and build buy-in for your product process. 

RELATED READINGS / RESOURCES

Defining your product mission and vision
https://newsproduct.org/product-kit/product-mission-and-vision

Mission vs. vision statements: definitions & examples
https://www.atlassian.com/work-management/strategic-planning/mission-and-vision

Backlog Prioritization Techniques: The Value vs. Effort Method
https://jexo.io/blog/backlog-prioritization-techniques-the-value-vs-effort/


About the author

Sara Carothers is a lead product manager for Arc XP, a content management and digital experience SaaS platform built by the Washington Post. She manages product lines that deliver customizable out-of-the-box components for media and enterprise websites, configured through a low-code interface. Previously, she was an editor for the Washington Post's mobile apps, and served in a hybrid digital producer/product manager role for its national politics desk. 

Share this

Share in your social media