Roadmap to launch

Following our meeting with developers we were able to gain an understanding to the feasibility of our banking app design. The next step is to develop a plan to move forward. The real world has constraints, and in an agile framework the goal is to have a product in someones hands quickly. 

Since meeting with the developers I’ve focused on scaling back my functionality to a thin-slice hero flow containing the most concise version of features to execute the core features. After  down selecting the features, I created a product road map to illustrate the allocation of work divided between 2 developers and a second product roadmap focused on rolling out the app in 30 day increments (40 hours per week for 4 weeks a month)

Product Road Map (Thin-slice hero flow)

Thin slice hero flow

My fist step was to go back through my wireframes and edit the complexity of features. When I met with Caleb, the developer, one of my goals was to gain insight into how much additional time it takes to create features that create convenience. For example, instead of obtaining an estimate for depositing a check with the phones camera I obtained an estimate for auto-capture of the check by using edge recognition technology. I structured our conversation so that I could illustrate the complex version for an estimate and discuss estimates for the most basic way to achieve the same goal. View my developer estimates here.

After down selecting to simplify the path to reach the same end goal, I ranked the tasks within the app according to importance. In keeping with the original vision, I included the budgeting features at the end of the product roadmap. 

Within the product software, you can view further detail of the step by hovering over the colored bar, or you can click on the bar to gain access to. more. information. I included a sample below since this isn’t visible in the samples below.

Hover view


30 Day Increment Product Roadmap

For the roadmap containing releases every 30 days, I identified the core activities required in the app: Checking your balance, viewing transactions, and depositing a check. Transfers and bill pay are important features that could contain placeholders referring clients to the website in the short term. Once I decided on the first set of activities, I segmented out time allocations for the convenience features that could be added at a future time. Physically, I completed this stage using 3 colors of posit notes listing the activity, time required, and screen number colored according to the immediate, intermediate, and long-term implementation (below). I later transferred that into Product Plan software.


One important factor to note is that the product roadmap includes front end and back end work. Below you can view the roll out over 150 days. 

First 30 days30 days

30-60 Days

60 days

60-90 Days

90 days

90-120 Days

120 days

120-150 Days


0-150 Days

Product road map 30 day sequence

The map with 30 day increment was very enjoyable to make. When releasing every 30 days, it began to make sense to build out “placeholder screens” directing the user to go to the website to make transfers and then reserving the opportunity to build this out further at a later iteration. To me this was very representative of a real life situation. My mid-sized bank in Chicago was recently acquired by a larger bank and over the past months I have been able to observe a similar situation where new features are slowly being rolled out. Next up: Payments through Zelle!