Partnerships are core to our business here at Zapier: we have thousands of app partners and are growing daily. We’re fortunate to work with all these partners—and to have a fantastic product team to help support them.

But depending on how your company is structured, your product team (or teams!) might be juggling several different projects at once—everything from process improvements to new features to bug fixes. Getting your project prioritized and added to the product roadmap can be challenging if you’re not on the product team.

As a partnerships specialist on Zapier’s marketing team, I want to make sure our partners are well supported, and that means helping them build integrations and supporting them with new features. From my experience working in partnerships, here are four tips I’ve found helpful in influencing a product roadmap.

1. Learn about the product team’s goals 

Ideally, every team’s goals will ladder up to company goals, but that doesn’t mean they’re always perfectly aligned. It’s important to start by learning about your product team’s unique set of goals or KPIs to determine how and where there is overlap.

Use this information to determine how to position and prioritize projects in a mutually beneficial way. For example, if you work for a SaaS company, and usage is one of your product team’s KPIs, you’d emphasize the aspects of your project that would increase usage. Mentioning those keywords in a project proposal will make it better heard and help foster a positive cross-functional relationship between teams.

In addition to knowing their goals, you’ll want to be kept in the loop. Keep open lines of communication, and learn as much as you can about how the product team works. For example:

  • Have regularly scheduled meetings with your product team, so you’re always up-to-date on what they’re working on. You never know when something new will mesh with a project that you’d like to prioritize.

  • Review their documentation so you can understand their processes for working on new projects. That way, you can work within their systems, and they’ll feel more comfortable with your proposals.

  • Be aware of the product team’s backlog and bandwidth for new projects. Putting pressure on a team that’s already inundated with high-priority work can leave a bad taste in their mouth.

2. Let customers help you make your case 

Every product team wants to provide the best possible experience for customers. So if you can show them that your project will contribute to a positive user experience, they’re much more likely to get on board.

There are lots of ways to do this, but one of the easiest is to go through your customer support tool and social media mentions. Log any requests or themes related to your project. Another option is to send out a survey or conduct user interviews, but you likely already have the feedback you need in the tools you already use.

Once you have the anecdotal evidence that users want what you’re proposing, compile this information into a more digestible form. Include some actual examples, but also support it with numbers (e.g., X users requested this feature in the past 6 months).

An example of showing user feedback in a project scoping doc
Here’s an example of a doc we compiled showing how a lot of our customers were requesting a specific Airtable trigger on Zapier. We got that feature on the roadmap!

This will help convince them that they’d be working on something that would have a direct impact on customers—which is always a win for product teams. 

P.S. If you have any other historical evidence that projects like this one have been successful, definitely include that too.

3. Scope out the project 

Take some of the work off the product team’s plate by doing an initial scoping of the project. You won’t be able to get hyper-specific (and you don’t want to come off as presumptuous!), but giving them a sense of how involved the project might be will help them contextualize the request better.

Instead of a Slack message or email making your initial request, go in prepared: provide a summary document that includes any resources needed to clarify the project’s scope. Here’s what I recommend you include in that doc:

  • A one- or two-sentence summary of the project

  • The goals of the project (and how they align with the product team’s goals)

  • The why behind the project (including information from the previous tip)

  • The expected output from the product team

  • The expected level of effort (even on a simple scale of 1-10) 

Send this document out, along with an invitation to a meeting where you can present more of the nuances of the project. (And before you do, check out these tips for running a product meeting when you’re not a PM.)

4. Think outside of the box

It’s easy to write off projects as “just a small feature” or “just a tweak in functionality.” So try to position your project outside those normal bounds. Here are a few ideas:

  • Compare your product to a competitor’s, and show how your project would help set you apart.

  • Angle your project toward brand-building. Sure, it might be a small tweak in terms of the product, but it could be marketed in a way that has a big impact.

  • Position the project as future-thinking: how will this lay the foundation for more significant changes down the road?

Since you’re not a product manager, you bring a unique perspective to the conversation. Leverage that perspective to highlight the value of your project.


When pitching your project, remember that there are tons of competing priorities. It’s up to you to convince everyone that your project deserves a spot on the roadmap. In the end, everyone wants to be sure the most impactful projects are prioritized, so if you can demonstrate that your request will move the needle, you’ll have a fighting chance.

Source link

[adsanity_group align=’alignnone’ num_ads=1 num_columns=1 group_ids=’15192′]

Need Any Technology Assistance? Call Pursho @ 0731-6725516