Manual coordination
Timetable generation involved substantial manual effort from faculty and administrators.
Reimagining howa college managesits timetable.
Taking a manual, coordination-heavy scheduling process and turning it into a centralised timetable and faculty management platform.
A scheduling problem.
An opportunity to build.
The Timetable and Faculty Management System (TCMS) was developed to replace a manual timetable management process at a college.
Scheduling required coordination between faculty, departments, classrooms and laboratories. The existing approach made the process time-consuming and difficult to manage.
I took ownership of the product from discovery and requirements gathering through MVP planning, development coordination, testing and deployment.
PRODUCTTimetable & Faculty Management System
USERSFaculty & administration
DEPLOYMENTCollege intranet
MY ROLEProduct Manager & Developer
02 / THE PROBLEMScheduling was more
01 02 03
Scheduling was more
complicated than it looked.
A timetable is not simply a collection of time slots. Every allocation needs to account for people, departments, classrooms, laboratories and availability.
Multiple constraints
Faculty availability, classroom allocations and laboratory schedules needed to be coordinated.
Changing availability
Fixed time slots could not always represent when a faculty member actually became available.
Start with the people
who use the system.
Before defining the solution, I worked with the people responsible for managing academic schedules to understand their requirements and pain points.
8ADMINISTRATORS INTERVIEWED
10DEPARTMENT HEADS INTERVIEWED
25+REQUIREMENTS IDENTIFIED
WHAT I DID
Translated conversations into product requirements.
I interviewed administrators and department heads, identified recurring scheduling needs and converted the findings into epics, user stories and acceptance criteria.
This created a structured foundation for prioritisation and development.
04 / MVP & PRIORITISATIONBuild what matters first.
Build what matters first.
Then expand.
With multiple requirements coming from different stakeholders, the challenge was deciding what should be included in the first release.
I scoped the MVP by balancing stakeholder value, engineering effort and delivery timelines.
Requirements were translated into a prioritised backlog, followed by sprint planning and development coordination.
PRODUCT DELIVERY APPROACH
01
Understand requirements
Gather needs from administrators and departments.
02
Prioritise the MVP
Balance value, effort and delivery timelines.
03
Plan development
Structure the backlog and plan sprints.
04
Validate and release
Coordinate UAT and deployment.
Moving beyond fixed
time-slot availability.
One of the more challenging decisions was how to represent faculty availability accurately.
Fixed time slots
A faculty member was marked as unavailable during an allocated time window.
10:00–11:00BUSY
11:00–12:00BUSY
12:00–13:00AVAILABLE
Limitation: A faculty member could finish a class early but remain marked unavailable until the original time slot ended.
Dynamic availability flags
Each faculty member had a 30-minute flag. Availability could change when the faculty member actually became free.
Faculty statusBUSY
↓
Class completed earlyUPDATED
↓
Availability flagGREEN · AVAILABLE
The flagging approach allowed availability to reflect actual faculty status rather than only a predefined time window.
PRODUCT THINKING
The important change was moving from a time-based assumption to a status-based representation of availability.
06 / EXECUTION & DELIVERYFrom requirements
From requirements
to a working product.
I led sprint planning and coordinated development, testing and release activities for an eight-member engineering team.
Alongside product ownership, I also contributed to the frontend, backend and UI/UX development.
The platform was deployed on the college intranet and is currently used by faculty and administration across eight academic departments.
8MEMBER ENGINEERING TEAM
8ACADEMIC DEPARTMENTS
LIVECOLLEGE INTRANET DEPLOYMENT
TECHNOLOGY USED
HTMLCSSJavaScriptNode.jsAxiosMySQL
Less manual effort.
More time for what matters.
BEFORE
Timetable generation could take a week.
The process involved manual scheduling and coordination across multiple stakeholders.
→
AFTER
The same work could be completed in hours.
The deployed platform made scheduling significantly easier for the faculty and administration.
Qualitative comparison based on the project experience; no independently validated percentage improvement is claimed.
08 / KEY LEARNINGSWhat building from zero
What building from zero
taught me.
01User discovery is essential when different stakeholders experience the same problem differently.
02A strong MVP is about making deliberate trade-offs, not simply building fewer features.
03Product decisions need to reflect actual user behaviour, not just predefined assumptions.
04Seeing a product adopted by real users is one of the most rewarding parts of product ownership.