Creating a Product Roadmap
Starting with sizing
Through the first half of Q4, we have spent most of our Product Management class getting to understand the role of PM’s, and how we will most likely interact with PM’s in the workplace. We have gone through exercises to estimate the time needed to complete a list of features on a product called SchoolAdmin. We spoke with developers in a 1-on-1 session (thank you Julianna!) to break down the features and give an estimate to the amount of work it might take to complete the tasks. Now that we have the understanding of time needed, it was our job to prioritize the features and create a product roadmap that leads two full-time developers to complete the project.
Discussing the sizing and hearing some think-aloud feedback from my developer was helpful because I was able to grasp how they group problems into buckets to tackle at the same time. It became clear that the various stages of the “Add prospective Student” flow were all tightly connected, and that these tasks should be approached at the same time and not necessarily considered multiple jobs. This feedback allowed me to create the roadmap in a more streamlined fashion and guide some decisions.
Building the Roadmap
Using the MoSCoW priority method (still trying to figure out how Must Have = Mo), I broke the features into Must Have, Should Have, Could Have, or Won’t Have classifications. Trying to start with Must Have, while also making sure that the developer was working on similar or dependent features made the roadmap slightly more difficult.
The 2nd task to this project was to effectively rebuild the map with a hypothetical budget cut, allowing only 80% of the previous time allotted. This proved to be more difficult, and required decisions of making some feature Won’t Have, which I did not need to decide in the full roadmap.
Insights and Learning
- Features like “Add 2nd student” that were linked to “Add prospective student” should be given to the same developer due to familiarity.
- Features that were dependent on previous pages or features being done could not be considered “Must Have”.
- Prioritizing building the “School info” was more critical than the “School Filter”. In a worst case scenario, a user could manually scroll through the list of schools, where as without the info, there would be nothing to filter through.
- Removing the “Breadcrumb”, although only 1 day, was an easy omission because there are multiple ways to navigate the site already through the dashboard and sidebar.