The roadmap is not the territory… but it sure is helpful.
When you estimate that it will take the better part of a year and most likely hundreds of thousands of dollars to develop an app, where do you even start to break ground?
In the fall, I redesigned the Wells Fargo app with rapid prototyping and ideation. This quarter, we picked our bank app redesign projects back up and began planning how we would get them developed. The first project was to estimate the scope of the project. I blogged about that experience in this post. Now, the task is to take that estimate and turn it into a plan.
The word people use in industry for a product development plan is a roadmap. It lays out the scope and sequence of a products’ parts that engineers will develop as they bit by bit make the vision a reality.
How do you create that plan? That was our task.
Our only real constraint in creating the plan was that we had two developers working full-time, forty-hours per week. Other than that, our main task was to identify some rationale for sequencing parts of the product in a particular order.
The Thin Slice
Though we planned to develop the app piece by piece over time, as is the case with all software, we needed to plan for our releases. Each release is a new version of the product that internal or external customers will have access to use. That being said, each release should be composed to be valuable in its own right.
One of the primary releases to consider is called the “thin slice”. This is a version of the product that is literally a slice of what the full release would look and feel like. Sometimes called the “minimum viable product” (also called an MVP), a thin slice of a software application is a version that embodies the essence and value of the full version with the least production cost. I will be using the terms MVP and thin slice interchangeably throughout this post.
By defining and creating a thin slice, it allows a company to aim for delivery of a product version that customers will enjoy as fast and cheaply as possible. By getting the product to customers fast, product managers can assess if the value proposition they projected holds true or if their take on the solution resonates with their target market. If a company invested all its funds in the full release without aiming for a minimum viable product, they could easily find their money wasted if they were even a fraction off the mark. Creating quick releases instead gives companies time to redirect efforts or even double down on positive market reactions.
Defining the Wells Fargo Thin Slice
Though we didn’t have a time constraint required, I decided to aim for an MVP release about halfway through the full release development. Since we estimated the development to take about seven to eight months, I decided to fit in about three to four months of development before releasing the thin slice.
To define what fit into this three to four month development window, I first reviewed the estimate I developed with a consulting developer two weeks ago.
From this list, I had about forty different components to develop
Which should I roll into the thin slice release? Which components or flows should I roll into subsequent releases?
To prioritize items, I relied on a few organizing principles. First, some simple features are just logistically and technically required for a banking app to be valuable to a user. No one will be able to use a banking application that won’t let them sign in – an app needs authentication. It needs navigation. It needs the basics. All those items get first dibs on the MVP.
Next, prioritize table stakes items like account summary, transaction review, and bill pay, transfer money, and mobile check deposit. These days, those capabilities are the least a customer will expect from a banking app.
Beyond the basics and the table stakes items, I felt it was necessary to incorporate some features that could differentiate the Wells Fargo app and create a superior value for customers. Three features that I decided to roll into the thin slice included Card-Free ATM, Fastlook, and my Favorites feature.
Each of these features provided convenience in novel ways. When I mentioned them to others, many people had never heard of these features but thought they were “cool”. The “cool” factor is gold in the world of product, and I took that cue to include these features in the thin slice.
With these principles in mind, I went through the list of features and flows to develop and indicated priorities regarding what made it into the MVP or not. Then I scanned the spreadsheet and assigned a sequence to the items within the MVP and after the MVP. I reviewed the sequence to be sure it made sense from both a technical standpoint (would feature b even work if feature a weren’t developed yet?) and a value standpoint (would customers really prefer feature d over feature c?)
I cut out a number of features from the original flows, including Make a Spending Scenario flow and Balance Alerts. Many of the features I did not include were in the original scope but I have not yet created wireframes for them. I therefore didn’t need to cut these out in my “rough cut”, but I did need to modify the menus to exclude them.
Once I was satisfied with the feature sequencing, I moved these items into a road map.
The spreadsheet could have been enough for some people, but it’s a pretty terrible visualization tool. Roadmaps are meant to communicate and refine project plans, guide teams, and persuade investors or others of the soundness of your plans. The majority of communication is visual. According to landmark studies by Dr. Albert Mehrabian often referenced in communication studies and in discussions about presentation techniques, as much as 53% of communication is visual, and only 7% is verbal.
With this in mind, to create a roadmap, we visualize each component as a block with a length proportionate to the duration of time it takes for engineers to develop it, and we lay the components end-to-end for as long as it will take to develop all the components. In doing this exercise, we lay down the road that will lead us to a finished product.
For our exercise, we have two developers, so there are actually two lanes to our highway.
One decision I made in developing this sequencing was to assign certain components to each of the developers. Some component structures, like those in the Make a Bill Payment flow, are very similar to others, like the ones in the Transfer Money flow, so it makes sense for the same developer to work on both components. On the other hand, many of the features to develop are generic to many apps, like Authentication, Change User Name, Set-up Touch ID, and Change Password, while other features are very specific to banking. Assuming that one developer may be slightly (or much) more experienced in banking specific protocols and development, I assigned the developer labeled “Resource 2” with the majority of banking specific features.
Because the roadmap is so long, I needed to cut it into pieces for the purpose of including it in the post. I used natural breakpoints to cut it up. These breakpoints are the places where I planned releases. The first three releases are part of the MVP, and the last two are subsequent to the MVP. The figure directly below illustrates these parts.
Each release encapsulates a set of features that provide a set of viable functions. Release 1.0, for example, has the minimum necessary to be a useful banking app, including authentication, account summary, and transactions review.
Creating a roadmap has been exceptionally educational. One reason it was so beneficial for me was that it provided another opportunity to think visually and express project plans visually. I have spent plenty of time with just words and numbers in spreadsheets, and expressing those values spatially gave the same information much more meaning in the context of project planning.
Another lesson I learned is that it’s important to get detailed estimates. This was something I did not do. With only an hour to develop an estimate with the developer, I often only had broad strokes to work with. For example, the mobile check deposit would take “80 hours”. What if I want deliver just a slice of that feature in the MVP? I don’t know what any single part of it costs, so unless I consult a developer to get a more detailed estimate, I’m somewhat resigned to keeping it whole. That inflexibility puts unnecessary constraints on my project planning creativity.
We had a visitor come to our class last week named Jaidev Amrite. He’s an experienced product manager and gave us great insights into the world of product management. His number one tip – if you don’t become the product manager, be sure to make friends with him or her. Working through these exercises has made it loud and clear how critical and influential the product manager can be in an organization. Having learned more about the PM’s role, experience, concerns, and language, I can certainly appreciate why and how to be an ally to one.