Glossary
A feature inventory is an authoritative catalog of all implemented product capabilities, derived from source code and kept current automatically. Without it, product teams can't confidently answer whether features exist, leading to sales errors, engineering duplication, and incomplete competitive analysis.
Across three companies — Shiksha Infotech, UshaOm, and Salesken — I've seen the same engineering challenges repeat. The details change but the patterns don't.
A feature inventory is a catalog of all features, capabilities, and functionality that a product possesses. Unlike a roadmap (which describes what will be built), a feature inventory describes what has already been built. It's the ground truth for what a product can do.
Most products don't maintain feature inventories. Instead, product knowledge lives in documents scattered across the company, in people's heads, and in the codebase. This creates what's called tribal knowledge: only certain people know what the product can do, and that knowledge is fragile (if that person leaves, the knowledge goes with them).
Feature inventories solve three problems:
First, they prevent duplicated work. When the product team doesn't know what features exist, they sometimes build things twice. "Can we add this capability?" "Let me check if we already built it." Without an inventory, checking means asking people. With an inventory, checking is searchable.
Second, they enable better planning. Roadmaps are better when they're informed by what already exists. If you want to add capability X, knowing that you have 60% of it already built changes how you plan. Knowing that you have none of it changes the scope conversation.
Third, they reduce tribal knowledge. When a PM or engineer leaves, their knowledge of the product goes with them. A feature inventory captures that knowledge in a searchable, maintainable form.
A good feature inventory includes:
It doesn't need to be exhaustive (every line of code cataloged). It needs to be useful (the features users care about are there, and it's searchable).
Start with user-facing features. Not every code module is a feature. A feature is something users interact with or care about. API endpoints, if they're part of customer-facing functionality, are features. Internal infrastructure usually isn't (unless it affects what customers can do).
Involve engineers. Engineers know the codebase. They know what exists, what's deprecated, what's fragile. Building an inventory without engineering input misses critical information.
Keep it updated as code changes. This is the hard part. An outdated inventory is worse than no inventory because people trust it and then get wrong information. The best way to keep it updated is to make inventory maintenance part of the code review process. When code ships, the inventory gets updated. Making this a habit is easier than trying to catch up retrospectively.
Make it searchable and accessible. A feature inventory in a Confluence page that only the PM can find isn't useful. It needs to be: searchable (full-text search so people can find what they're looking for), linked (so features reference related features), and accessible (PMs, engineers, support, everyone uses it).
They're related but different:
Feature Inventory: What does the product have? (For internal use)
Product Documentation: How do users use what the product has? (For external use)
A feature inventory might say: "We have export functionality. It exports user data as CSV. Limitations: doesn't support custom fields."
Product documentation for the same feature would be: "To export your data, go to settings, click Export, choose CSV, and download. Your export includes: user profile, projects, and collaborators."
Both are useful. Feature inventory is for the product team. Product documentation is for users.
Feature inventories affect:
Sales conversations: When a prospect asks "can you do X?", the sales team needs to know. They either need a current inventory or they need to ask engineering, which is slow. A searchable inventory is faster.
Support conversations: When a customer asks "can I do X?", support needs to know. If it's possible, they can walk the customer through it. If it's not possible (yet), they can explain why. If it's possible but undocumented, support can point to the code or engineering can explain it. Without an inventory, support often hears "I'm not sure, let me ask engineering."
Product planning: When you're planning the next quarter, knowing what you've already built informs what you build next. Is the feature complete, or does it need refinement? Are there related features that would be natural to add? An inventory answers these questions.
"Feature inventories are only for large products." False. Even small products benefit. The problem they solve (tribal knowledge, duplicated work) affects all sizes.
"Feature inventories become outdated immediately." They do if maintenance isn't embedded in process. If updating the inventory is part of the code review or deployment process, it stays current.
"We can search the codebase instead of maintaining an inventory." Engineers can. Non-engineers can't. A feature inventory should be accessible to PMs, designers, support, and sales. The codebase isn't.
"Feature inventory is the PM's job." It's a product team job. Engineers own the accuracy (they know what actually exists). PMs own organization and accessibility (they know what sales and support need). Working together, you build a useful inventory.
Q: How granular should features be? A: User-facing capabilities, not lines of code. "Export as CSV" is a feature. "CSV writer module" is not. A user would care about the first, not the second.
Q: How do we keep it updated? A: Make it part of process. When code ships, the inventory gets updated. This can be: a checklist in the PR template ("update feature inventory"), a discussion in code review ("should this be in the inventory?"), or a separate task after deployment. What matters is that it's expected, not optional.
Q: What tool should we use? A: Google Sheets works fine for small products. Confluence works for medium products. For larger products or products with complex relationships between features, a database-backed tool (even a custom Airtable base) makes more sense. The important thing is that it's searchable and accessible.
Q: How often should we audit the inventory? A: Quarterly is reasonable. You don't need to go through the entire codebase. You need to review: what shipped this quarter (is it in the inventory?), what's being used less than we thought (should we mark it for deprecation?), what features have interdependencies we didn't capture (should the inventory show relationships?).
Keep reading
Related resources
