Trimming Down that Banking App

For our last product management assignment, we met with developers to generate estimates based on the redlined wireframes of our mobile banking apps. For this assignment we used those estimates to create two product roadmaps. The first was based on an “ideal” scope with two developers working full time (40 hours per week). The second was based on a “constrained” scope of the product launching within one month (20 working days) still with two developers working full time.

Approaching this I was very thankful for the estimates spreadsheet we created in the last assignment. This helped me quickly review the estimated hours for each flow. I created new columns to turn these estimates back into days, and generated totals at the bottom. To build out my full front end app as I currently have it scoped I’d need an estimated 57 days. So I only needed to trim a little bit.

Looking at my flows I zero’ed in on the send money flow where a user can send money to another account outside of the bank. This was chosen because it nicely cut out 8.5 days and I figured this is a function that many users have other apps to do this already such as Venmo and Zelle.

RemovedSendMoney_LBS

I also decided to lose the chart function of the monthly trend feature, because that information is a duplicate of the list screen in chart format and would cost me 2 weeks.
RemoveChart_LBS
Lastly, I trimmed down the deposit check flow to remove the confirm image screens and the static info screen at the beginning of the flow. This removed another 3.5 days. I figured that these were more nice-to-have items and I think the MVP version of the app will function well enough without them. In fact, they may not even be necessary so it might be better to add them in later if we find users are having difficulties there.

Removed deposits screens for overview instructions and confirm image.
Removed deposits screens for overview instructions and confirm image.

Next, I began laying out my development roadmap. I decided to use half days as my increments along the top and added two rows to divide work across the developer resources. To organize the flow/screen development I tried to group similar functionality and screens together thinking that would reduce the amount of ramp-up time for the developers as they moved between flows.

You can see how these screen are similar and may benefit from having the same developer work on them.
You can see how these screens are similar and may benefit from having the same developer work on them.

I also made an attempt to have the flows build off of each other functionality wise. For example, the screens showing flagged and recurring transactions would be built after the basic transaction screen. This means the core functionality of the app will be developed first. I placed login at the end which may seem counterintuitive, but my thinking around this is that these screens offer a little flexibility on the features that we add so may do well at the end when the timeline has more or less than anticipated.

Included below are the constrained roadmap (top) and ideal roadmap (bottom). The timeline for my “ideal” app build could be achieved within two months of development if all goes as planned.

LBS_Roadmaps

Click here to see the full spreadsheet of estimates and roadmaps.