The Feature That Everyone Requested But Nobody Actually Used
"Bulk operations would be a game-changer," read the GitHub issue with 47 upvotes and enthusiastic comments from developers across different projects. "We need to be able to select multiple content items and perform actions on them all at once - publish, unpublish, delete, move between categories. This is essential functionality that every CMS should have."
The feature request was perfectly reasonable. The use cases were compelling. The community consensus was clear. We prioritized it for our next major release and spent six weeks building a comprehensive bulk operations interface.
Three months after launch, our analytics showed that less than 2% of Twill installations had ever used bulk operations. Even among the most active users, the feature was being used maybe once per month, if at all.
We'd built exactly what people asked for, but apparently not what they actually needed.
The Perfect Feature Request
The bulk operations request looked like product management gold. It had:
Clear problem definition: "Managing large amounts of content one-by-one is tedious"
Specific solution requests: "Select multiple items and perform batch actions"
Strong community support: Dozens of upvotes and detailed use case descriptions
Competitive parity: "Every major CMS has this functionality"
Multiple stakeholder validation: Requests came from both developers and content teams
During our planning sessions, everyone agreed this was obvious missing functionality. Our design team created beautiful mockups. Our engineering team was excited about the technical challenge. Even our client teams mentioned that bulk operations would improve content management efficiency.
The feature roadmap practically wrote itself.
The Implementation That Checked Every Box
We built a comprehensive bulk operations system that addressed every use case mentioned in the GitHub discussions:
Multi-select interface: Clean checkboxes with "select all" functionality
Batch publishing: Publish or unpublish multiple items simultaneously
Category management: Move content between categories in bulk
Tag operations: Add or remove tags across multiple items
Status updates: Change workflow status for entire content sets
Bulk deletion: Remove multiple items with proper confirmation dialogs
Export functionality: Download metadata for selected items
The feature was polished, well-documented, and exactly what the community had requested. The GitHub issue thread filled with positive reactions when we announced the release.
The Launch That Should Have Been Triumphant
The bulk operations announcement generated significant excitement. The feature was prominently highlighted in our release notes, demo videos, and documentation updates. Early feedback from beta users was positive - they confirmed the functionality worked as expected and solved the problems they'd described.
But something odd happened in the weeks following release: almost no one was actually using it.
Our usage analytics showed:
98% of installations never used bulk operations
Active users averaged 0.3 bulk operations per month
Most bulk actions were performed on fewer than 5 items
The export functionality went completely unused
Support tickets weren't complaining about bugs or missing functionality. Users weren't reporting problems with the feature. They just... weren't using it.
The Reality Check Conversations
Confused by the disconnect between enthusiasm and adoption, I started having direct conversations with users who had originally requested bulk operations.
"Oh, bulk operations - yeah, that looks great!" said one content manager from a client project. "We haven't needed to use it yet, but it's good to know it's there."
"When do you think you'll need it?" I asked.
"Well, when we have to manage large batches of content, obviously."
"How often does that happen?"
Long pause. "You know, now that I think about it... not that often. Most of our content updates are pretty specific. We're usually working on individual pieces."
This conversation repeated across multiple user interviews. People loved the concept of bulk operations, but their actual content workflows rarely involved managing large groups of similar items simultaneously.
The Workflow Reality Gap
The deeper issue became clear during a screen-sharing session with the International Energy Agency's content team. They had thousands of articles, reports, and data sheets - exactly the scenario where bulk operations should be valuable.
I watched their content manager work through updating publication status for a batch of reports. Instead of using our bulk operations feature, she was going through items individually, making different decisions for each one based on context I couldn't see.
"Why not select them all and update the status at once?" I asked.
"Because they're all different," she explained. "This one needs a different publication date. That one is missing required metadata. This one needs review from a different department. They look similar in the system, but they all need slightly different handling."
The bulk operations feature assumed that content management was like email management - lots of similar items that could be processed identically. But content isn't email. Each piece has unique context, requirements, and stakeholder considerations that resist batch processing.
The Feature vs. Workflow Mismatch
Our usage analytics revealed the fundamental problem. When users did perform bulk operations, they were typically:
Deleting test content during initial setup
Moving demo articles into proper categories
Cleaning up imported data from migrations
Managing temporary content created for specific campaigns
These were all maintenance tasks, not core content creation workflows. The feature was being used for housekeeping, not for the day-to-day content management that people had described in their requests.
The real content workflows looked different:
Individual review cycles: Each piece of content went through unique approval processes
Contextual publishing: Publication timing was based on specific campaign or project needs
Custom categorization: Content organization required understanding the specific topic and audience
Relationship management: Content decisions involved considering connections to other content that wasn't obvious in bulk views
The Community Feedback Loop Failure
The most troubling realization was how the GitHub discussion had created a false consensus. The feature request attracted people who thought bulk operations sounded useful, but it didn't validate whether their actual workflows would benefit from the feature.
Comments like "this would save so much time" and "essential for content management" sounded compelling, but they were hypothetical. People were imagining scenarios where they'd use bulk operations, not reporting frequent situations where they actually needed them.
The social dynamics of GitHub made the problem worse. Once a feature request gained momentum, people felt pressure to agree that it was important. Disagreeing with a popular feature request felt like being obstructionist or not understanding user needs.
Meanwhile, the people who might have pointed out workflow mismatches - content managers dealing with complex, contextual publishing decisions - weren't actively participating in GitHub discussions about CMS features.
What We Actually Learned
The bulk operations experience taught me several crucial lessons about community-driven product development:
Vocal requests don't equal actual needs: The people most likely to comment on feature requests aren't necessarily representative of typical usage patterns.
Hypothetical enthusiasm differs from practical adoption: Users can genuinely believe they need a feature without actually having workflows that would use it regularly.
Edge case optimization can miss core workflows: Focusing on scenarios where bulk operations would be useful (data cleanup, migrations) led us to overestimate how often those scenarios occurred.
Social proof creates false validation: Once a feature request gains community support, it becomes difficult to question whether the underlying need is as common as it appears.
Usage context matters more than functionality: People don't just need the ability to perform bulk operations - they need workflows where bulk operations make sense.
The Pivot That Actually Helped
Instead of doubling down on bulk operations, we focused on improving individual content management workflows:
Better content previews so users could make decisions faster
Contextual action shortcuts for common individual tasks
Workflow automation for repetitive individual operations
Content relationship visibility to help with contextual decisions
These improvements addressed the actual time-wasting parts of content management - the friction in handling individual items - rather than trying to batch-process inherently contextual work.
The Lesson About Community Product Management
The bulk operations experience fundamentally changed how I evaluate feature requests, especially popular ones. Now I ask different questions:
How often do you encounter this problem? (Not "would this be useful?")
Show me the last time you needed this (Not "can you imagine scenarios?")
What do you currently do instead? (Understanding existing workflows)
Who else is involved in these decisions? (Identifying stakeholders who aren't in GitHub)
The most dangerous feature requests are the ones that sound obviously useful to everyone. They bypass critical thinking because they feel like no-brainer improvements. But "obviously useful" and "frequently needed" are completely different things.
The best features aren't the ones that get the most enthusiastic community support - they're the ones that solve problems people encounter regularly in their actual workflows. Sometimes that means building boring improvements that nobody gets excited about, but that make daily work incrementally better.
Bulk operations taught me that community consensus can be wrong, not because people are lying or confused, but because the social dynamics of feature discussions can create false validation for hypothetical needs that don't translate to real usage patterns.
The goal isn't to build features that sound great in GitHub comments - it's to build features that become indispensable in daily workflows.