Creating a Product Roadmap
Last week, I worked on sizing the features and components of the banking app I am redesigning. I met with a developer and we went over in days how long different features would take as wells as how long the key flows would take to build.
I estimated the total app to take around 5 months for 1 developer to build.
This week I have been focused on creating a roadmap for exactly how this app will get built. In order to prioritize which features to start with, I asked myself: What is most essential for a banking app? What would be most valuable to a user? and What features are “nice to haves” that can be skipped for now and added in later?
Step 1 – Prioritize
First I prioritized the key flows by writing them out on a list and shuffling them around.
Some of the prioritization is debatable, and I actually did move things around some when I late went through features. For example, I changed see transactions to come before mobile deposit because that made more sense for both capability and the timeline of the features to be built.
Step 2 – Thin Slice
Next, I went through the wireframes of all the key flows and eliminated the parts that were non-essential.
The main features/components removed were those that the developer mentioned would take longer, and also didn’t detract from core value.
The first to go were: scheduling, a carousel for the accounts, touch ID, search and filtering for accounts, adding a non-Wells Fargo account, and a lot of the navigation from the menu and section screens were removed and added in along with the corresponding features.
Each of the new “thin slice” was saved into it’s own file so it could be shared with a developer.
Step 3 – Documentation
From here, I created an excel document and put all the flows in order of priority, typed in the features to be removed, how many days it would save, and the rational behind that decision.
Step 4 – Product Roadmap Version 1
For the first round of the product road map, I put all the features and components for each flow into a column and marked which features would be removed in red. This way I could make sure to add them back in to a later part of the road map. I also noted how many days it would take for each flow.
Step 5 – Add in Release Time Frame
Then I added up the days and figured out when we would be able to make a product release based on days and coherence of the features.
I decided that the first release could happen after one month of work, and then after that we could develop a 2 week release cadence. For the first release, the user would be able to log in, create an account, see their balance, view account transaction, and even make a mobile deposit. I felt really good about providing all this, which really is the core of what a banking app should do in my opinion.
I incorporated buffer days into each release. If two weeks is 10 working days, a lot of my release timelines were 8 days. However, the 3rd release has a 12 day timeline, and I worried the buffer from the first release (2 days) and the 2nd release (2 days) wasn’t enough.
Step 6 – Add a Developer
Next, I reorganized the product roadmap thinking of how I could utilize two developers on a project instead of one. For the most part it was simple.
I thought about keeping the developers on the same type of tasks. For example, one developer does “mobile deposit” while the other does “view account transactions”, as opposed to having them both work on the same task. There were a couple of times when I had to move order of items around in order to make work days fit a timeline and keep core functionality together. I didn’t want to have “pay a bill” built and released at a different time from “view bills”.
I kept some buffer days in the release timeline so that the different parts could be wired up.
At the very end of this roadmap, there were really just a few more features to be added in. At this point, the release cadence can switch to a one week cadence and we can update, fix bugs, and add small features even more regularly.
On second thought….
The total time line for two developers is only 3 months. I think that’s relatively low, and allows space and time for other aspects of the app, like a “safe to spend” feature to be built in. I think what I would do, is have one developer work on the updates and bug fixes and have the second developer work on new features that can be released on a slightly longer time line.
Hopefully this way the app will always be improving.