Product manager diary: Learning to work with vendors and development teams outside of your organization
How do you balance clear communication, changing needs, decisions that predate you—in the midst of a million support tickets?
This year has been my first as a product manager in a newsroom, after working in editorial and engagement roles as a student and early-career journalist. The most challenging parts of product work feel similar to the newsroom and yet completely different at the same time. A big focus over the last year has been identifying how the skills I already have fit into my organization, and where I need to build up skills after getting to know what the day-to-day work on a product team looks like.
One thing I’ve spent a lot of time doing is working with vendors and developers to provide technology for products like a mobile app, push notifications, donation tools and an events calendar content management system. Learning to communicate with these teams effectively has been crucial, especially in a startup newsroom.
If you’ve ever been the primary point of contact for relationships with vendors or development teams who don’t directly sit within your news organization, you know the feeling when…
…at any given time, you’re staring at a million support tickets.
Someone created one yesterday, you made one last week, some started several months ago and they’re still marked ‘open.’ Some may even involve support threads with another vendor or team outside your organization.
…there’s more history than you know—on both sides.
A team member who is no longer involved made something a year ago that a new developer has to learn now. There’s an old workaround to avoid a platform that the organization now has access to. A decision was made by someone who is no longer with the organization. In any scenario, there’s history on both sides that still influences the work.
…teams on both sides are growing, shrinking, and changing.
Teammates come and go, an organization’s needs change, restructuring occurs, and new priorities influence the working relationship. New faces join meetings, and others depart or become less present.
…a member of one team doesn’t entirely understand the other team’s scope.
Most people never have a complete picture of how the other side works—whether it be their product, environment, value add, or processes. This leads to assumptions or misunderstandings.
…a technical team member doesn’t fully understand the news value.
Maybe a vendor is building their expertise in news media, or a team member is new to working in it. Either way, the use case for the technology needs to be translated.
…a team member doesn’t entirely understand the technical implications of a proposal.
They may have limited knowledge of code-heavy work they’re involved with, which makes it harder to understand the time or process another team needs to get the work done.
Figuring out what works and where to improve
In the past year, I’ve been in every scenario above, and more than once I’ve been the team member mentioned. Some of these situations have been completely new to me, but I’ve been able to reference strategies I learned in an online product management course I took before starting my role, and from resources like the News Product Alliance’s Resource Library or articles on Source.
Many of these struggles are expected in a growing organization, or when working between teams. These are ways I’ve learned to manage them that feel helpful no matter where you are on the org chart:
Communicate exactly what you want the other team to do
Out of the million ongoing and new support tickets, regularly point out which ones are a priority and which ones can wait. When bringing up a new issue, communicate whether you’re looking for the other team to fully solve the problem or just help you find the next step. If you’re referencing documentation, send the link. Clearly speak the need from your side, and just as clearly express what you’re looking for from the other side.
Tell the background story in a few different ways
It’s easy to run to the other team with a narrow request to make communication quick, but sometimes it helps to go further. For the other team to better understand the functionality you’re trying to deliver, find different ways to loop them in and illustrate your organization’s “why.” Take a few extra minutes to tell them the user journey, use case, and question you’re trying to solve. Name exactly the expected or unexpected behavior and, of course, include prior communication. When relevant, explain the decisions that went into how a product, feature, or project reached a certain point. This can help avoid assumptions or misunderstandings, and help the other team bring in another member to support you if needed.
Be as clear as possible about your organization’s priorities
Use your regular meetings to explain changing roles and introduce new faces or priorities. Let vendors and development teams know what’s uncertain or still being figured out, and what information they can provide to help you make internal decisions. This can help explain why something that was a focus in last week’s meeting may no longer be, and relays a “heads up” for questions you may be asking down the road.
Ask for feedback and suggestions
This one is specifically for working with vendors – you don’t have to have completely figured out how your organization will use a new product. Sometimes sharing product observations or early-stage ideas can lead to fruitful suggestions for meeting your goals. This can apply to implementation, too, in asking for review or feedback on the execution of a feature from a vendor’s product. They’ve seen successes and use cases in how other organizations have used their product, which can be helpful to you, too.
Keep artifacts from the other team on hand
Everyone knows the importance of writing documentation for your newsroom’s internal users, but one of the most useful artifacts I’ve shared with my team was a simplified map of a vendor’s systems architecture that I pulled from their website. It was an ah-ha moment for colleagues across my organization whose work sometimes crossed into different parts of the system.
Be curious about the other team!
Ask where they are in their growth, what their organizational structure is like, and how their product roadmap works. Ask how a service or feature came into being. Learn the backgrounds of your most frequent collaborators. Try to ask them similar questions as they’re asking you: “Is there anything else from your side I should know about?” may provide you with information about a new feature they’re working on that you wouldn’t otherwise have known about!
Learn the language of their software
As much as is within reach, learn the terminology for components and the environment of the software the other team is working on for your organization. You don’t need to learn how to make your own deployments, but it can go a long way to ask a support engineer to explain their issue diagnosis, ask ChatGPT to breakdown new terms you’re encountering, or even ask someone from the other team to spend 30 minutes explaining part of their backend to you.
I’m early in this part of my career, and I know that I still have skills to grow in communicating effectively with other teams. Last year, when building my skillset to become a product manager, I knew about product management’s role in propelling a news organization’s roadmap. Still, I needed to learn more about the language and processes of the work involved, so I took an online product management course prior to starting my role. It helped greatly in bridging some knowledge gaps essential to my role – like learning how to write a user story, story pointing to create development estimates, and templates for organizing a JIRA board – and allowed me to easily jump into my new work with tools and terms in hand.
This year, I’m taking the same approach to increase my knowledge of the fundamentals of web development—I’m enrolled in a boot camp because I want to better understand the technical trade-offs of work I am a part of and to communicate more precisely with vendors and development teams. I hope it will have the same effect in equipping me with the terminology, frameworks, and standards of programming, so I can collaborate with vendor and developer teams with a better picture of the execution of the work we’re sharing. By the end, I want to be able to make more “quick fixes” to our organization’s web products on my own, and be able to take a more active role in problem-solving and strategy from our business, editorial, and engineering perspectives.
I’ll be back here in a few months to share with you how it goes.