Turn repository labels into useful product-progress evidence
Create a lightweight taxonomy that links pull requests to products and initiatives without mistaking labels for a complete roadmap.
Delivery activity lacks product context
Repositories and pull requests describe technical work, while leaders usually ask about products, capabilities, features, initiatives, releases, and customer outcomes. Without a bridge, reporting falls back to repository counts or manual status slides. Labels can provide a useful first mapping because they already travel with the work. The goal is not to make every label perfect; it is to create enough consistent product context that delivery evidence can be grouped, inspected, and corrected.
Separate durable and time-bound concepts
Keep durable products and features distinct from initiatives, MVPs, releases, and iterations. A product or capability has continuing ownership and a lifecycle beyond one delivery window. An initiative links several features for a temporary objective. A component maps the technical topology, such as a service, client, SDK, or repository. Use explicit prefixes or controlled mappings so a team label, feature label, and release label cannot be confused. Preserve uncategorized work instead of hiding it.
Treat labels as evidence, not absolute truth
A pull request label can suggest that work contributes to a feature, but it may be stale, overly broad, or added for a different workflow. Keep the source label and repository link, record whether the association is explicit or inferred, and allow a manager to author the durable mapping. Merge requests without a feature label can fall back to repository or component mappings while remaining visibly unclassified. Provider-confirmed issue state should never be invented from a pull-request reference alone.
Make classification part of normal work
Choose a small required label set, document examples, and add templates or automation that suggest labels when a change is opened. Review uncategorized and conflicting work during the weekly delivery routine, not in a separate taxonomy project. Let teams correct mappings from the report and propagate durable decisions to future work. Keep label names stable enough for trend analysis, but version the mapping when the product structure changes so historical evidence remains explainable.
Track coverage and usefulness
Measure what portion of active work has a credible product, feature, initiative, and technical-component association. Sample the linked records and ask whether the grouping helps a leader make a decision. High coverage with vague labels is not success. A useful system makes gaps visible, distinguishes authored structure from inferred evidence, and links every progress claim to actual changes or work items. Once the lightweight model is trusted, a dedicated issue or planning connector can add provider-confirmed state, priority, assignee, and due dates.
See your delivery system clearly.
Explore a production-like Troodo workspace and see how delivery evidence becomes a focused management brief.
Explore the live demo