Product Manager Hat: Creating a Roadmap
For the first part of our Product Management project I met with a developer to estimate how long it would take to build the banking app for which I designed hero flows and user tested in the second quarter. During that conversation, the developer gave an estimation for how long each screen would take to build, the reasons why, and a few suggestions of what to do to make a few flows more attainable than others. If you’d like to take a look at the previous process, you can go here.
The next step a product manager takes after sizing an application the way we did with our developers, is to reduce the scope of a hero flow to fit into the development timeline that is available. This is done in order to plan how to build the application by removing features but by making sure that it continues providing value for the user. This keeps app building planning realistic but still focused on the product’s vision.
According to the developer’s estimate, it would take 120 days to build the banking application, aka: the flows that were shown to him. In order to ship a product faster, we need to take certain steps to make sure we remove certain features from the application now, but without removing basic capabilities that allow function and user satisfaction.
Revisiting hero flow
I revisited the hero flow with the printed excel spreadsheet that had the estimate my developer gave me, I went through the screens, and basing myself out of the time it would take to build each one, I would make the decision to either cut down several features in one flow or let it as it stands.
Original hero flow for “Accounts” looks like the one below:
Rough cut thin slice flow
Due to the conversation I had with my developer and basing myself out of some of the usability testings I did with potential users, I decided to cut down the “search” feature because I now that it’s something that users seldomly use. I also decided to remove the “credit limit bar” simply because it needs more visual design work. I also removed “make payment”, “money field” and “calendar” because this is a capability that can be found elsewhere in the app by going to “Move Money”. Having those features there only makes it more convenient to use. You can see an example below:
I crossed out each feature that will not make it for the Minimum Viable Product launch and then calculated how much it would take to build after that first round. There was a lot of back and forth doing this exercise, but was finally able to cut down development days from 120 days to 60.
The “Accounts” flow rough cut ended up looking like the image below:
New thin slice flow
After revisiting my hero flows, I went on to the next step and modified the wireframes according to the changes that were made during the rough cut, turning it into a thin slice flow:
You can take a look at all of the thin slices here.
Capability Description and Sequence
After defining the thin slice flow, a detailed description was provided for each of the features and placed in sequence. The capabilities are arranged on top of the timeline previously determined for each one of those capabilities that will be built under the MVP launch.
The same process was used to define the first and second launch of the app.
After finishing the rough cuts, I had everything needed to start putting together the product roadmap by illustrating the sequencing of the key product changes that I decided to make in order to adapt to capacity constraints.
The minimum viable product launch for my banking app is 60 man days, considering I will be having 2 developers working full time, this means the MVP will be launched in 6 weeks. After the MVP release, I will be launching features every 30 man days, aka 3 weeks.
You can take a look at the roadmap development process here
What I learned:
- Designing a full vision is important to have as a guiding star, but taking into account how features can be removed by sets without removing value is a strategy worthy to have in mind.
Things I could have done better:
- Be more detailed when note taking details for a specific screen. Providing more detail on the developer’s rationale about what can and cannot be done could better feed my decision making process to cut down features. This is only if there is no in-house developer available.
Next up, we will be reviewing our roadmaps during class and then we’ll continue developing a strategy brief to bring this app to development.