Delivered PGDM context
MBA / PGDM learning lens
Turn a user problem into an adoption case.
- Strategic problem framing
- User value & usefulness
- Feasibility & adoption
- Institutional impact
Incoming PGDM 2026–28 · Great Lakes GurgaonDelivered to PGDM students · Proposed PhD research extension
AI Mini Hackathon: Build-First. By Students, For Students.
The incoming PGDM cohort started with problems they knew from student life, then built GenAI prototypes that people could open, test and question. This page records that July 2026 programme. A later, clearly labelled section shows how a PhD researcher might study this kind of learning design; it is not a record of doctoral participation.
- Registration file · raw records
- 29 registration records
- The original registration file includes repeat team registrations, so this is not a unique-team count.
- Prototype response sheet · final rows
- 24 timestamped response rows
- These are the auditable rows in the shared final problem-statement and prototype response sheet.
- Final notice · 4 July 2026
- 10 teams announced for the final
- The contemporaneous notice also named a final jury of three alumni.
- Evidence note
- These records capture different workflow stages and are not identical. A later 27 July institutional summary reports 26 recorded entries and nine shortlisted teams without documenting its reconciliation method. The figures above remain stage-specific, so 26 is not presented as a count of unique prototypes.
Worth asking
Before building, ask what deserves to exist.
Would you still use this next week, or did it only have to work once, on stage?
If the AI got something wrong here, who would have caught it before a user acted on it?
01 / What happened
Learn by making.
The programme ran over three days: one shared kickoff, two semifinal rooms and a final for the shortlisted teams. Each stage asked students to make the idea more useful and easier to explain.
- 01
Stage 01
Kickoff together
The full batch met in the Auditorium on 2 July to hear the brief, see what GenAI could do and agree on responsible-use expectations.
- 02
Stage 02
Choose a student problem
Teams named a pain area, the people living with it and the practical change their idea should make.
- 03
Stage 03
Build in pods
Build, Users & Business, and Story & Demo pods worked in parallel, connected by the team lead and pod leads.
- 04
Stage 04
Show the work
Two semifinal groups presented on 3 July. The final notice announced ten teams for the 5 July jury in the Auditorium.
02 / Programme schedule
Three days, with time to build between rooms.
The kickoff set a common brief. The two semifinal groups kept presentations to three minutes, and the final allowed roughly nine minutes for the pitch and demonstration, followed by two to three minutes of questions.
Full-batch kickoff
Thursday, 2 July 2026
6:00–8:00 PM
Auditorium
Semifinal · Group 1
Friday, 3 July 2026
2:30–5:00 PM
A16
Semifinal · Group 2
Friday, 3 July 2026
6:00–8:30 PM
Auditorium
Final
Sunday, 5 July 2026
2:30–5:00 PM
Auditorium
03 / Audience lenses
One event record, two clearly separated uses.
The management material begins with the programme delivered to the incoming PGDM 2026–28 cohort and develops it into a reusable classroom pathway. The doctoral material is a proposed research extension only. PhD students were not participants in this edition, and none of the questions below is presented as a finding.
Proposed research extension
PhD lens · proposal, not participation
Treat the prototype as an intervention to examine.
- Research question & constructs
- Evidence & provenance
- Validation & reproducibility
- Ethics & limitations
Management learning pathway
Give each prototype a trail of decisions.
The event record establishes the brief, pods, presentations and jury process. For an MBA or PGDM classroom reusing the format, the sequence below adds depth around the moments that can disappear inside a fast build. It is a learning-design scaffold, not a claim that every activity occurred in July 2026.
- 01
Pre-work
Notice before proposing
Keep a short problem diary from student life. Record what happened, who experienced the friction and what people currently do to work around it. Arrive with observations as well as assumptions.
Useful artifact · Problem diary + assumption list
- 02
Problem
Draw a useful boundary
Name the user, the job they are trying to complete, the consequence of the present difficulty and what the team will not try to solve. A narrower problem usually produces a more testable build.
Useful artifact · One-sentence problem frame
- 03
User
Listen for disconfirming evidence
Ask potential users about the current workflow, exceptions and reasons they might reject the idea. Treat disagreement as useful evidence rather than something to edit out of the pitch.
Useful artifact · User notes + revised assumptions
- 04
Adoption
Explain how use would begin
Identify the likely owner, the workflow that would change, the support people would need and a modest measure of useful adoption. A clever demo is not yet an operating case.
Useful artifact · Adoption map + success measure
- 05
Build
Test the smallest honest promise
Build only enough to let someone attempt the core task. Observe where they hesitate, record failure modes and distinguish a working interface from a reliable AI-enabled service.
Useful artifact · Testable prototype + test log
- 06
Responsible AI
Make safeguards visible
Document the model and data used, keep personal or institutional information out unless authorised, test factual claims, provide human review and consider bias, accessibility, security and foreseeable misuse.
Useful artifact · Responsible-AI check + disclosure
- 07
Reflection
Show how judgment changed
End with the decision trail: what the team first believed, what users or tests challenged, what changed in the build and which question should be answered next.
Useful artifact · Decision log + next experiment
Proposed PhD research extension
Move from an interesting event to a defensible study.
The questions and design choices below are examples for doctoral readers. They do not describe research already conducted, doctoral attendance or effects produced by the July 2026 event. A real study would need a protocol, appropriate ethics review, consent and a clear separation between research participation and course assessment.
Proposed extension · no findings are reported here
Sample research questions
- RQ1
How does closeness to a personally experienced problem shape problem framing, iteration and willingness to abandon an early idea?
- RQ2
How does work divided across build, user-and-business, and story-and-demo roles affect integration, shared learning and prototype coherence?
- RQ3
When do responsible-AI checks change a feature, narrow a claim or alter a team’s view of adoption readiness?
- RQ4
How do live user and jury questions influence managerial judgment after the demonstration, not only the quality of the final pitch?
D01
Constructs and operationalisation
Possible constructs include problem-framing quality, iteration depth, team integration, responsible-AI maturity and adoption readiness. Define each before analysis—for example, through rubric dimensions, version changes and documented decisions—and treat these as candidate measures, not validated scales.
D02
Unit of analysis and data sources
Choose whether the study concerns an individual learner, a team, a decision episode or a prototype. With permission, evidence might include briefs, decks, version histories, demonstrations, decision logs, rubrics, interviews and reflections. Do not merge workflow counts as though they describe the same unit.
D03
Consent, ethics and role separation
Secure the relevant institutional ethics review before collecting research data. Separate research consent from course participation and grading, minimise personal data, explain withdrawal, de-identify reporting and obtain fresh permission before reusing administrative or classroom records.
D04
Limitations and rival explanations
A single institution and cohort cannot establish broad effects. Selection into a final, prior AI experience, facilitator support, team composition, jury questions and incomplete records may all shape what appears to be a learning outcome. Report these rather than smoothing them away.
D05
Longitudinal follow-up
Pre-specify follow-up points that ask whether prototypes were used, revised, transferred or discontinued and whether learners retained the underlying decision practices. Continued use and learning are different outcomes and should be analysed separately.
D06
Reproducibility and audit trail
Where appropriate, preregister questions and analysis choices; version the protocol, codebook and rubrics; preserve a transparent trail of exclusions and changes; and share only materials that can be de-identified and released within the consent granted.
04 / Challenge themes
Start with a problem worth solving.
Students could choose from nine themes. The list gave teams a place to begin while leaving the actual problem, user and form of the prototype to them.
Challenge themes
Where teams looked
- Student productivity
- Learning & class preparation
- Case analysis & class participation
- Placements & careers
- Entrepreneurship & startups
- Campus operations & student life
- Sustainability & social impact
- Wellness & personal development
- Responsible & ethical decision-making
Prototype areas
What emerged
- Business-news briefings
- Peer connection
- Shared rides
- Interactive case learning
- Academic hubs
- Career preparation
- Wellness
05 / In the room
A demo makes assumptions visible.
A working link changes the conversation. Teams had to show what their prototype did, explain who it helped and answer questions about whether Great Lakes could actually use it.
06 / What the jury considered
The final decision rested on five practical questions.
The 4 July final notice announced ten teams and a jury of three alumni. That panel used the five criteria below, which are intentionally narrower than the broader learning rubric introduced at the kickoff.
01
Clarity and relevance of the problem
02
Practicality of the GenAI solution
03
Prototype quality and usability
04
Ease of adoption at Great Lakes
05
Potential institutional impact
The broader learning rubric
At kickoff, teams were also asked to think about originality, teamwork and responsible use—not only the final ranking. Keeping these two lists separate matters: one guided the learning; the other guided the final jury.
- Originality
- AI integration
- User experience
- Feasibility & scalability
- Responsible AI
- Collaboration
- Presentation
- Live demonstration
07 / What each team brought
Each team had to bring work the room could test.
Teams of up to about fifteen could divide the work across Build, Users & Business, and Story & Demo pods. The team lead, three pod leads and a nominated presenter kept those streams connected.
Required submission
- Pain area, problem statement and target user
- An accessible prototype link and working demonstration
- A short pitch covering the problem, solution and user benefit
- A clear account of responsible AI choices
The seven-slide deck
- 1. Title
- 2. Problem
- 3. Solution
- 4. Live Demo
- 5. User Benefit
- 6. Responsible AI
- 7. What’s Next
08 / A parallel track: the internal hackathon
The same format, run for the institution's own departments.
Separately from the PGDM student build above, an internal AI Hackathon applied the same problem-statement-to-prototype format to Great Lakes Gurgaon's own departments— HR, Admissions, Marketing, Finance and others pitching GenAI-enabled fixes to real institutional pain points.
13
registered teams, roughly nine departments
Team Numero Uno
Winner (Executive Education) · 90/100
AI Avengers · The Neural Network
Runners-up, tied at 86/100 (Admissions · Marketing)
What came next
To carry hackathon outcomes past a single event, a proposal for a Centre of Excellence for AI and Innovation at Great Lakes Gurgaon was put forward—intended as a standing platform for continuing the strongest ideas from student and internal hackathons alike. The proposal received encouraging, informal leadership feedback (“an idea worth pursuing—sooner the better”); it remains a proposed initiative, not yet a formally established centre.
Building a prototype is one thing; using AI well the rest of the term is another — see AI for Students for the everyday version of the same judgment this event asked for.
Live beta · open for testing
09 / Side Quests
This hackathon didn't stop when the event ended.
I kept building. Side Quests is where those personal, off-syllabus prototypes live — starting with AI Viva Bot, a live oral-exam simulator that needs people willing to try to break it.
10 / Source material and notes
Read the brief and the thinking behind it.
Public briefing deck · PDF
AI in 45 Minutes
This is the public briefing resource used to introduce the build.
View the deck (opens in a new tab)LinkedIn field note
Why do LLMs hallucinate?
A practical note on probabilistic generation, verification, and why fluent AI outputs still need human judgment.
Read the post (opens in a new tab)LinkedIn posts
Follow the public conversation
I use LinkedIn to share what I am testing in the classroom, what students teach me and where the next question leads.
Open LinkedIn (opens in a new tab)