Tetris in a New Dimension: Creating a Product Roadmap
After getting estimates on my wireframes with a developer, I was tasked with prioritizing the features to build first. Keeping the user in mind, I wanted to make sure I was delivering value, but keeping the flows very lean in order to build and ship them as soon as possible.
To do this, I returned to my wireframes with a critical eye and the words of my developer in mind. I balanced the user goals with the amount of time it would take to build out certain features in my flow. I discovered that my flows were already very lean and it was difficult to take out many additional pieces to create thin-slice flows.
Below is an example of one of the removed features. I took out the option to make a bill payment recurring for the initial launch. This feature would add an additional 10-12 days of build time. It is not necessary to have for the first launch.
In the end, I was able to take off 23 days of build time by creating even leaner flows for my thin-slice wireframes. Click on the following to see the entire estimate spreadsheet with changes made for the thin-slice flows: Estimates of Thin-Slice Flows Spreadsheet (Yellow highlights illustrate the changes made to the screens. Orange highlights show the changes in estimates for full flow based on new thin-slices.) View of all updated screens as thin-slices.
Developing Roadmaps with Varying Constraints
Creating an Ideal Product Roadmap
After creating my absolute lowest estimated build while retaining value, I realized that with two developers working at 40 hours a week, I would be able to ship my thin-slice flows in just about 4 weeks of production. To map out the flow of work, I created a product roadmap.
First, I created an Ideal Product Roadmap that illustrated the cascade of tasks that would build up to our complete thin-slice flow launch. This included the Login, Login Fail, Home and Accounts, Check Deposit, Pay Bills, Pay a Friend, and Spending + Budget thin-slice flows.
Each developer was tasked with 3 distinct flows and then shared the task of creating the Spending + Budget flow because of its estimated time allotment and number of visuals. I broke Spending + Budget into the Budget Breakdown section and the Past Spending Graph section.
For full details of the Ideal Roadmap, please click here.
After the launch of the thin-slice flows, I began adding back in the features that were de-prioritized for the initial launch. This included small tasks, such as, creating customizable buttons on the home page, adding a Favorites section to contacts in Pay a Friend, and being able to edit added payees in the Pay Bills section. It also included larger tasks, such as the Quick View visualization and the recurring payment feature.
In the Ideal Roadmap, I clumped these based on themes and time. That way we could ship things in increments that made sense to the user (see Fig 3). For instance, the first theme was around Managing Contacts added in the app. This included the ability to edit added payees in the Pay Bills section and included a Favorites section of contacts in the Pay a Friend flow. The second theme group was focused on visual implementations and included the Quick View feature as well as the donut chart of past spending trends in the Spending + Budget section.
Fig 3. Ideal Product Roadmap – Illustration of Clumping Releases into Themes. The first allows users more management over their contacts and payees in the app. The second provides more visuals throughout the app.
Below are the screens with the added visuals. While neither of the top visuals in each screen made the cut for the thin-slice release, both of them would be re-added in the phase 2 of releases. In the Ideal Roadmap, they are released together adding to the user’s experience of visual features in the app.
Again, because my flows were already very lean my whole app could launch within 45 days even with adding in the cut features that were taken out of the thin-slice flows (as seen in the Ideal Roadmap Fig 2).
Creating a Constrained Product Roadmap
After creating an Ideal Roadmap, I also created a Constrained Roadmap (Fig 6). In this scenario, I still had two developers working at 40 hours a week, but I needed to launch something in 30 day increments. Because this particular build was very lean already the change between the two roadmaps was quite small. I was still able to launch my thin-slice flows within the first 30 day launch, so that was great news because it meant that we would have a viable product within the very first launch.
To see a detailed version of the Constrained Product Roadmap, please click here.
However, the constraints did change was how I clumped the additional features beyond the thin-slice flows. Where I had clumped them by similar themed features, I decided to break up the visual theme release into the Quick View and the donut chart for past spending trends because of their length. In the Ideal Roadmap these two visual components would be released together, but since I wanted to get out as many complete features as possible in the 30 day launch, I decided to separate them. I was able to add the Quick View build up (Fig 4) to the 30-day launch because it was only three days long and would be able to be done by one developer at the end of the first 30 day period. I moved the donut chart past spending visual (Fig 5) to the phase two release (Fig 7).
Because my flows were already quite lean and my estimates for build time were pretty low, I thought I would have to cut entire flows, but actually managed to fit all the thin-slice flows into the initial build phase. I still prioritized these flows within that time period to make sure that if we decided to launch early we would have a viable flow with a login and home page.
I spent some time testing out different roadmap tools to see which one I could pick up the fastest. I ended up going with Product Plan, which gave me good control over dragging and dropping boxes, but I accidentally built everything out with time estimates and then realized that the timeline did not depict the weekends, so I had effectively scheduled over everyone’s weekend (not a good work-life balance). So, I went back and added weekend blocks into the timeline to depict weekends. There may be a better tool for that.
Another wonderful thing about creating a product roadmap is it allows you to use spatial awareness along with prioritization of tasks, user goals, and budgets. Creating a visual tool that depicts that tasks broken in digestible pieces that can be moved and placed into various spaces, allows us to find the best plan of attack for building out a product. It was like a huge game of tetris, but with another dimension–the dimension of priorities and constraints.