Reframing a mission-critical baggage platform.
Discovery, MVP scoping and roadmap definition for the rebuild of a Baggage Reconciliation System supporting operations at Dubai International Airport.
A critical operational system with a long horizon.
The Baggage Reconciliation System sits inside airport operations where product decisions have operational consequences, dependencies across multiple teams and limited tolerance for ambiguity. My role was to translate operating needs into a structured product direction while coordinating delivery across two Scrum teams.
Do not start with a backlog. Start with the operating model.
A rebuild at this scale cannot be treated as a list of feature requests. The useful work was to establish which operational capabilities belonged in the MVP, how the future-state platform should evolve, and how requirements could be made precise enough for engineering and testing.
The product challenge was less “what features do people want?” and more “which capabilities keep the operation safe, scalable and evolvable?”
Translate operations into product structure.
Map operating needs
Partnered with operational and business stakeholders to understand workflows, constraints and the outcomes the rebuilt system needed to support.
Make scope explicit
Authored features, business logic, functional requirements and acceptance criteria so scope could be challenged before it reached development.
Separate MVP from horizon
Led MVP scoping while defining a five-year roadmap, separating immediate operational necessity from longer-term product evolution.
Keep business and engineering aligned
Managed Agile execution across two Scrum teams, PI planning and backlog prioritisation while using delivery metrics to surface bottlenecks.
Outputs that made the programme legible.
The 82M+ figure describes the operating environment. The product outputs are the discovery, feature definition, MVP scope and roadmap.
From “a bag is missing” to “the chain broke here”, on invented bags.
Not project data. It checks a made-up custody chain and shows how a simple scoring rule can separate MVP from horizon. The numbers below are computed at build time from invented data made with a fixed random seed. They show how the idea works, not what happened on the project.
| Result of the chain check | Bags | Share |
|---|---|---|
| Complete chain | 4,789 | 95.8% |
| Gap between two scans | 168 | 3.4% |
| First scan missing | 18 | 0.4% |
| Last scan missing (may still be travelling) | 25 | 0.5% |
Of 5,000 invented bags, 186 need a person to look. For the 168 with a gap, the check says where the chain broke:
| Checkpoint with no scan | Bags |
|---|---|
| Check-in | 0 |
| Loaded on aircraft | 69 |
| Transfer area | 100 |
| Arrival hall | 0 |
The first and last checkpoints show zero because a missing scan at either end cannot sit between two scans. Those cases appear in the rows above instead.
A scoring rule for the MVP cut
The scores below are invented for this page. They are not the real feature list. The point is that the cut can be argued from stated criteria instead of preference: score is criticality plus dependants, plus 2 when the capability is hard to add later. At 7 or more it goes in the MVP.
| Capability (invented) | Score | Scope |
|---|---|---|
| Match each bag to its flight | 11 | MVP |
| Flag a bag with no match | 10 | MVP |
| Record every custody handover | 10 | MVP |
| Audit trail for every change | 9 | MVP |
| Shift-level exception list | 5 | Horizon |
| Self-service reports | 3 | Horizon |
| Mishandling prediction | 3 | Horizon |
| Cross-airline analytics | 2 | Horizon |
How this was computed
Four generic checkpoints: check-in, loaded on aircraft, transfer area, arrival hall. They were chosen for this
illustration and are not taken from any standard or system. Each scan is missing with a small fixed probability.
Code: src/lib/artifacts/bag-custody.mjs.
What I owned — and what I did not.
I owned / led
- Product discovery and MVP scoping
- Feature definition and backlog prioritisation
- Business logic, requirements and acceptance criteria
- Roadmap definition
- Agile execution across two Scrum teams
I partnered / influenced
- Engineering implementation
- Testing and release readiness
- Operational stakeholder decisions
- Vendor selection and budget alignment
The operating environment is independently visible.
Public sources establish the scale and continued role of baggage reconciliation at DXB.
The useful PM artifact is shared clarity.
Large enterprise rebuilds create pressure to equate progress with feature volume. The work I value most from this programme was creating a structure where operations, engineering and delivery teams could discuss the same future state with fewer hidden assumptions.