How to Persuade Your Company’s Product Team to Build Something

So you want your company’s product team to build an internal tool or piece of software.

If you aren’t on the product team—let’s say you work in sales or marketing—making the ask can be intimidating. You might not know the technical details of the feature you’re requesting or who to approach with your request.

While working at companies like Quartz, Facebook, Google, and Microsoft, I’ve been on both sides of this process. I’ve been on the business side, giving feedback to product and design teams about a new piece of software, and I have been on the product side, receiving that feedback. I can tell you: It’s hard to convince a bunch of other people to spend dozens of hours of their time building something for you.

Here is how to make sure your requests for the product managers, engineers, designers, and data scientists with whom you work get built and not ignored.

Start with the problem, not the solution

Many feature requests start like this: Someone casually throws out a “simple” feature idea that would take a long time to build, with little evidence of need, and then smiles proudly for thinking of it. He says something along the lines of, “You know, you guys should just build customer service chat so we can talk to people directly. X company has it. Can you do that?”

From the product team’s perspective, this request style makes it seem as though you think building a product is so easy that all it takes 10 seconds of business ingenuity to identify the solution.

On top of being a bit insulting to the product team, starting with a preconceived solution is the perfect way to end up with something that introduces further problems.

You should start by describing the problem, not only because is it a more collaborative exercise, but also because it’s likely that your conception of the technical solution isn’t going to be the best one. And that’s okay. That’s not what you’re paid to do—it’s why the engineers, designers and product managers at your company are there. Explaining the problem that needs to be solved is helpful enough.

Here’s an example of how to focus on the problem instead of defining a solution:

Hey! The marketing team has noticed that a lot of people are discovering our website through search and online advertising, but no one is buying anything. We always have a ton of emails from people asking very specific questions, but by the time we respond to them, many never get back to us, or they say they’ve gone with a competitor.

We think that if we have some way to communicate back-and-forth with users more quickly, we’ll be able to keep these people engaged and answer their questions, and convert more sales.

Identify the users

The product team needs to understand the specific needs of the type of person who will use the feature in order to build a useful solution.

For example, a data dashboard should look very different if the intended user is the CEO (who needs very general company metrics, like the number of daily users or sales) than if the intended user is an account manager (who needs detailed filters for specific deals, clients, or regions). The required level of polish will also be different.

Here’s an example of how to appropriately define an audience:

The chat platform would be used by our existing customer support team of 6. That team would log in and answer people’s questions, and every person on the team would take a shift.

Be specific about how the feature will be used

Be explicit about what the users of this feature will want from it. If the sales team needs a dashboard just so it can see general revenue numbers, explain that. You may save the product team from building fancy visualization graphs and custom date-range features that the sales team doesn’t really need.

This goes the other way as well. If you’re not upfront with all of your needs and those needs end up trickling out after-the-fact (“Why can’t I export this to Excel?”), you may find it difficult to get the product team to build something else for you again.

Here is an example of how to appropriately define needs:

The queries we get are mainly pricing questions or technical integration questions that are handled by our solutions engineers. So not only do we need to chat with customers, we need the ability to pass a customer’s chat conversation off to another person internally. And we only need to be able to communicate via chat. We don’t need screenshots or voice calling or anything fancy like that.

Also, some of our clients are in Europe, which means we need answer messages early in the morning, and it would help if our support staff was able to respond to messages on their phones and not just their desktop computers.

Data, data, data

The more things you can quantify, the better—honestly, I have yet to see a feature request with too much data.

Saying something like, “70% of our support email conversations have more than 15 back-and-forth messages” helps the product team know that the customer service chat needs to be able to support long, threaded conversations. Letting the product team know that “56% of our conversations require technical input from our solutions engineers” can emphasize how important it is to build the ability to easily assign in-progress chats to other employees.

Perhaps more importantly, data that gives a sense of impact (the size or business value of the problem) will increase the likelihood that your feature request is accepted. Just saying that a feature is “very important” or “critical” isn’t enough—product teams hear this all the time. People in product roles tend to value quantitative metrics over anecdotes, and making a compelling case with data will make your request stand out amongst the giant mountain of big requests and small bug fixes the product team is already balancing against their existing commitments.

Here is an example of how to incorporate data for both context and impact:

When we follow up with missed clients, on average five of them each month tell us that they didn’t sign on with us because we responded to their support email too slowly.

The average yearly revenue per client is $6,000. This feature could directly lead to a $360,000 increase in yearly revenue, just counting the people who have explicitly told us slow communication is the reason why they didn’t sign up with us.

When you do use anecdotes, focus on users’ frustrations and make them feel real

Unfortunately, not every company or team has great access to data. If you don’t have much to quantify, I would recommend telling detailed user stories that emphasize the various points of frustration and anxiety that are caused by the problem.

People in technical product-oriented jobs may seem egghead-y, but they often derive satisfaction from fixing things and solving people’s problems, particularly engineers and designers. If you start using full names, photos, and direct quotes of people that this product team is failing with their lack of a solution, the opportunity to improve users’ lives becomes very concrete.

Note that this strategy tends to work better with the actual builders (engineers, designers) than it does with product managers, who are a bit more cynical and wary of incoming proactive feature requests.

Tie your request to goals of the product team or company

Product teams have a set of clear, measurable goals. These are often assessed through directly measurable metrics like user growth, user engagement, and ads clicked, and the leaders of these teams are often under immense pressure to improve those metrics.

Showing how implementing your feature request will improve one of the product team’s goal metrics improves your case. Product team members are, like everybody else, trying to do well on their performance reviews, make their bosses happy, and get raises.

If you can’t tie your request to the product team’s goals, the next best thing is to tie them to the top-level company goals. It’s hard to argue with a feature’s importance if you can make the case that it directly impacts one of the company’s fundamental goals.

Here is an example of how to incorporate the product team’s goals.

I know one of the product team’s goals this quarter is improving the percentage of people who visit the website that buy something. I think implementing this customer support chat feature would directly impact that goal, as well as help us acquire new customers, which you know our CEO said was the company’s major focus this quarter.

Google around for 30 minutes

While you may not be a software engineer, it’s worth taking a few minutes to mimic one of their best skills: Googling. Reading through resources and applying them to their own tasks is part of a developer’s job. You should tap into that knowledge too—here are a few specific things that would be worth Googling before making a request:

1. Development: Across platforms like Medium, Quora, Stack Overflow (a Quora for programming questions), you can find in-depth yet accessible answers to questions such as, “how to build customer service chat for website” or “how long does it take to build user login.” Some of the articles will be highly technical, but skimming a few can help you appreciate the level of complexity required, understand some of the tradeoffs in implementation, and cite relevant resources that map to the feature you want to the product team.
2. Design and strategy: Aside from the purely technical side, Googling “customer service chat best practices” returns countless design, user experience and strategy-oriented articles and blog posts. Go through the first two pages of search results and document your learnings. This will infuse your feature request with industry best practices, and also just increase your knowledge about the right things to think about with respect to that feature.

Here is an example of how to incorporate your research:

I found a few blog posts that discuss building a customer chat platform from scratch, and I’ve included the links. I also found an interesting design article about the common UX challenges of customer service chat platforms, which might be relevant. The general consensus seems to be that it’s best to use an existing provider, because it would take several engineers quite a while to build a live, instantaneous platform from scratch.

Look for companies that provide the feature as a service

For almost any feature, there will be several companies offering a product that you can use for a monthly fee. There are entire websites dedicated to looking at which of these products well-known companies are using. For example, Spotify uses Sendgrid for email management, Optimizely for A/B testing, Qualaroo for in-app surveys, and Salesforce Desk for their customer support chat. For bigger features, I would highly recommend Googling “best ___ companies” or “top _____ provider reviews” and doing some research on the companies in the space. Even if you end up building your own version of the feature, you’ll look much more informed and you’ll know what parts of the feature are most valuable.

Here is an example of how to recommend a product as a solution:

I did some research on some companies that offer customer service chat as a service. Intercom and Zendesk are two of the biggest. Zendesk takes feedback and puts it in tickets that customer service people can pick up, whereas Intercom is more chat-based. They both have free trials, so we could see if they meet our needs without paying a lot upfront.

Get product team stakeholders’ approval

The quickest way to get something prioritized in a product roadmap is to go to the top.

One tactic for doing that is getting an executive on your team to convey the request and its importance to the lead product team stakeholder. Almost as a defense mechanism against potential distractions, engineering teams are much more receptive to working on tasks for other teams when the requests are coming from someone on their own team.

Pro tip: learn when the product team’s roadmap planning happens, and make this meeting happen then—you’ll be able to slot your feature in as a part of their plans from the get-go.

Here is an example of a request made with stakeholders’ approval:

I recently chatted about this with Sarah, your VP of Product. I was in a meeting with her and Michael, my boss on the Sales team, and she agreed that this was a major issue. She noted that there might be bandwidth on your team later this month to tackle this. So I wanted to follow up on this with you.

Understand that this will take some effort

If you expect multiple people to spend dozens of hours working on your feature rather than all of the other stuff they had planned to do, your feature request pitch had better be long and thorough. If you find that putting together the request is too much work, perhaps you should reconsider if this feature is really something you need.

If it you do make the request, going through the process of making it effectively will make you a better employee. As more companies emphasize technology and data, a business person who can convince technical stakeholders to build things is extremely valuable.