International Student Insights Dashboard.
BMI Global Ed runs international student recruitment fairs, and every fair produces registration and badge-scan data. I knew that data had more potential than we were using, so I proposed a product that turns it into insight for the universities who exhibit, and made the proposal reviewable as a working prototype.
The data was already there
At every fair, students register online or at the door, are checked in and given a printed badge, and have their badges scanned by the universities they speak to, who can rate each student on the spot. We already used this data well internally, for reports, breakdowns and marketing lists. I knew there was more potential in it: joined across both sides of the fair, it could tell each university which students fit it best, and become a product universities pay for.
How this data is collected: Self-Serve Fair Sites,Conference Check-in & Badge Printing,BMI Smart Scan. How it is reported today:Fairs Reporting Hub.
Two-sided matching for the universities who exhibit, and new opportunities with those who don't
Students tell us what they want: a subject and a destination. Universities tell us, through their booth ratings, which students they want. No one was putting those two signals side by side. The product I proposed does exactly that: it shows each exhibiting university where student demand and its own interest overlap, so its team knows who to follow up and which fairs are worth attending. It also opens a door to universities that were not at the fair, who could still see what students there wanted.
Built on real client needs
Shaped by use cases our existing university clients already had: knowing which students to follow up after a fair, whether a fair was worth the spend, and which markets and subjects are growing.
Three personas
University recruiters, BMI's internal teams and fair managers, each with their own view of the same data.
Two-sided matching
Student interest crossed with each university's own booth ratings: the product's core differentiator, because the fair data holds both sides.
Privacy by design
Each university sees only its own ratings, never another's, with consent, age and data-freshness rules written into the requirements.
New opportunities beyond the fair
Universities that did not exhibit could still see the student-demand side of each fair, what students wanted to study and where, opening a new line of work with clients the fairs never reached. Booth ratings stay private to the university that made them.
Measured from the start
Success KPIs defined up front, and a phased roadmap from prototype to full platform.
AI-assisted product management
AI helped me draft; the product decisions were mine. I fed our existing client use cases and public market data into AI-assisted drafts of the requirements, then set the scope, personas and privacy rules myself. The finished requirements became the specification for two builds.
Why build it twice
Running an AI coding agent on the same specification, in parallel with my own build, was an evaluation: could the requirements alone carry a build? I compared the two, reconciled them by pull request, and kept my build as the one that shipped, with a market-specific dataset in place of the agent's generic one.
A working prototype on public data
The prototype is a static dashboard with six modules, modelled on one market, Mexico, to make the concept concrete. It runs on ten public education and demographic datasets and fictional student records, so no personal data was involved and the concept could be judged before any backend or database investment. It was never connected to live fair data.
Six modules
Summary, Geographic, Courses, Pipeline, Destination and Intelligence, switching instantly in the browser.
The matching view
Student interest set against university booth ratings, the proposal's core idea made visible.
One university's own view
A persona-specific view showing how a single university would see its own leads and insight.
Export and print
Three CSV exports and a print or PDF copy, so reviewers could take the numbers away.
From prototype to platform
The proposal is with the Managing Director and COO. If it goes ahead, this is the order I would build it in, starting on the badge-scan data the fairs already collect.
What I did
The idea, the requirements and the prototype were mine; the AI coding agent's parallel build was an evaluation I ran.
- Spotted the opportunity in data the fairs already collected, and proposed the product on my own initiative.
- Wrote the product requirements document with AI assistance, drawing on existing client use cases: problem statement, three personas, five module specifications including the two-sided matching concept, success KPIs, privacy rules and a phased roadmap.
- Coded the prototype myself, from first commit to a deployed, reviewable site in seven days.
- Built a market-specific data model for Mexico from ten public education and demographic datasets.
- Ran an AI coding agent on the same specification as an evaluation, then reconciled the two builds by pull request, keeping mine as the one that shipped.
- Presented the proposal and prototype to the Managing Director and COO.
Tech stack
Say hello.
Message sent.
Thanks for getting in touch.