Transformation 04 / Live-event companion app
The deadline was not a roadmap choice. It was the event.
I shaped requirements and release readiness around a fixed World Cup weekend where ambiguity had a public cost.
scale22–23 Feb2025 World Cup weekend
The official Crans-Montana race history confirms the fixed public event dates.
reported100,000+audience interactions during event periods
Recorded in the enterprise case source. The term is not converted into users, downloads, or attendees.
scale3event-critical release slots in the simulation
Representative prioritization constraint used to demonstrate delivery pressure.
scale1immovable public launch window
The event could not move to follow the product roadmap.
The actual project
What the business needed, and what I delivered.
- The business
- Swiss-Ski needed its mobile app ready around the 22–23 February 2025 Crans-Montana World Cup weekend. Audience information, engagement, content, release support, and an immovable public event date converged.
- The product mandate
- Turn the event calendar into a delivery plan: define the audience-critical journeys, decide what had to ship, and make product, engineering, content, and operational readiness agree before the races began.
- My work
- I structured mobile journey requirements, clarified stakeholder requests, supported sprint prioritization, reviewed event-critical flows, and coordinated release-readiness expectations beyond engineering completion.
- Business effect
- The app premiered around the World Cup weekend and the supplied source records 100,000+ audience interactions during event periods. The number is retained as interactions, not relabeled as users or downloads.
Act 1 / The pressure
Seven requests. Three release slots. One immovable weekend.
Change one condition and watch the consequence travel through the system. The model uses representative data and preserves the real decision.
Choose 3 more items. Prioritize the audience path, not stakeholder volume.
Act 2 / The model
Event readiness was larger than engineering completion.
Requirements, defects, dependencies, and stakeholder requests all converged on one public date. The useful question was not whether each request had value, but whether it protected the audience journey and operational readiness for that weekend.
A feature could be code-complete and still not be event-ready if content, support, release sequencing, or ownership remained unclear.
- 01Audience need
- 02Release slot
- 03Operational owner
- 04Event support
Underlying structure: I shaped requirements and release readiness around a fixed World Cup weekend where ambiguity had a public cost.
Act 3 / The decisions
The product changed when the decisions became explicit.
Prioritize by event criticality
The pressure. Every stakeholder request arrived with a reason to ship before the event.
The move. Rank work against the audience path and operational consequence of failure.
Inspect the tradeoff
Consequence: The release lane protected what the event experience depended on most.
Treat readiness as a shared decision
The pressure. Engineering completion could hide unresolved content, support, or ownership work.
The move. Review product behavior, release sequence, and operational support together.
Inspect the tradeoff
Consequence: Ready meant usable and supportable at the event, not merely merged.
Resolve ambiguity before the peak window
The pressure. The cost of an unclear journey rises sharply when a public event begins.
The move. Validate audience flows and stakeholder expectations before the final window.
Inspect the tradeoff
Consequence: Teams could focus on event execution instead of interpreting basic product behavior.
Contribution boundary
My work turned interpretation into buildable behavior.
What I contributed
- Structured requirements for mobile audience journeys.
- Coordinated stakeholder expectations against fixed event windows.
- Supported sprint prioritization and release-readiness planning.
- Clarified engagement flows and operational sequencing.
- Aligned delivery activity with live-event support realities.
What remained outside my ownership
- I did not own the event, all implementation, audience acquisition, or the full product outcome.
- The 100,000+ figure is described only as recorded audience interactions during event periods.
Act 4 / The change
The event calendar became a product constraint.
Evidence-qualified outcome100,000+ recorded audience interactions during event periods
The app premiered around the 2025 Crans-Montana World Cup weekend. Delivery priorities were interpreted through event criticality instead of backlog order alone.
The supplied source records 100,000+ audience interactions during event periods. The site preserves that exact definition and does not relabel it as users, downloads, or attendance.
Read the evidence boundary
The priority board is representative. It contains no internal defects, unreleased requirements, or private event operations.
Act 5 / The lesson
Deadlines become product constraints when they change the cost of ambiguity. In a live-event product, prioritization and operational readiness are part of the user experience.
Start a conversation
What are you trying to untangle?
Bring the unclear process. We can make the next decision obvious.