Product ownership · UX direction · AI-assisted delivery
I came up with the idea for a new prediction platform and proposed building it to involve hackathon spectators
Make a prediction as a participant. Switch to Admin to manage an event and settle its result
This is a public reconstruction with fictional events and browser-local data that resets on reload. Core participant and admin flows are interactive; XLSX import and prediction history are labelled interface previews. The case below describes the original project, including workflows beyond this reconstruction
I saw an opportunity to give hackathon spectators an active role, beyond following the presentations
So I proposed building the platform, created a prototype in Manus and developed the participant and admin journeys with Codex
The platform went live during the event, with 2,917 predictions settled across 11 events and a preserved final archive
While helping organise a corporate hackathon, I proposed giving spectators virtual credits to predict hackathon outcomes, follow results and compete for prizes
A dedicated digital product for spectators had not been part of the initial plan. After my proposal was approved, I took ownership of shaping and delivering it
Predictions were the starting point. As the product developed, I added team voting and audience-award workflows, connecting more ways to take part in the event
The currency had no monetary value and could not be withdrawn or exchanged. I treated the economy as an engagement mechanism and tested proposed reward rules against that purpose
The product had a defined lifespan. A reliable event, clear rules and correct results mattered more than continuing to expand the feature set
I led the product from the original proposal through requirements, design, release and live operation. I developed the BRD and first design prototype in Manus before moving into full-stack development with Codex
I set product priorities, reviewed technical options and checked the result myself before accepting it. Codex implemented and tested the application; product ownership describes my responsibilities on the project, rather than a formal Product Manager title
The initial MVP connected login, virtual balance, events, predictions, settlement, a leaderboard and administration. It established the full cycle from a participant’s choice to an organiser’s official result
A merchandise shop was added during development. I later asked to remove it and return to editable prizes for leaderboard positions. The final product focused on predictions, voting, prizes and running the event
I also separated the main hackathon questions from additional events. The most important choices needed to be visible immediately; secondary questions could sit further down the page
Removing the shop kept the scope focused on the hackathon
Early layouts for selecting an outcome were either too large or too dense. I checked that team names remained readable, the selected state was obvious and the main action stayed visible
The resulting sequence was explicit: select a team, choose Place Bet, then confirm the amount. Before selection, the interface needed to explain why the action was unavailable. After submission, it needed to show the participant’s choice and expected reward
A reward based entirely on the shared pool could produce a disproportionate payout for a very small prediction. I asked for numerical examples, challenged confusing alternatives and set constraints to make the virtual economy easier to understand
I requested a visible potential reward and moved detailed formulas into the rules. The event card could then concentrate on the choice and its consequence. The displayed reward remained an estimate until settlement
I simplified the ranking by basing it on the net result of settled predictions. Allocated credits should not automatically become a competitive advantage
I also asked for a leaderboard with its own scroll area and the participant’s position in the header. Finding your place should not require scrolling through an ever-growing page
Public support and a secret audience award needed different behaviour. I separated the two instead of treating voting as a single generic feature
For both, I asked for a clear selected state, acknowledgement that the vote was saved and confirmation of a changed choice inside the product
Recurring rounds let spectators support a team. Organisers could change the question, open a new round and retain earlier results
The audience award needed voting results to remain private until the announcement. Before then, a broadcast view could show the number of votes without revealing the distribution
These describe the original product’s two voting modes. The public demo reconstructs selected team-voting workflows
The organiser needed to create and edit events, change schedules, manage their status, open voting rounds and settle official outcomes. I treated the administrator workflow as a core part of the product
Hands-on testing exposed practical gaps: unclear start and end fields, problems with administrator imports, missing main events and reset controls. I turned those observations into changes to the workflow
An operator’s working screen is different from a screen shown to spectators. I requested separate 16:9 views for rankings, Team Boost and Audience Choice, then reviewed text density, overlap and whether all teams fitted
During the event, a simpler standalone statistics card was also needed. I treated that output as part of running the hackathon rather than assuming the main interface would serve every context
Live changes included schedules, leaderboard presentation and credit allocations. My recurring constraint was to preserve accepted predictions, votes and configured events
Organisers managed much of the event through the admin interface. Some changes still needed technical assistance, so the launch was not entirely self-service
I found issues on mobile that were less apparent on desktop: an unstable header, an excessively long leaderboard and a voting section that occupied too much of the screen. I requested a complete mobile layout while retaining the desktop experience
Onboarding also needed to work in context. I checked that each hint pointed to a visible element and did not cover the action it explained. Desktop used element highlighting; mobile used a separate bottom panel and different scrolling behaviour
As voting features were added, the tour needed to explain them too. These were manual acceptance checks. I did not run a separate usability study or measure whether completing the tour meant that people understood the rules
A prediction had to be saved once, the balance had to change consistently and settlement had to avoid duplicate payouts. I requested correctness checks and load tests around those risks
I also asked for staging and production to be separated. After test content was damaged and an unapproved shop appeared in the wrong version, preserving configured events and enforcing release scope became explicit acceptance conditions
The project record includes failed readiness checks as well as successful runs. Some tests exposed strain on the login process or response times above the target thresholds, even when no requests failed. I used those findings to prepare for launch. The soak figure describes one historical test; it does not establish incident-free operation or a service-level guarantee
During the hackathon I requested activity summaries, reviewed results and managed live adjustments. The work shifted from adding features to keeping the event running consistently while people were using the platform
After the event, I requested a complete archive and a check that the project and data had been preserved before the server was cleared. The original service ended with a closing page
A later local presentation mode was prepared for a screencast. That work happened after the final production archive and is separate from what ran during the hackathon
The strongest result is that the platform supported the event from start to finish: participants made predictions and voted, an organiser managed events and outcomes, and the final state was retained in an archive
The record supports real use and settlement. It does not establish an increase in overall hackathon engagement against a baseline, a satisfaction score or a quantified cost saving
Verified from the original platform’s final production snapshot. This is a platform-wide settlement result, rather than a participant count or a result generated by the public demo
The case draws on recorded product decisions, saved implementation and test reports, and the final production archive. Final prediction states are confirmed; the archive does not establish that every voting session was technically closed. Screens on this page belong to the sanitised reconstruction. Historical broadcast cards, private records and participant data are not included
This project required me to make product decisions, verify the implementation and run the live service. Working with AI reinforced the importance of clear requirements and careful review: a message saying a change was ready was not enough
In the ILIAS case, I explored how an open-source LMS could support a corporate learning need, and where its learner and administrator experience needed adaptation
Explore the LMS caseI’m looking for a Product Owner or Product Manager role combining product judgement, business analysis and hands-on delivery
