Roadmapping to an MVP

Unprioritised ideas and requests

When I joined Monash, the mobile team was just a small group of developers, including a few current Monash IT students. The team had been established by one of the directors in the Digital Department to bring his vision to life. He provided a broad range of feature ideas for the new app — from something as simple as a campus shuttle bus timetable to something as significant as enrollment functionality.

At the time, the app’s front-end was already in development, showcasing concepts like assessment reminders, grades, unit information, and more. However, the availability and structure of the underlying data were still unclear.

The team needed to make an informed decision about where to focus for the app launch—it was time to shift from concept to product. My first mission was clear: to discover what truly matters to Monash students and what is realistically achievable for the team in time for the launch.

---

Discovery

Semester journey mapping workshop

To truly understand the challenges students face each semester, I asked current Monash students to break down a semester into key stages and list the typical activities at each stage. I then asked them to explain how they personally complete each activity.

For example, when it comes to tracking assessment due dates, some students with fewer assessments found that adding deadlines to their Google or Apple calendar worked well. On the other hand, students managing a larger number of assessments found this setup tedious and preferred simply printing out a list of due dates.

Hearing about these workarounds gave me valuable insight into just how unsatisfied students are with the current process and highlighted what the system at Monash is missing.

Impact analysis

The results of the workshops highlighted where the key pain points were and how desirable potential solutions would be. This provided the team with a valuable starting list of features. To define the MVP for the app launch, we needed to further refine this list by assessing both feasibility and impact, allowing the team to prioritise effectively.

For the feasibility check, the mobile development team and I reviewed each item to determine how ready the necessary data was to support the feature. Unfortunately, some highly desired features—like the assessment weight breakdown—were unlikely to be available in the near future. These features required significant changes to the workflow on the teaching staff’s side to first clean and structure the data. We decided to set aside these long-shot features as future action items to address with the relevant stakeholders.

When it came to estimating impact, we aligned on two key criteria: how broadly each feature would affect the user base and how frequently each feature would likely be used.

Timetable: The best impact with the least effort

The analysis quickly revealed a clear opportunity for the mobile app: to become a one-stop hub for managing daily schedules. This emerged as the most consistently frustrating task that coursework students faced several times a week.