We are moving forward with our Banking Apps initiatives. Every student goes in their own direction. Starting at the same place, now we got totally different apps, estimates, timelines.
Slicing it thin, with a cherry on top.
After doing a one-hour-long estimation together with a developer we were challenged with creating a roadmap for the app. In Q3 we learned about MVP – Minimum Viable Product (also called a “thin slice”) – the minimum set of features bringing value to the user. This quarter we also learned the term MLP – Minimum Lovable Product – that I believe makes a lot of sense taking in attention the abundance of competing products on a market.
It was time to decide what is my “thin slice” and what can wait until later.
I felt like it’s finding a right balance between the three factors:
- The importance of the feature for the user
- Level of effort that goes into creating the feature
- And the “layers” into which the feature can be sliced down to
- The “delight” aspect of the feature, even if it’s not very important
I knew that I need to roll out the V1 with a truly minimal set of features, and the features being thin-sliced, – which should require as minimal effort as possible, while still being a “minimum lovable product”, – which is where the “delight” aspect comes in. While having barebones functionality, there has to be something “different”, too, to make sure the user installs it.
I also needed to know the type of persona who would use the application – or the “thin-sliced” version of the application. The “scooter” version of what will become a real car. I quickly came up with a very real use case, and built a storyboard around it, displayed below.
Tanya really wants to keep an eye on her financial situation and the most convenient way for her to do so is through the mobile app, especially since she’s always on the go and rarely near a computer (and never near a computer during her work days as a nanny). She makes sure she has enough funds to get to the next paycheck, ensures there’s nothing fraudulent, and also self-analyzes her own spending habits looking at the transactions.
Breakdown of features and functions.
The core functionality of the banking app to a user like Tanya is exactly what went into the thin-sliced v1:
- Your Bank Account And Info (eg balance)
- List of Transactions and Transaction Details
- Basic miscellaneous info (contact us, ATM & branch locator, FAQ, legal info)
For example, Login Flow is being released partly in V1, partly in V2:
Accounts flow will be completely built only at 3rd iteration:
Here is my Sketch file for more details!
The last item in the list stands out. It’s not “essential”. However, that it something that may be very different from the other banking applications around – an ability to effectively communicate with a bank representative through chat – which is the preferred method of communication of many people these days (millennials especially). Additionally, according to my developer, a basic version of chat doesn’t require a lot of effort, – and I decided to include it in V1.
The next set of essential features comes in v2:
- Foundational Move Money Framework
- Bill Pay
- Check Deposit
- Transfers Between Accounts
- Alerts & Notifications
- Smart Personalization
- Touch ID
Similarly, most of the features being essential, with a couple that is nice-to-have and making overall experience much better: Smart Personalization (mostly applied on the homepage and adding the bits of delight through the use of user’s first name and pulling a shot of the picture the user is living in) and Touch ID.
Main flows such as Bill Pay and Transfer Between Accounts are fully built except the ability to Add the Transaction in Favorites and Set Reccurence. Check Deposit also doesn’t allow to add the transaction in Favorites.
The third and later versions have just a couple of essential features in it, and most of the things are now big differentiators from the competition:
- Send/Request Money
- Wire Transfers
- Favorite Transactions
- Future/Scheduled/Planned/Projected Transactions
- My Goals
I used the original estimation sheet to map out the features (or, for some, “screens”) into the versions of the application. (click here to open the image in a larger view; the legend is at the bottom).
I organized the features and the effort in man-days into an actual timeline spreadsheet. Below is the “printout” of the spreadsheet (click here to open the image in a larger view):
Looking back, one thing I would have done differently with the developer is to ensure the estimate is getting done based on features, not on screens. Right now, if a part of a separate feature is included on a screen, it would be a part of the estimation of the said screen. That is not ideal when you’re building a roadmap and removing the slices of the product.
So, when creating the roadmap, I aimed to build it all up based on features instead of screens; and a feature may by itself be just one screen or multiple screens, but also may be a part of many other screens that have another “base” feature in their core.
One other thing I was thinking about a lot, but then learned from developers as I have been going through the exercise, is that every release requires extensive QA, when the developers (and ideally QA engineers) ensure the quality of the product and together with the product managers or product owners polish the functionality for best customer experience. I made sure to include time for QA and Polishing into the timelines, which accounts for 10-20% of the feature development time, largely depending on the complexity of the features. I also made sure to do releases on Mondays only; releases on Fridays are the worst nightmare of developers, – since if something does go wrong, it’ll happen over the weekend. On Monday (or mid-week), everybody is available and around to support the release and fix any possible issues quickly and efficiently.
The class has taught me a lot about what it takes to create a product, or, rather, plan to create a product. I’m enjoying learning more about it and am eager to move further!