How Not To Propose a Feature to Product Managers

Product managers are often pinged with feature requests and what grave consequences it might have if they're not listening. Don't be the one to propose something without evidence.

Photo by Ben White on Unsplash

There are many memes about the busy life of product managers. Some highlight what different people think they do; others make fun of how dangerously they like to live if they ship a feature without proper user testing.

One aspect that is usually not mentioned in these memes is how often product professionals are bombarded with ideas and feature requests.

Saying “no” is one of the superpowers product managers need to master to keep their product focused.

But they don’t have an easy job.

Sales, marketing, and other departments are constantly competing for the attention of product teams. At times, they all try to prove that their request is the most important and the utmost urgent.

In this article, I’m trying to shed light on all the wrong reasons stakeholders use to sell an idea to product managers. Some are misinformed, others are deceptive, but they all have one thing in common: they lack evidence.

---

From CEO requests to uncommitted promises

“The competition already has this feature; we should also do this”

Some of the requests are centered around the competition, and for many reasons, it makes sense. Maybe the competition has already achieved something that we would like to, or they’re actively nurturing a cash cow.

One important fact to remember here: no products are the same. While one thing might work for one company, it might not work for the other. Instead of pointing to a specific competitor or feature, product managers must understand the underlying problem first. After this is done, only then can the discussions begin about how relevant it really is and with what priority it should be addressed — if it should be addressed at all.

“This request came straight from the CEO”

Another classic reason for pushing features ahead is that it comes from a higher authority. While product people should respect their managers, it doesn’t mean that they should follow them blindly.

If someone from the senior management brings a feature to the table, they might have valid reasons. One of the common examples is when they know something that we don’t, like a new market opportunity. Here, product managers should listen first and try to get as much information as possible before making a judgment. If the data still does not add up, product owners would be right to challenge the request.

“A lot of clients want this feature already”

Pressure from sales to deliver new capabilities is not a new thing. They’re the ones out in the fields, constantly speaking to a diverse group of clients and trying to engage potential leads.

While performance bonuses often strengthen salespeople's motivation to push something through, well-prepared product professionals should be prepared to be factual. When talking about feature requests, product managers should quantify the impact of a new capability. When a new request comes in that mentions “a lot of clients,” sales should be able to list those customers. Beyond that, the forecasted revenue impact can also be compared to other product priorities.

“We need to do it by next week”

In product management, urgency is always present in some form or another. Everybody would love to get their things done as fast as possible, and in the case of requirements, this pressure is usually put on product managers.

There are many places urgency can originate from, and the first step should be to understand its source and the reasons behind it. Once product managers have that, they should check who the user is, what the problem is, and the potential value an urgent development would create. If they have all these, they can start comparing them to their team's items and if it would be worth dropping something in exchange.

“There are no workarounds here; it’s legal compliance”

Some people say legal is a necessary evil when it comes to product management. Even if a product works flawlessly, being compliant with local and international regulations is necessary for business sustainability.

The moment when we arrive at the gray area is when we talk about the interpretation of laws. While product professionals should also take compliance seriously, rules can be interpreted in many different ways; just look at cookie tracking. When product managers are asked to make changes in their products for legal reasons, they should always ask back for clarification. Also, what would be the fine if the company is not compliant? The same goes for security. There are risks and chances of reputational/financial loss, but the initial problem should always be known, as with every other feature request.

“We already promised this for the customer”

If the sales organization is promising features that are not existing yet, it’s either a questionable corporate strategy or a serious misalignment between sales and product development.

People use a product for what it’s capable of today and not for its future roadmap. If there was a promise without proper commitment, then the person making the pledge should be held responsible. In exchange, if product managers commit to something, it’s like a bonding blood contract that they would be willing to fight for.

In general, under-promising and over-delivering is a better overall strategy than the other way around. Imagine if you’re ordering pizza, and the application says it’ll arrive in ten minutes. After then, how satisfied would you be when it gets delivered after half an hour?

“We need to refactor this code, and it will take some time”

By a popular definition, product management is at the intersection of customers, technology, and business. Beyond creating value for customers, product managers also need to care about a solution's technology aspect.

For products already on the market for some time, developers are rightfully raising the topic of code rewrites. A technological approach that seemed popular five years ago might not stand the test of time today. Product managers should approach this topic with the same principles as the others: what value would this change bring? If it’s something that would speed up future developments, then it could be a worthy investment. On the other hand, if a refactor is just making some code prettier used by only a few customers, it might not be worth the effort.

“Hey product buddy, I would need your help”

One team alone is not always enough to deliver a shiny new feature in a scaled R&D organization. Product and engineering teams need to work together, and a request can easily come in from another product colleague.

Here, product managers don’t have an easy choice. Should they help another team reach their goal, or should they focus on their own initiatives instead? Or a little bit of both? To answer this question, product owners need to see context and raise their viewpoint from product-level to platform-level. If they consider the two competing initiatives, which would have a bigger impact? Theoretically, it’s easy to answer; practically, it’s often hard to quantify. If a conclusion cannot be reached, the simplest thing is to ask the first common manager to choose, supposing they have adequate knowledge of the situation.

---

The conclusion: how to get over false justifications?

From worshiping the competition for a particular feature to assuming that another request is the dream of all customers, there are many ways to try to sell an idea.

To spot false justifications, product managers should consider the following:

• Ask about the problem itself, instead of hearing a solution idea.
  In many cases, someone already experienced the problem first-hand and thought of different ideas to solve it. But instead of telling the original problem, often a pre-selected solution is presented.

• Clarify the details and quantify the numbers as much as possible.
  Hazy details and exaggerated numbers don’t help the product manager’s job. When inquiring about further details, make sure that there is a reasonable effort put into providing a factual response.

• Consider the level of confidence based on the reversibility of the idea.
  First, recognize the effort needed to test a hypothesis and how reversible the development would be if it turns out to be totally wrong. Then, consider if it matches with the required level of confidence.

Remember, it’s mostly about creating value. If you don’t know the reason why you’re working on something or don’t see any value in it, something is off.