Product Management Part 1: Development Estimation
For the past few months, we’ve worked to redesign AT&T’s mobile app. The process has included research, concepting, sketching, and wireframing, evaluation, & iteration. The next step of the process is product development — bringing the app into reality.
Design vs. Product Development
As designers, we are user-centered; we focus on people, their goals, and the way the design will support their experience in achieving those goals. Design is all about visualizing an ideal state and sketching our way to that future.
Once we get into production, however, we must also be technology-centered. “Shipping,” or product development requires the product manager to be pragmatic as she brings the product to market.
While the design process is all about the user’s behavior and feelings, product management zeroes in on the system’s components, features, and controls.
The first step to shipping is consulting with a developer. While designers love to play in ambiguity, developers tend towards “well-defined” problems, strive for efficiency, hate to do the same work twice, and guard their time.
Although these two mental frameworks may seem antithetical, it helps the designer move from “blue sky” to “realistic,” consider reusable components (leading to efficiencies), and get ready for sizing.
Sizing is a method for assigning relative time estimates to build unique features, components, and controls. Sizing helps guide priorities, identify total time on task for a development effort, and steer redesign efforts to quickly launch the product.
Sizing, despite being often being wildly inaccurate, 1) provides clarity to stakeholders who have to commit to delivery (to a board of directors, for example); 2) provides clarity to marketers, who need to build campaigns around delivery dates to understand an order of magnitude for producing a product; 3) gives the entire team a view of the product, so they understand it thoroughly; and 4) forces detailed interactions between the designers and developers.
To size my wireframes, I walked my developer through my flows, and he estimated how long it would take him to create each component, screen by screen. He gave his calculations in “man days” (a man day being equal to one day of work for one person), and estimates ranged anywhere between a half day to 3 days.
Then, I asked my developer to estimate how long it would take two developers to create each flow. To my surprise, instead of simply halving his calculations, he divided them by 1.5, to account for sick days, inefficiencies, or unforeseen roadblocks.
As, again, sizing is often inaccurate, I then took his calculations and added a 30% padding to each, a common practice among product managers. You can see calculations illustrated below, as well as in this spreadsheet: myAT&T redesign estimation – Sally
As of the latest calculations, production would take 51.5 man days. The next challenge will be updating the design to only require the allotted 20 man days. Stay tuned for Part 2: Thin Slicing & Road Mapping.