The worst arguments for building a new feature
Let’s face it — 99% of product ideas that compete for a place in your backlog are more or less rubbish. As product managers, we often have to find the 1% of good ideas and then choose only the best of them because of limited resources. This means saying “no” a lot...
In the past few years, I’ve realized that many arguments for building features are fundamentally wrong. They come with argumentation fallacies, and they can seriously damage the product and affect the decision making of an organization and its flexibility for years. Here are the worst arguments I’ve heard.
“But our competitors have it, too.”
It’s good to monitor your competition. Evaluate their moves and learn from them. Get inspired by the ideas here and there but do not blindly copy everything they do.
They most likely have a different audience than you, and they might have a different product vision. Maybe the feature that you want to copy doesn’t work at all and they plan to remove it. Companies that only copy competitors are always one step behind.
“Sales team needs it…”
Unless it’s a customer who generates 90% of your profit or your sales team is extremely familiar with the product vision, strategy and roadmap, your answer should be “no”, regardless of whether your sales team, support team or boss has asked for the feature.
By the way, have you noticed that the salesperson from a car dealer always sells what they have in stock (unless you’re Elon Musk), while a salesperson 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 encounter a planning fallacy and overall poor estimates in software projects, every feature still brings new complexity and a need for maintenance in the future.
The scope of the work should never be the main argument for building something and, therefore, your answer here should be “no” as well.
“We can make it optional.”
This argument is often brought to the table when we discuss a feature that would be beneficial for one group of customers but at the same time harmful to another group of customers.
Realize that every such feature will double the product complexity. From now on, you’ll always have to think of both scenarios. Your product will start living a double life, and you will be receiving requests to make both ways of usage even better and more differentiated. Unless your budget and resources are limitless, think twice before agreeing to any “optional feature”.
“It has been in our backlog since last year.”
“Times they are a-changin’”, user needs are changing and so are your product and your competitors. It’s hard to build a feature-oriented roadmap for years or even months ahead when you don’t have all the necessary data and the freshest inputs.
Instead of plucking something out of your backlog, I recommend creating a strategic theme- and goal-oriented document (more). Don’t take your backlog or roadmap dogmatically, and always question it. Also remember that a good backlog should be groomed, organized and up-to-date.
“We have nothing else planned.”
Building a feature just to keep your developers busy always causes more harm than good. These kinds of features are usually prepared in a rush, aren’t well-thought-out and are poorly designed. Ultimately, they always bring extra complexity and technical debt to your code.
Instead of making something new, you might use the extra time to pay off your technical debt. Discuss the best candidates for refactoring with your developers. What will improve their velocity, code quality or reliability? You can be sure they will come up with plenty of work to do.
“If we don’t build it, somebody else will.”
This argument often comes with an idea for vertical or horizontal expansion. While there is nothing wrong with a product line extension or expansion to another segment, you’re more likely to be successful when focusing on your core business. You can always come up with a way to do things a little better, cheaper or faster and improve your main value-added product.
Your product was built to solve a certain problem and that’s why your customers love it and use it. This is what you should stick to even when thinking about new product ideas and features.
No customer or stakeholder should be more important than a great product and the rest of its users. Give yourself permission to say NO without feeling guilty, mean, or selfish. It’s your job to look at your product from a wider angle, set priorities and pick the right spot for the improvement, optimization or brand new feature.
As Warren Buffett famously said, the difference between successful people and very successful people is that very successful people say no to almost everything.
