If features are good, then the more features your product has the better, right? Wrong!
It’s the classic quantity over quality debate, and for those of you who are still undecided here’s our take: Quality wins. And yet many product teams still operate like having more features is the main measure of success.
When the only roadmap your team is using is feature-driven — and performance is measured by how many features we can squeeze into the next release cycle — then your team may as well be a feature factory. Here’s why.
A feature factory is a product team or company that’s more focused on pumping out features than understanding whether those features should be pumped out… or not.
As an expert in product management, Cutler identified feature factories as companies that focus on the number of features included instead of the quality of features and their impact on consumers.
What’s so bad about being a feature factory, we hear you ask? Lots of companies develop products this way — and if it ain’t broke, don’t fix it.
But it is broken. Let’s look at some common feature factory problems.
When work is disconnected from objectives, it becomes valueless. If a developer has no feedback on their work or how it ultimately impacts consumers or the company’s strategic objectives, they realize that their work doesn’t matter.
Teams organized around short-term convenience quickly become teams of 1 person. Workers are left demotivated, disconnected, and disenfranchised.
Stephen Covey, author of The 7 Habits of Highly Effective People said, “The main thing is to keep the main thing the main thing.”Feature factories create products that do the exact opposite.
When users are forced to wade through layered menus of features that they will never use to find the one thing the product is meant to do, they go and find a more optimized solution.
Features don’t always add value, they sometimes dilute it.
Adding features adds complexity. Each added feature exponentially increases the possibility that one feature will break another.
This complexity also means that if a feature breaks because it was dependent on a resource that has changed or is no longer available, product teams encounter the failure cascade. Truly as bad as it sounds, this makes finding and fixing issues in released products more difficult — and, sometimes, impossible.
Added complexity makes everything slower. Features take more consideration before implementation to ensure they are truly new and not overlapping. New features must integrate with more existing systems. Testing needs to consider ever more complex and convoluted use-cases and corner-cases.
Users love it when product owners listen to their feedback and respond appropriately. The answer, however, is not always a new feature.
Constantly adding new features that have a minor impact, or only benefit a small subset of users, can cause most of your customers to be cynical of new releases — and new features end up being irrelevant.
So if product teams shouldn’t lean too heavily on feature-led roadmaps, then what can they do? Enter: the outcome-driven roadmap.
60+ pages full of information about roadmapping and especially product roadmap: what is it, how to create a product roadmap, types of roadmaps, prioritization and tips on how to communicate with stakeholders effectively using roadmaps.
Outcome-driven roadmaps include features, but they look vastly different from feature-driven roadmaps. Every feature is tied to outcomes. Outcomes are measured through KPIs to understand success. And whether an outcome is successful or not, it is reviewed, and the impact of features is understood.
How a feature is implemented is as important as whether it is implemented. Teams are rewarded for innovative, excellent implementation because it impacts the outcome.
Features are strategically assigned to teams who develop towards outcomes that are already being worked on. Features are prioritized by impact as well as effort and time.
Features can also be incrementally improved to better meet outcomes — or canceled if they are not meeting the objectives. Developers understand why adjustments or pivots are necessary and can help with formulating the best solutions.
Optimizing outcomes instead of focusing on features removes the risk of feature factory behavior and keeps product people with their eyes on the prize!
If your product team exists in a feature factory already, or you’ve noticed your team is heading that way, there are actions you can take. Check out the airfocus ebook, to help you transition to a value-focused company.