Creating Product Roadmaps
For our last assignment in our Product Management course, we met with a developer who gave us estimates for the front-end development time to complete hero flows of our mobile banking apps. Using those time estimates, we have spent the past week creating product roadmaps for our banking app. We’ve created two different roadmaps for the same product, assuming we have two developers working 40-hour work weeks. One roadmap illustrates a full release of our thin-slice flows – the very minimum functionality that still offers value to the customer, while the second roadmap illustrates a release of the product constrained by 30-day release cycles.
PREPARING THIN-SLICE FLOWS
To prepare for creating my product roadmaps for the A+ FCU banking app that I redesigned, I started with the sizing estimates that the developer I spoke with had provided me. The flows I presented the developer were what I would consider hero flows – basic but complete flows for a banking app. Here’s the original estimation summary, broken out by functionality chunks as the developer indicated.
Fortunately, the hero flows I originally created are already basic and wouldn’t require a lot of time to develop. However, I felt that there were still a few features that I could cut to make for the thinnest-slice flows that my users would value. The highlighted areas in the table below indicate what I removed from the hero flows to define my thin-slice flows:
My thin-slice flows would take 60 days to develop, as opposed to 80 days for hero flows. With two developers working 20 work days a month, I should be able to develop these thin-slice flows in just over a calendar month.
Next, I prioritized the functions from most important to least important, to determine in which order to build the product and assign the different functions to the two developers on the roadmaps.
Thin-Slice Flow Functions
Enroll in online banking
Home (Accounts Overview)
Full Hero Flow Functions
Add account (internal + external)
Menu navigation drawer
Deposit check – dynamic limit
THIN-SLICE SCREEN ADJUSTMENTS
I went back to my wireframes and removed the functions and components that weren’t part of my thin-slice flows.
I removed the ability to set and use a passcode for logging in to the app, so I adjusted the login screens to reflect this. I kept a fingerprint login in addition to the standard login for Android users because it’s valuable to my users to have a quick way to log in.
I also decided to take out the menu button and navigation drawer, because the functionality included in my thin-slice flows is available to users directly from the home screen. The navigation drawer was built as part of the hero flows to allow users an alternative way of accomplishing tasks, and it includes the ability to add an account, which is a function that was also removed from the thin-slice flows. The navigation drawer was also originally conceived as something that could be built out and expanded, as new functions are added to the app over time. Because the log out button was located in the menu drawer, I had to replace it on the home screen, underneath the welcome header.
BUILDING THE ROADMAPS
I decided to search for and use a product roadmap tool, to gain experience with a new purpose-built digital tool, and one that was hopefully easy to use. After some brief research I decided to try ProductPlan’s software, because I liked the visual layout and it appeared easy for a beginner to use.
First I made the full-release roadmap, which schedules the features of my thin-slice flows for the complete period of time it would take to develop them. I took my list of prioritized features, and calculated how to divide those features between the two developers, using the chunks of time (e.g. 8 days) that the developer had indicated. I decided that a single feature needed to remain with one developer if at all possible, because I don’t have enough knowledge to know if developers can ‘share’ working on the same thing. I set both roadmaps to being on April 1. See my full-release roadmap below:
In my decision-making, it made sense to me for a single developer to own all the pre-login and login features, while the other worked on the highest priority banking functions – home, accounts, deposit check, and internal transfers. On the full-release roadmap, the thin-slice flows are complete on May 14, while the hero flows are complete on May 27. I included additional ‘future version’ functionality, such as the ability to set recurring transfers and viewing spending habits, beyond that date.
In my 30-day release cycle roadmap below, you can see that the first 30-day release, on April 26, includes enrolling in online banking, log in functions, the home screen (accounts overview), and the ability to view account activity and individual transaction details. The user can’t move any money around, but they are able to see what’s going in and coming out.
At the 60-day release, on May 24, all thin-slice flows have been completed, and hero flow functions are underway. On this 30-day release cycle roadmap, the thin-slice flows are complete on May 20, while the hero flows are complete on May 30. The majority of the 90-day release is dedicated to additional functionality (spending habits, recurring transfers).
Aside from the release timeline, and the slight difference in dates that the thin-slice and hero flows were complete across the two roadmaps, in general they were fairly similar, with a few notable exceptions.
In the full-release model, Developer 1 owns all the login, pre-login, and smaller pieces of functionality, while Developer 2 works on the larger pieces of functionality related to the banking functions – home+account overview, deposits, transfers. In the 30-day release cycle model, Developer 1 works on deposits because Developer 2 owns all the functions relating to transfers. Because transfers are functionally integrated with adding accounts, Developer 2 works on creating functionality for internal transfers, then builds out the transfer features by working on the ability to add both internal and external accounts.
In the full-release model, to release the hero flows efficiently, the add account feature is broken up between the two developers – Developer 1 works on adding external accounts (which I estimated would take longer), while Developer 2 works on adding internal accounts (which I estimate would take a shorter window of time, since it doesn’t require going ‘outside’ the bank). Realistically, I don’t know if it’s possible to split up adding account features across developers, and if so, if this is the correct timing split. I would need to speak to a developer again for guidance.
In the 30-day release cycle model, Developer 2 owns all transfer functions, so s(he) works on the totality of adding accounts.
- ProductPlan’s Advantages + Limitations:
You can add details that pop up in the active roadmap (see below), which is very helpful. But you can’t organize the roadmap by the number of man days, only days on a calendar – by weeks (or months). It doesn’t factor in weekends for you. I had to painstakingly use Google Cal to coordinate the number of man days with a monthly calendar, assuming the work started on April 1.
- Starting Thin:
It helped me that I started with very basic functionality. I didn’t have to cut much to get to thin-slice flows, and the hero flow functionality is scheduled to finish chronologically not long after the thin-slice flows are released. I know that things always ‘have to get cut,’ but it made my job easier not to have to cut too much this first time.
- Constraints of Feature Timeframes:
While it would be possible to fit development of features into a certain time frame if you’re only looking at the total number of man days for development, those ‘chunks’ don’t fit cleanly into that time frame. Creating the roadmap is a little like playing Tetris. You have to consider priority, release cycles, and which developer is best to delegate tasks to.
- Needing Additional Info from Developers:
One change I had between roadmaps was to divide ‘add accounts’ from a total chunk of 12 days owned by a single developer into two sections (one 4-day and one 8-day) to be shared across 2 developers. Before I would feel comfortable actually doing that, I would need to speak to them to know if that was possible. I need more info to truly make an informed roadmap.
- Working Ahead:
Because of the time frames of feature chunks, across both models one developer was always working ‘ahead’ to the next version, while the other was finishing the milestone (thin-slice, hero flow, etc). New versions were always beginning in overlap with the current release finishing up. I can see how this could propel a sense of continuous forward momentum.
Click here for a condensed pdf of this product roadmap process.
Click here for more detailed versions of both A+ FCU product roadmaps.