Creating a Product Roadmap
In our Product Management class, we have learned how to properly identify and catalog application features, as well as different sizing techniques for determining the length and workload of developing them. We are working with our instructor on an application that helps students and their parents keep track of school applications. We analyzed screens from this in-progress project, identified the features offered, and then presented them to developers to get their opinion on how long each would take to develop.
Once we had determined the time needed, we were tasked with creating a full-length schedule and a “thin slice” schedule for developing 80% of the product’s features. I had spoken with my developer about the potential for creating slimmed-down versions of some features that he informed me would take a particularly long time to develop, such as the ability to schedule school visits through a calendar function and school coordination. With an assessment of 14 days, this was by far the longest development time of any feature.
The following spreadsheet represents the full-length development schedule I’ve developed, assuming two developers are working four-day work weeks.
The thin-slice version removes two features: the Schedule Appointment feature and the Prepopulated Entries feature, which would automatically recognize information about a student entered for a previous application and supply it for future applications. It also changes the Search for School by Zip Code and Distance from Zip Code features into a Search by City and State feature, which saves 2.5 days in development. These changes bring total development time from 38 days (19 days with two developers working) to 18 days (9 days with two developers working). With an extra day’s worth of time baked in, the two schedules come out to 20 days and 10 days, making thin-slice development time exactly half the length of the full version. The thin-slice schedule can be found below.
When assigning tasks and determining the order of development, I assessed features based on must have, should have, could have and won’t have criteria. I worked to assign developers to entire flows and to assign flow development in concentrated schedule blocks, so that the developers would not have to jump around between different screens and flows. Must-have features were prioritized first, and subfeatures were developed after the primary features they depended on. To the extent that the schedules deviate from this pattern, it was due to developer input that some features would take one tenth, one fourth, or one half of a day. Combining these smaller features to create a full day’s worth of work occasionally required combining work on different flows into a single day.
This project, while initially difficult to grasp conceptually, has proven invaluable in learning how to work with developers to appropriately size projects and create a roadmap for development. Knowing how to speak this language and translate information from design to coding is crucial for working with teams to bring products to life.