Estimation and prioritization for a product roadmap

We started our Product Management course digging into a new feature release of a School Admin product. School Admin works with independent schools to provide software that they can use to automate all kinds of school administration tasks. The release that we are working on is a parent-facing portal that facilitates online applications to client schools.

We first documented the features and then facilitated a discussion with a software engineer to get an estimate for how long the project might take. The first engineer I talked to was my friend Sunny. Facilitating that conversation, I let him organize the features into categories that were meaningful to his work as a software engineer (navigation, data management, styling, sub-pages). He then gave me estimates for each of those categories.

Afterward, as I was thinking about prioritizing features for a thin slice version of the app, I realized Sunny’s estimate wasn’t really going to help me. I reached out to another software engineer, Matt, and walked him through the features and asked him to provide an estimate while sticking with my categorization around features. The estimate ended up actually being substantially shorter (a little more than 5 weeks, compared to about 8 weeks), which I attribute to natural variation. Both engineers insist they were giving very conservative estimates.

With Matt’s estimate, I was able to think about what features seemed worth investing time in. Right away two places to scale back came to mind. First was a component to add an applying student to the portal that included a sub-component that asked to identify who this student was a sibling of. The flow of this feature seemed potentially confusing. Is step-sibling a sibling? If one parent did the application for one child last year and another parent completes the process this year, would the portal prompt this different user?

As I explained how it might work, Matt indicated that it might complicate existing data structures. The estimate for the ‘add student’ component was substantially increased by including the ‘add sibling’ subcomponent. For something that to me had questionable value, it was easy to de-prioritize that.

The other possibility I considered for scaling back was the student dashboard and the application checklist. Both of these features included a visualization of the student’s progress as an applicant. Although seeing the application progress in both screens was nice to have, they were performing the same function for the user in different ways. Twice as much work for the developers, but not twice the value for the user.

Although I had an intuition about these two features being the place to trim fat, I wanted to approach the question more systematically. I used a 2×2 to graph the value to the user against the effort required to deliver the feature or component.

prioritization chart

I then created a product roadmap for the full product. I put features that served as containers for other features first (such as the menu and sidebar). I also prioritized the fields that can be customized by the schools as they might end up needing more robust testing because the school users might get really weird is chosing content for those areas.

Parent Portal - Full Product

Visualizing the process this way I realized two things. One, the notification center icon was a substantial chunk of the roadmap. I hadn’t even visualized it on my 2×2 thinking of it as trivial. Two, while my Matt and I had discussed the complexity of the ‘add sibling’ sub-component, I hadn’t actually asked him to break down the estimate into one estimate for the component without the sibling option and with it. If Matt and I were actually working together on a team, I might have sent him a quick slack message for clarification, but because he was just helping me out with this project, I decided to work with the info I had.

My ‘thin slice,’ a scaled-back version of the product with 80% fewer resources in terms of developer time, emerged with ‘add sibling’ component intact, but without the dashboard status display and without the dynamic notification icon. The link to access the notifications is still there, but does not display differently in response to new notifications. The redundant status display on the student dashboard is removed. Now a parent will have to click on the application checklist to see their student’s progress toward completion.

Parent Portal - Thin Slice

With testing and feedback from users on both the school administration side and the parent applicant side, I might have made different choices. Will it annoy schools to send notifications that parents never see because a red blinking message icon isn’t demanding their attention? Will the lack of a progress bar at the top level screen lead to lower rates of application completion? Perhaps.

While talking to Matt and Sunny they both emphasized that the time estimate for a project doesn’t reduce by half when doubling the number of engineers on the project. Context switching and time spent coordinating work and making sure endpoints match up reduce the efficiency of projects with mutliple developers working on them. To minimize inefficiencies my roadmap suggests an order, but defers to the engineering team to allocate work within the team.