When you’re spending every single day talking to the people who are buying your product, you’re in a position to truly understand them in a way that’s incredibly valuable for the whole company. 

And yet, you’ll hear frustrated sales people saying: 

“Why won’t the product team build what I’m asking for?”

We’re not here to tell you how to make that happen, exactly – but we do want to help you to make those conversations less frustrating.

That starts with an understanding of how someone from sales and someone from product might think differently. While you’re mostly focused on making your number for this month or this quarter and deals from 6 months ago are a hazy memory, a product manager can spend each day living with the results of decisions that were made since the product was built, and having those impact what they can do now. Like this example from Melissa Perri, it may even have been something that came from sales. So if there feels like a general resistance to build something on request, don’t take it personally – that likely has something to do with it.

Now, you might be thinking “but it’s just this simple thing, surely that’s no big deal” and this can lead to uttering those fateful words:

“It would be quick to build though!” 

Which feels like objection handling 101, but sadly has the opposite effect. 

The thing is, development is a bit of an iceberg. For the few lines of code to add that simple thing you can see, under the surface there’s much more work to do. You might need to involve a designer if it changes a UX flow. Then you need to go through testing. Then, you need to make sure the customer-facing teams know it’s coming, make sure you have it covered in your help documentation, and write it up in your release notes. Depending where it is, you might need to change screenshots or videos in your marketing materials too.

So by only considering the effort to actually build it, you’re only considering a small part of all the work that needs to be done.

And since there’s a universal law that says you can never have enough people or hours in the day to build everything you want, the list of what does get built is always the subject of ruthless prioritisation and with a thousand other ‘quick wins’ waiting in the wings, something being simple or small isn’t going to earn it a spot.

So what does?

Well, you know how you hear people say “don’t bring me problems, bring me solutions”?

This is where you do the opposite. 

Unless you’re in a professional services or custom software company, the aim is to build the thing that solves the most important problem to the majority of your target market. To do that, you can’t just compare features, or solutions. “Should we build X, or Y” often leads to comparing apples and oranges. You have to take it back to the why, and the who. 

What impact does this have for which customers? 

Let’s look at an example:

“We need to add a kanban view” is all about the solution.

“Development teams are looking for a way to visualise work in progress” tells you who is asking, and what they are trying to achieve. What if it happened that there was already a different method of visualising work in progress that’s in an upcoming release? If you came asking for kanban view and didn’t say who wanted it and what for, they might not be able to say “hey actually there’s a chance we’ll solve that problem in a different way” and now, you don’t even have to fight to get your request put on the list!

While it doesn’t always work out that way, you’ll always have more valuable conversations and build a better relationship with the product team that will serve you better in the long term than if you managed to get one thing added to the roadmap for that one deal.