Discovering the world of product management

This quarter in Product Management

So far we’ve learned skills that have to do with design, business development, and production of technological products.

We started this quarter with an introduction to product management, method and skill (that will be added to our toolkit) and that aims to better prepare us to lead product planning and development from beginning to end. {the intention of having this knowledge is…}

Before this first assignment, the class had a brief introduction to the world of developers. For this, three guest speakers came to AC4D and talked to us about their ventures, process and current projects that they’re working on. From server configuration, to web development, to hardware software development, all three speakers shared their perspective of what it should take for us to have an efficient feedback session with a developer as part of a Product Management role.

For this assignment, we were tasked to show our baking wireframes to a developer so they could and facilitate a feedback session with them so they could size – assigning relative estimates to unique features, components and controls. Before this first assignment, which I will be telling you all about below, my peers and I already had a general idea that:

  1. Developers strive for efficiency, the more accurate information they can have about your product, the better
  2. There is no universal way to do sizing (developers all use different methods but the most typical ones are “t-shirt sizing” and “fibonacci sizing”)
  3. The estimated time it will take is almost never accurate, but it’s useful to have active conversations with the developers anyways because it provides clarity of what it takes to develop a mobile app to everyone involved in the project.

Break down feature and capability

In order to prepare the screens of my banking application for my meeting with a developer (and AC4D alumni – Chap Ambrose), I started by reviewing the screens that I had created in Q2. I started by separatating each flow into its own category, duplicating the screens that I needed to in order for the flow to make sense.

Sizing Exercise - 1
Sizing exercise: Preparing screen flows for walkthrough with developer

After this I started analyzing each screen in order to categorize them by feature (behavior of the system that directly fulfill some user need. Aka: “view account summary”) and component or control (system parts that provide and encapsulate common functions needed to implement features. Aka: “drop down list”)



Components breakdown_example
Example of screen annotation for component breakdown (“Account Balance” flow)


Features breakdown_example
Example of screen annotation for feature breakdown (“Account Balance” flow)

After doing this for each one of my flows, I started documenting each feature and control in a spreadsheet by assigning them a label with a name, a unique identifier and a description under each of those elements. All of this is done outside of the context of the wireframes so the could stand on their own. Each screen pertaining to my wireframe flow was also given a unique identifier that was added to the documentation of my components/features so that they could be easily referenced.

Out of context documentation
Documentation of each feature and component individually and out of context.

The whole annotation process ended up looking something like this:

Annotated screens

For a detailed view of all the annotated screens click here, for the breakdown exercise. here, for the entire breakdown.  

Sizing Session

After finishing preparing my screens, it was time to meet with my assigned developer to get a estimate for the development of my app! Activity otherwise known as “sizing” – a method for assigning relative estimates to unique features, components and controls.

Prior to meeting with Chap he let us know that the proper way to show him our screens would be directly in my Sketch file. So before our meeting I made sure my annotations were made directly in my file. Our meeting was in a coffee shop, he had his computer where he opened an Google spreadsheet ready to annotate information for each of my screens. As I walked him through the screens, he quickly analyzed each one of them and asked questions, shared concerns and made suggestions. After I attempted to clarify each point, he identified each screen on one of his google spreadsheet fields and gave it a number. I will share my learnings below:

Things I hadn’t thought of:

Source of data: The developer will need to have an idea of the source of the data that my app will use. Since I’m not actually employed by bank, nor I’m a bank owner, I had no idea how to answer where the data of the transactions will be coming from, or the source of the API’s needed for to make it actionable.

Things I didn’t know:
  • By now I know that each developer has a way to measure how long it’s going to take them to complete a project. In class we were introduced to the concept of sizing using t-shirt sizing and the Fibonacci framework, but my developer used “points”.
  • API knowledge: There were a lot of questions regarding data sources which I had no idea how to answer, but definitely gave me a notion of what types of questions I would expect from another sizing conversation.
  • Legal concerns, due to the nature of the project – Banking Application -, there were questions around how safe it would be to handle private type information like a banking customer.
What I will do better next time:
  • Time management: Ask beforehand how long it will take to go over a specific amount of screens to know how much it will take to go through them during the sizing session.
  • I would have liked to have had an intake form with each screen number so I could take notes for each screen in a more efficient way.
  • Missing screens: there are a lot of interactions I did not think through when building the screens for my app. Many of them have to do with edge cases that I did not take the time to come up with. To do this, it is advised to spend some time analyzing each screen and come up with different scenarios that could trigger different responses.

Unfortunately, the meeting had a hard stop after exactly one hour and I had more screens that we did not have time to go over. But at the end of our meeting I was able to get a high level estimate of how long my app will take to be developed.

Screenshot of estimate spreadsheet (Flows “Account balance” and “Pay someone”)

For a view of the entire sizing spreadsheet, please click here.

Fields highlighted in orange are missing screens that the developer did not know how to estimate. I also learned that, the less unknowns the developer has or detects in the customer (myself in this case) the more likely he or she will be to double the amount of time it would take for the app to be developed. Considering that I potentially had only 50% of screens of the entire system I was given an estimate of 120 days of work (excluding questions marks, aka: screens without wireframes).

Next Steps

After this exercise, we will share our learnings in class and get feedback which we’ll then use to create a roadmap to plan for our product development.