Building a draft of a product roadmap: How to (and not to) do it

As a follow-up to my blogpost on feature and capability and sizing summary, I am going to discuss my process for building a product roadmap for the TD Bank Mobile App I wireframed in quarter 2. A product roadmap is a visualization of how a product builds over time. This means that I had think strategically about what features to build first, second, third…up until the entire application is “done” (even though nothing is ever done!). I will describe my process as follows:

  • Building a thin slice flow
  • Mapping out capabilities
  • Building a draft of a product roadmap
  • Reflections

Building a thin slice flow

The first step of building a product roadmap is by determining what thin slice flows I will start with. A thin slice flow is a pared down version of a hero flow. This means that the flows I will build will be minimal, yet a user can still find the experience valuable. For this, I started at a high level. I asked myself which flows are necessary and which ones can be built later. The full list of flows are as follow:

  1. Login
  2. Check balance
  3. Mobile check deposit
  4. Bill pay
  5. Quick pay
  6. Transfer
  7. Settings
  8. Support
  9. Safe to spend

Since users primarily come to their banking app to check balance, pay bills and transfer money, I will include these in the first version of the banking app. I will also include paired down versions of Settings and Support since these have basic necessary features like FAQs, change password, and getting live support.

After determining which high level flows I would hold off on, I dove into Login, Check Balance, Bill Pay and Transfer. Below, I will discuss what I chose to leave out in version one with a rationale.

Login:

I left locator and sign up features on the login screen. These will take time to build but aren’t valuable for loyal TD bank users. I also crossed out all buttons and references to features that won’t be rolled out until later versions. I also took away the fancy “Good morning/afternoon” feature since that is necessary.

Check Balance:

Since the primary use of check balance is to be able to see a list of recent transactions, I decided that being able to view and download a PDF for past statements will be a feature I will add later.

Bill pay:

In the thin slice flow, users will be able to pay their bills to any payee, but it will only be a one-time bill pay. Developing the scheduling feature will take too much time. I will also be able to leverage the “Add a payee” feature in the transfer flow.

Transfer:

Much like Bill Pay, I will keep this to one-time transfers, though users can transfer internally or externally.

Settings:

Version one will only be available in English.

I have included visualizations of the original flow,s a rough cut flows (where I indicate the features and components that I will add in later), and the final thin slice flows.

Login Flow
Login Flow
Login Rough Cut
Login Rough Cut
Login Flow
Login Flow

 

Bill Pay Flow
Bill Pay Flow
Bill Pay Rough Cut
Bill Pay Rough Cut
Bill Pay Thin Slice
Bil Pay Thin Slice
Check Balance Flow
Check Balance Flow
Check Balance Rough Cut
Check Balance Rough Cut
Check Balance Thin Slice
Check Balance Thin Slice
Settings Flow
Settings Flow
Settings Rough Cut
Settings Rough Cut
Settings Thin Slice
Settings Thin Slice
Support flow
Support flow
Transfer flow
Transfer flow

Mapping out capabilities

Next, I mapped out capabilities. This means I took all the features that I want to build for version one, laid them out and prioritized the order in which they will be developed. You can see a visualization of this below.

Layout Capabiities

Then, I printed and cut them out to determine how to distribute the work between two developers who each work 40 hours weeks.

Maker:S,Date:2017-12-7,Ver:6,Lens:Kan03,Act:Lar02,E-Y

Building a draft of a product roadmap

Finally, I built a draft of the road map. It proved challenging to build a stand-alone visualization I could easily send out to a team. How do I make it accurate, reflective of time, and readable? Honestly, I think it starts earlier in the process. As I learn how to work with developers, influence their decisions, and think about how a product builds value over time, I think I will be able to more accurately build a stand-alone map. In the end, I also decided not to map out Safe to Spend. It was the riskiest feature of my app and to develop anything of value will take 8 months (!). I can’t think of a good reason to develop my Safe to Spend feature. In the end, the whole banking application will take about 12 weeks to build (?!???). You can see my draft below. Gray represents the first release. Red represents the third release. Blue is third. Green is the final release.

Roadmap 1 Roadmap 2

 Reflection

As I continue to develop as a designer, I know I also need to learn more about software development. In the end, I do not think my roadmap is accurate. There’s no way that I could build a whole banking application in fewer than 12 weeks. Though I based my information on the initial conversation I had with a developer, I do not think that I have enough detailed information on individual components and features, nor do I have accurate data on how long each feature estimate. I’m excited to learn more about software development as I continue building my skills as a human-centered designer!