Glossary
By the Glue Team
A feature inventory is a comprehensive catalog of all features, capabilities, and functionality that exist in a product. It documents what the product can do, preventing duplicate development, informing competitive positioning, and supporting product decisions. Without a feature inventory, teams often unknowingly build features that already exist.
A feature inventory lists:
A good inventory includes:
Feature inventory is strategic infrastructure:
Prevents Duplicate Development: The most embarrassing waste is building a feature that already exists. This happens frequently in large products. Sales discovers a customer asked for "feature X" but engineers already built it years ago. Time is wasted rebuilding. Feature inventory prevents this.
Informs Roadmaps: Product roadmaps should be based on what exists and what gaps are. Without knowing what you have, you can't identify what you need. Features you've already built become your competitive advantages—if you knew you had them.
Enables Better Onboarding: New developers can read the feature inventory to understand what the product does. Product managers can read it to understand selling points. This is faster than reverse-engineering the codebase or reading old specifications.
Supports Competitive Analysis: When analyzing competitors, knowing your own features is prerequisite. "They have X and we don't" only makes sense if you know for sure you don't have it. Feature inventory enables accurate gap analysis.
Helps Prioritization: If you're deciding between two features, understanding which one already exists partially (and can be extended) vs. building entirely new is important context.
Reveals Zombie Features: Features nobody uses exist in many products. A feature inventory reveals what's actually valued vs. what's accumulated cruft. This information informs deprecation decisions.
Supports Licensing and Packaging: You can't tier features (free vs. pro vs. enterprise) without knowing what all features are. Inventory enables packaging decisions.
Creating a feature inventory requires systematic work:
Start with Specifications: Collect product specs, design documents, and feature requests. These document what was intended to be built.
Inspect the Product: Use the product end-to-end. Document every capability visible in the UI, every configuration option, every integration.
Review the Code: Code audit reveals capabilities not exposed in UI. Hidden features, internal tools, beta features. Look for feature flags that expose unreleased work.
Interview Teams: Ask sales what customers ask for. Ask support what problems features solve. Ask engineering what's complicated or incomplete. These conversations reveal nuance.
Check Metrics: Which features do users use? High-usage features are valuable. Zero-usage features might be removed.
Document Relationships: How do features relate? Does feature A require feature B? Which features are alternatives?
Assign Owners: Who maintains each feature? Who knows it best? Owner is point of contact for questions.
Version and Update: Feature inventory is living documentation. As new features ship, add them. As features deprecate, mark them. Review quarterly.
By User Role: Different users see different features. Organize by who uses what. Sales features vs. customer features vs. admin features.
By Functional Area: Organize by domain. Payments, authentication, reporting, etc.
By Platform: Desktop, mobile, API. Organize by which platforms support which features.
By Maturity: Shipped, beta, development, deprecated. Shows status at a glance.
By Release Timeline: What shipped when. Helps understand evolution of product.
Most teams use a spreadsheet or wiki to maintain inventory. Some use specialized tools. The format matters less than the discipline of maintaining accuracy.
Feature inventory reveals technical debt:
Feature inventory is input to technical debt prioritization—what should be consolidated, cleaned up, or removed?
"Feature inventory is just a list." Partly false. It's a living document that requires investment. Maintaining accuracy is ongoing work. But that work is valuable—teams that maintain good inventory ship faster.
"Product managers should maintain feature inventory alone." False. Multiple perspectives needed. Product sees customer perspective, engineering sees technical perspective, sales sees customer request patterns. Best inventories are collaborative.
"Feature inventory is only for large products." False. Small products benefit too. Even five-feature products should have documented, shared understanding of features.
"We can build feature inventory from docs alone." False. Docs are incomplete or outdated. You need to actually use the product and read the code to build accurate inventory.
Codebase Documentation: Feature inventory documents what exists at product level. Codebase documentation documents implementation at code level.
Feature Discovery: The process of finding features that exist. Feature inventory is the output.
Competitive Gap Analysis: Gap analysis requires knowing your features first. Feature inventory is prerequisite.
Technical Debt: Outdated, unused, or duplicated features contribute to technical debt.
Q: How detailed should feature inventory be? A: Enough to answer "Is this built?" clearly. One-line descriptions for simple features. Paragraphs for complex features. Link to detailed specs if they exist. Avoid overwhelming detail that makes maintenance hard.
Q: How often should feature inventory be updated? A: As features ship. Quarterly full reviews. Monthly spot checks for accuracy. If inventory drifts, stop trusting it. Accurate is better than perfectly formatted.
Q: Should deprecated features be listed? A: Yes. Mark them as deprecated. This prevents rebuilding them. It also informs users who might still be using them (with migration paths) that the feature is going away.
Keep reading
