Let’s face it – 99% of the ideas that vie for space in your backlog are, to one degree or another, just rubbish. Product managers often have to look for the remaining 1% of good ideas, and then, due to limited resources, choose only the best ones. This means they often have to say no …
Over the past few years, I’ve realized that many of the arguments for adding new features are fundamentally wrong. They are flawed and can seriously harm a product and influence a company’s decision making and agility for many years. Below are examples of the worst arguments I’ve heard.
“But our competitors have it.”
It’s good to keep track of your competitors, measure their movements and learn from them. Get inspired by other people’s ideas, but don’t blindly copy everything they do.
Chances are, their audience is different from yours, and they may have a different vision of the product. Perhaps the function you want to copy is not working at all and they are planning to remove it. Companies that only copy competitors are always one step behind.
“The sales team needs it …”
Regardless of who requested a new feature, sales team, support team or boss, your answer should be no unless a 90% revenue customer or your sales team are real experts in product planning, strategy, and drawing up road maps.
Upcoming Workshops
By the way, have you noticed that an auto seller always sells what he has in stock (unless you are Elon Musk), while a seller from a software company always sells what they don’t have?
“It only takes a few hours to create this feature.”
Nothing is as simple as it seems at the beginning. Even when I face scheduling error and general misjudgment of projects, any feature still brings new complexity and service requirements in the future.
The scale of the work should never be the main argument for creating something, and therefore, in this case, your answer should also be “no”.
“We can make it optional”
This argument is often voiced when we discuss a function that is useful for one group of clients, but at the same time harmful for another.
Understand that this feature will double the complexity of the product… From now on, you always have to think about both scenarios. Your product will start living a double life and you will receive requests to make both use cases even better and more differentiated. If your budget and resources are not limitless, think twice before settling for any “optional feature”.
“This has been in our backlog since last year.”
“Times change,” user needs change, and so does your product and your competitors. It is difficult to create a feature-oriented roadmap for years or even months in advance when you don’t have all the necessary and up-to-date data.
Rather than pulling a task out of your backlog, I recommend creating a strategy document focused on topics and goals (more). Don’t mistake the backlog or roadmap for unbreakable dogmas, and always question them. Also remember that a good backlog needs to be prepared, organized, and updated.
“We have nothing more planned”
Making a feature just to keep your developers busy will always do more harm than good. These features are usually prepared in a hurry, poorly thought out, and poorly designed. Ultimately, they always introduce additional complexity and technical debt into your code.
Instead of doing something new, you can use the extra time to pay off your existing tech debt. Discuss the best “candidates” for refactoring with the developers. What will improve their speed, code quality, or reliability? You can be sure that the developers will have a lot of work to do.
“If we don’t create it, then someone else will do it.”
This argument often comes with the idea of vertical or horizontal expansion. While there is nothing wrong with expanding your product line or expanding to another segment, you will most likely find success by focusing on your core business. You can always think of a way to make something better, cheaper, or faster and improve your core product.
Your product is designed to solve a specific problem, which is why your customers love and use it. This is what you should stick to, even thinking about new ideas and features.
No customer or stakeholder should be more important than a great product and the rest of its users. Allow yourself to say NO without feeling guilty, mean, or selfish. It’s your job to look at the product from a broader angle, prioritize and choose the right place for improvement, optimization, or a completely new feature.
As Warren Buffett said, the difference between successful and highly successful people is that very successful people say no to almost everyone…
