Creating a Product Roadmap for the Velocity Credit Union App

This week in Product Management, we took on the task of creating minimum viable product (MVP) versions of our banking apps and then creating a product roadmap planning how all the features for the full release of our banking apps would be built out.

The Purpose of the Thin-Slice Flow or MVP

First, a word on why we would even bother creating an MVP. MVPs are the leanest versions of your product that can still deliver value to users. Product managers are wise to have staged rollouts of versions of their products (from minimum viable product all the way to full release) for a few reasons. It enables them to begin to deliver value to users sooner. It decreases risks as the team has earlier opportunities to adjust their plans in response to user feedback and behavior. Finally, it can enable them to potentially start earning money months or years before the full vision of their product is built.

Creating My MVP

With all that in mind, I set out to figure out what the minimum viable product for my Velocity Credit Union app would be. The standard process for doing this is as follows:

  1. Start with your idealized, fully built-out flows. In this case, I am using my Pay a Bill to a Saved Payee Flow as an example.
Original Pay a Bill to a Saved Payee Flow
Original Pay a Bill to a Saved Payee Flow


2. Eliminate (by literally x-ing them out) as many features as you can while still leaving something functional that delivers value to your user.

Rough Cut of Pay a Bill to a Saved Payee Flow
Rough Cut of Pay a Bill to a Saved Payee Flow


3. Create new visuals of your remaining flows with the eliminated features taken out.

MVP of Pay a Bill to a Saved Payee Flow
MVP of Pay a Bill to a Saved Payee Flow


My rationale for the pruning I did for my MVP was that I should retain only the most basic features one would expect to find on a banking app that would allow you to never actually have to go to the physical bank, such as checking your balance, depositing a check, paying a bill, transferring money, changing your password and contact information, and choosing how you would like to receive fraud alerts. These relatively few features cover most people’s most common banking needs. They do not include Person to Person transfers because I figured that most people will probably already have Venmo anyway. They also do not include options for planning ahead such as setting up recurring transfers or my Safe to Spend flows. Those sorts of financial-planning functions I left to later versions as you’ll see in my product roadmap below.

How to Build a Product Roadmap

Product roadmaps exist to create alignment around which features should be built when and by whom so that the whole product team knows the schedule for what is being worked on and when different versions will roll out. Though it is meant to be a living document (especially past the near future of the next 3 months), it helps everyone to have an idea of where the product is headed and what their priorities and daily tasks should be.

To create a product roadmap, I first took all my features and described them in greater detail so that someone other than myself could figure out the capabilities of each feature and the value they deliver to the customer.

Screenshot from my spreadsheet with the sizing of all my features
Screenshot from my spreadsheet with descriptions of all my features

Then, I placed all the features on cards sized according to how long my developers have estimated the features will take and arranged the cards in the order they should be created (according to the dictates of the company’s priorities and what made sense from a functional standpoint).

My Feature Cards, including capabilities and sizing
My feature cards, including capabilities and sizing

Next, I assigned each feature to be built to the resources that will create them (in this case, developers). For this part of the process, I prioritized releasing versions as quickly as possible, which meant that I made sure that the same developer was put in charge of creating similar features (such as two versions of calendars) since they would be better able to piggyback off of their own work than if the calendars were assigned to two separate developers.  

Feature cards as assigned to different developers
Feature cards as assigned to different developers

Finally, I indicated when the key release milestones would occur.

Here is the roadmap as a whole:

Product Roadmap
Product Roadmap


Version Rationales


As I stated above, my rationale for my MVP was to include all the most basic banking features, but omit most of the features that would allow someone to plan ahead or use Person to Person payments. Refer back to “Creating My MVP” for a longer explanation of my choices for this version.

Version 2

For my version 2, I wanted to include more “set it and forget it” functionality. For instance, I included the features that allow for scheduling transactions in advance, recurring transactions, and setting alerts. These features deliver more value to the consumer by enabling them to not worry about their financial situation unless they receive an alert (they’ve created) telling them otherwise.

Version 3

Version 3 of the VCU app allows for more convenience. Rather than switching out of their banking app and into Venmo, users would be able to use P to P to make financial transactions with friends while retaining transparency about how those transactions are affecting their balances. Version 3 also allows for smart searches among contacts and common bill payees and Touch ID sign-in. 

Version 4: Full Release

Version 4 builds on the “set it and forget it” features first introduced in version 2 by adding the Safe to Spend and Ways to Save features. These features actively warn users about possible financial problems even if users have not taken the time to set up alerts. They also help the user create long-term spending and saving goals that increase the user’s odds of achieving better financial security. In other words, in the full release, users don’t have to look out for their own finances; the Velocity Credit Union app does it for them.


This exercise was interesting given all my conversations with product managers in the past few weeks. They all told me that past 3 months, one’s product roadmap starts to reflect reality less and less, and that past 6 months it amounts to essentially a wishlist. Applied to my own work, that would mean that only my MVP would fit within that window of a relatively predictable future. This is better than the alternative of my MVP straying into the murky, unpredictable future, but demonstrates to me how long (at least for a banking app) it takes to produce even the most basic functions. Thinking about the other project I am planning now, the KeyUp mobile app, this exercise has emphasized to me the need to pare down my expectations for what we will be able to create as an MVP. Reining in my completionist tendencies has never been my strong suit, but seeing the actual calendar for how long all these features would take certainly helps.