US Bank Mobile Banking App Redesign: Product Roadmap

We are getting closer to the development phase for our mobile banking app project. My last post involved creating estimates for feature development across the entire system. Now, we’re working on turning those estimates into a product roadmap that will help guide the development process.

A product roadmap lays out groups of features that should be implemented at one time in order to maintain a coherent system that could be released. Each group of features, known as a “thin-slice”, is distributed across the developers available to work on the project. You end up with an estimate of what value you’ll be able to deliver when. Of course, practically speaking, roadmaps are highly inaccurate documents and must evolve as you learn more and hit bumps along the way. Let’s take a look at what mine looks like now.


(click image for larger PDF version)

The first slice is a very simple version of the app, containing only a view of the user’s accounts, their respective balances, and the transaction history under each account. Here’s what that would look like, almost entirely.

Screen Shot 2016-02-10 at 6.06.37 PM

There can be lots of benefits to releasing the app with limited functionality. It can boost team morale to see their work being used, and you can learn when the stakes are lower about pitfalls you might encounter during the release process. However, in this case, there are a couple of strong reasons why a release with limited functionality could be detrimental:

  • The industry has an established baseline of features that are available in just about every mobile banking app. For example, being able to set up bill payments that come out of your account automatically at scheduled intervals is no longer optional—it’s required.
  • Some features, if not implemented, would require the business to take on significant investment in human resources to make up for a lack of automation. For example, you can see that OCR is not being implemented until Slice 3. The app could be released without it, but that would require manual processing of every single check deposited through the app.

Because of these reasons, I was motivated to find a way to get all of the baseline features implemented and to do so in ways that would reduce investment required in other parts of the business.

Let’s take another look at Slice 3:


The pieces in this slice are as follows:

  • The ability to log in using Touch ID (1 day)
  • The ability to create recurring transactions (8 days)
  • Automated check processing with a 3rd party provider of an OCR API (10 days)
  • Advanced notifications (3 days)

The bulk of this work is in creating the logic for editing recurring transactions and integration with a 3rd party OCR service. Much of this work can be done in parallel by a second developer. Because there are obviously some dependencies between the work being done by each developer, I have tried to organize the work so that there is opportunity for appropriate collaboration and handoff. The second developer is also provided some time prior to the scheduled release date to account for the inevitable hiccups in syncing all that work up. Here’s what the final roadmap looks like.


(click image for larger PDF version in context with thin-slices)

The entire project is scheduled to be developed in 34 days. That sounds hopelessly optimistic. Because road-mapping is such an inexact science, we will have to keep an eye on progress as development is under way. The schedule almost certainly will need to shift one way or the other. Let’s hope our developers don’t decide to take a vacation!

For a look at a full breakdown of features, thin-slices, and the proposed roadmap, here’s a PDF: USBank_Wireframes_Kade_r6_ThinSlices.pdf