AI: The Ultimate Product Killer

Adding New Features Was Never the Problem

The bizarre conflict at the heart of all the AI excitement:

1. AI has made us better at shipping.

2. Companies are now hiring Product Managers who they ask to be able to ship stuff on their own.

3. The end result: we can ship more features.
   

YAY! Everyone rejoices. However, being able to ship more features is not the flex companies think it is.

More features isn’t better. Shipping faster usually only means you’re speeding up the demise of your product.

When will we learn that shipping more features was never the problem in the first place?

More Features = More Problems.

Product Management means shipping the right things and getting rid of the things that don’t pull their weight.

If anything, we should be hiring PMs who are great at editing and removing, because that’s the current bottleneck. We see so few great products, because most companies suck at editing and removing. They’re constantly running the hamster wheel of adding more and more features without ever looking back.

In some companies where adding new features is the bottleneck, but usually that’s caused by sucking at editing and removing. We’ve reached the point that we’ve got a big bloated codebase that’s keeping a giant mess of features afloat. It’s a matter of time until all those features will drag your product down because the actual bottleneck is sucking at editing and removing.

Every feature we add, unless it adds value, is a parasite. Here are some of the different costs you incur for the upkeep of a feature in your product (list not exhaustive):

• Support costs when people call to troubleshoot or let you know something doesn’t work.

• Maintenance costs to fix issues or to update features, so they remain working.

• Infrastructure costs to pay for servers and infrastructure the feature runs on.

• Increased development costs for other features: as your codebase grows, it will become more expensive to add new features.

• Dependency costs. More features mean more dependencies to manage. More dependencies result more time lost in coordination and meetings, which means higher development costs.

• Marketing costs for features communicated to your users.

We can visualize the balance between the ability to add and remove as follows:

If the ability to add and remove are both high, you can build an Applesque Product that is capable of doing many things yet still appear simple to users. That’s an awesome place to be in. If you’re good at removing, but not at adding, you’ll end up with a Minimalistic Product, which does few things but does them well. That’s not bad either.

If you are great at adding features, but not good at removing, you will usually end up with a Swiss Army Knife Product. That’s a risky and dangerous place to be in where disaster is lurking around the corner. The product can do many different things at the same time, and appears as complex to users, because stuff rarely gets removed and revisited.

It’s a problem that gets exponentially worse as you add more features, especially because features interact with each other.

If you’re bad at both addition and subtraction, you’re usually in a Frankenstein Octopus Product situation. You've added too many features which resulted in technical debt, feature debt, and incessant firefighting. This means it becomes nearly impossible to add new features without opening a blister pack with a gazillion developers. As you’re also incapable of removing features, you’re stuck with the current demon spawn of a product.

To make matters worse, the following usually happens:

When you’re in a Swiss Army Knife situation, usually over time, it turns into a Frankenstein Octopus Product situation. You have a product that can do a gazillion things, but it does none of them well. Plus, you’re in the worst position to do anything about it.

It’s an evil genie you can’t put back in the bottle. So, please don’t end up there. And if you have a Swiss Army Knife product, watch out. You will only notice when it’s too late.

Don’t Be Like Atlassian: Get Better at Removing Features

One of the best examples of a company that has entered Frankenstein Octopus Territory is the Jira issue tracker made by Atlassian. I’ve been using it for more than ten years and loved using their magnificent Swiss Army Knife back in the day. But at the moment, every day when I’m using it, I become more miserable as the rot of their Frankenstein Octopus Product begins attacking my brain.

In the age of AI, we’re mostly focusing on the ability to add new features, even faster, all we’re going to get is lots of tick-ridden products with companies hiring people who are great at exacerbating the mess of ticks.

The host, your product, will slowly succumb under the crushing pressure the upkeep of all those ticks requires. It will slowly turn into a Frankenstein Octopus Product… until someone a meeting room whispers that evil and damning word: rebuild.

Then you know, you’re totally screwed. Because when a rebuild is on the table, you’re in the biggest mess of messes.

Don’t end up there. It’s where companies frequently go bankrupt. Do you remember Netscape?

If you don’t, it proves my point and if you do, it also proves my point. But perhaps they would have went bankrupt regardless, because of Internet Explorer being aggressively bundled together with Windows. But they lost many years of market leadership by performing a rebuild.

Refrain from hiring Product Managers who are only great at adding features, try to hire Product Managers who are great at editing and removing.

You want to have as many features as necessary, but as few as possible. And that’s the damndest difficult part, not adding those darn features.