If you’re a Product Manager of a mature product, you’ve probably suffered the unfortunate experience of building dead functionality.
It may go by different names at different organizations, but it refers to unused or low-usage features in your application that failed to fulfill their promise.
The key phrase here is: “unfulfilled promise.” Some features can be low usage but still critical to a product's success. If you’re experienced in FinTech, you’ve probably built a lot of low-usage but critical features like archiving, recovering data after an interruption in services, or a manual input/edit of a transaction for situations where a feeding system is down.
Features like the above are rarely used but serve a critical purpose. Dead functionality refers to features you intend your user base to adopt but don’t live up to their promise once deployed.
Perhaps they sounded like great ideas at the time you built them. Your customers may have even been stoked at the prospect of getting this functionality. But when you rolled it out, nobody used it no matter how hard you pushed.
Why does it happen?
Dead functionality typically stems from one of these seven reasons:
It sounded interesting
You or someone on your team came up with a brilliant idea. In fact, it sounded so genius, you failed to do your due diligence. The cool features were approved, built, tested, and deployed. Your user base promptly ignored it.
This is the easiest problem to avoid. An organization that instills structure and requires justification of features forces the Product team to do the work and prove that the feature will solve a problem or exploit an opportunity better than the competition.
We had an extra 50 Development days to fill
Suppose you have 500 development days per release, and you’ve only got 450 days filled. What do you do with that extra time? Perhaps you’re not in a position to do advanced work on the next phase of your roadmap and the thought of taking care of those nuisance defects - issues that aren’t urgent enough to address at once - doesn’t seem worth the effort. Instead, you invent work to fill up the time.
In these situations, I prefer to address the time with outstanding low and medium-priority defects or performance improvements. Always have a list of vetted performance improvement enhancements or cleanup work ready.
It’s been sitting out there a long time
“We’ve had this enhancement sitting out there for over a year!”
Here’s the thing. If an enhancement has been sitting on the sidelines for over a year, and nobody is clamoring for it, you should question whether it’s needed or wanted.
Building a feature just because it was logged a long time ago is a surefire path to creating dead functionality.
Change in the marketplace or business rules renders it useless
This scenario might be the toughest to avoid, especially in FinTech where regulatory and industry changes might render once critical functionality to outdated trash.
Marketplace shifts, regulatory rule changes, and industry practices can affect the viability of your features and the value of your application.
These changes rarely happen overnight, so you usually have time to prepare and adapt, but it requires you to pay attention to all facets of the business, including regulatory rules and industry mandates. This must be part of your defined processes.
The Dunning-Kruger effect
Imagine a new Product Manager starts a job, does their research, designs a product roadmap, gets buy-in, builds the damned thing, and only once in the marketplace do they realize they were naive in their assumptions. They thought they knew it all but later realized they were incompetent when they made their product decisions.
It’s an example of the Dunning-Kruger effect - a cognitive bias where people with limited competence in a particular domain overestimate their abilities, owing to the phenomenon that they simply don’t know what they don’t know.
People with limited skills or knowledge in a particular domain overestimate their abilities because they’re unaware of the existing totality of knowledge.
These tips can help you avoid this bias.
Never assume you know all there is to know or all you need to know about a domain.
Always search for what you don’t know about your area of focus. Find a topic where you’re uncomfortable. This will keep you humble.
If it seems too easy to conduct due diligence on a feature or product, then it probably means you’re unaware of what you don’t know. Take a step back and immerse yourself in the domain you wish to compete. Talk to new people, seek different perspectives, and search for the knowledge you were unaware existed.
Poor execution
Sometimes, you’ll have a great idea and design that’s fully vetted, yet, the feature still fails in the marketplace. Sometimes, the team executes it poorly. Perhaps it was rolled out with defects and the customer base lost confidence. Other times, poor execution could delay the release, allowing competitors to steal market share before your feature has a chance to win over customers.
No matter how fantastic a feature or how well it promises to solve a problem, your organization must execute it well.
Orders from above
There’s one cause of dead functionality where you own little to no responsibility. The ones running your organization order you to build something for reasons never fully explained.
Sometimes, they may ask you to vet their ideas or provide your analysis. In these cases, you have some influence. Often, however, you have little recourse to these decisions.