Mapping Our Road
This week in our Product Management class, we took a harder look to the designs we had developers estimate last week, parring them down to a more economical size, and creating a roadmap for development.
There were four parts to this process, which I will talk through in more detail below, and a number of learnings, which I will share at the end of this post.
Part 1: Trimming the Fat
After my meeting with my developer, I learned a lot of interesting things about the amount of work that would go into developing some of the features of my app. A number of my assumptions were tested as I found that some features I considered small and insignificant would take much longer to develop than I anticipated. And vice versa a number of things I imagined would be complex and take much time to develop were estimated to take less time to create than I thought.
This added an interesting element to the value of each of my features and even to each of my flows that for the first time was not based solely on the needs and convenience of my user.
To understand this I printed out each flow of my wireframe as well as the estimates provided by my developer. I then wrote down the time he gave me as an estimate on each screen and each feature that he gave me an estimate for.
Once I had everything estimated out, I walked myself through the entire app to weigh the cost (in the amount of man days something would take to create) against the value of a feature, screen, or entire flow to my users.
Some features, screens, and flows were very easy to cut as they took a lot of time and I observed that they were not very important to users in user testing. For instance, you will notice in the image above, I have completely cut the ability to choose a frequency with which to transfer money from one account to the next. Each option of a frequency (i.e. monthly, weekly, daily) would take the developer 3 (wo)man days to code and the calendar feature which allowed users to select and end date to their recurring transfer would take another 3 days to code. Knowing that this was not important or essential to my users, I cut this feature and the screens associated with it, trimming the fat.
Part 2: Mapping It Out
Now that my wireframes were trimmed down, I worked to group and then name features and screens as tasks for developers.
In this way, I was able to identify how long each flow would take and then could add some additional data for prioritizing flows before others, outside of the information I learned from my user interviews.
In the process of considering what I learned in my user testing, I began to prioritize what was essential for the users I spoke with, what wowed them, and, ultimately, what would need to go into development first. I started laying this out into a roadmap using a tool called Teamweek.
SIDENOTE: I looked at a couple different options of roadmapping tools and ultimately settled on Teamweek because it was free, it was very intuitive, and it had the ability to be synced with Slack and Google calendar and offered a feature called “Button” which allowed you to link tasks and the entire roadmap to other tools like Trello, JIRA, etc.
I laid out all the flows that still existed after I trimmed the unessential bits of my app, dividing to development duties between two developers I assumed were working 40 hour weeks. I created the roadmap that you see below.
This new parred down app appeared that it was going to take. In the end, it appeared that even in this parred down state, my app would take 8 weeks and 40 (wo)man days between two developers to create.
Part 3: Creating an Ant out of the Ant Hill
I had been tasked with identifying the features that were most essential so that there could be some semblance of an application in production 20 days into development. Though difficult to reduce the capabilities of my app by a more than significant amount, I had already arranges my Product Roadmap in terms or priority. So the experience of parring it down by half again was more simple of a decision than you would at first imagine, because I had already thought through and organized features and flows based off of importance.
You can see my updated reduced roadmap in a larger version here. The final three flows that were left after this cut were my Log-in and Check Balance flow, my “Transfer Money” flow, my “Deposit Check” flow, and the basic functionality of my “Set Alerts” flow.
SIDENOTE: In doing this, it was very difficult to evenly divide and fit all tasks neatly into days and weeks while also considering the sequence in which they may need to be developed (some features needing to be created before the next).
Part 4: To Infinity and Beyond
Now that I had a finalized roadmap of my first 20 days of development, I began to consider how to plan out the remaining weeks and months of development so that my app would ultimately include all the features that I had in my initial thin slice, and then hopefully eventually include most all the features I had in my very initial wireframes.
For this, I turned to Trello, mostly because I have used Trello in professional roles previously and found it to have all the functionality I wanted for illustrating and tracking progress on development over time. You can view my long term roadmap on Trello here.
I grouped the tasks I had created for my developers into two week sprints which I lumped into lists in Trello. I named the list for current sprint “In Progress,” the next sprint “Up Next,” and the third sprint “Confirming.” With the first 6 weeks organized, I created two additional lists: one called “Exploring” and another called “Icebox.” “Exploring” is a list of all the features that are left to be developed after my initial cut. All of these features have production dates associated with them that could be adjusted based off of progress in the first three sprints. And, the “Icebox” is a list of features that were a part of my initial wireframes that are in a metaphorical icebox until we get some of the more essential functionality of the app created.
There were a number of learnings this week which provoked questions that I have and hope to answer in the following weeks.
- In Product Management, you’re going to have to make tough decisions – I had to make a number of tough decisions this week. They all fell into one of two categories.
- Decisions that could disappoint the user
- I had to cut many flows from my initial wireframes using the limited information I had from my user testing to consider what was most useful and valuable for my user. If given, I would have taken a little more time to do user testing before eliminating the amount that I did.
- Decisions that could disappoint the stakeholders ($$money makers$$) in my company
- There were a number of times that the estimation given to me by my developer exceeded the amount of time that I had left to allocate for a task. Rather than risking leaving my developers twiddling their thumbs, I decided to assume they would run ahead of schedule and be able to complete some tasks a day early. This is a risk that could leave the company in a bind, either over budget or with an incomplete project.
- Decisions that could disappoint the user
- Developers are really important for making things – I knew this. They are the ones who will ultimately be working to bring our ideas to life. But it was not until this week that I realized there is most likely an indefinite amount of information we can learn from them in order to create designs that meet the budgets of our companies and fulfill the needs and desires of our users. I wish in my meeting with my developer I had asked for more specifics around some of the estimates he had given me for particular screens. Was there a feature of a screen that I could consider adjusting or eliminating so that I would not have to forsake an entire flow but could just get make a change to that feature?