In Q3, we learned how to identify what must exist in order for a product to serve its purpose (the “minimum viable product.”)
In Product Management, we are learning how to take that MVP and match it to human constraints: The labor available to build the thing.
We had two challenges this week: Produce a “thin slice” (or, streamlined) version of our ideal app, and map it to worker days; and then trim it again, to match a constraint of 40 work days total (or: a team of 2 developers, both available to work 20 hours).
After meeting with my developer, I’d already trimmed quite a bit. But my developer had given me a wide time estimate re: how long building my flows might take.
Here’s what I learned-and-built:
I. Pad extra time around your estimates for unexpected delays
I choose to map my flows to the 1.5x padded points estimate—my developer was reasonably sure he could execute what I was looking for (cutting out my need to map the “extreme case” hours), but it’s good practice to follow the rule of projects: Something will always go wrong. So I chose a medium-padded version to be confident that my MVP banking app will be achievable.
II. Develop minimum success criteria for each task for clear milestones
My developer estimate sheet matches each screen to the hours required. My next step was to enter each capability into roadmapping software, and include logic criteria: What each screen must be able to do to be successful (in an MVP version). I tagged those criteria to each task, so my developer team would have them at hand while building.
III. Map each task to time estimate for sequencing
First, I mapped time by flow: Login, Accounts (passive: viewing), Accounts History (active: scrolling & downloading), and Deposit a Check. I included a milestone after each flow, signaling when an end-to-end experience was complete.
I sequenced the build by base-level need (i.e.: Login, followed by passive Accounts viewing, into more active actions).
I set the project kickoff to April 1, and gave my developers weekends off ;).
When mapped, it became clear that the deposit flow took nearly the same amount of time as all the other flows combined. I had mapped to flow tasks, because as a product manager, this is most intuitive for my purposes (checking to ensure sequencing is correct). But it occured to me that developers may work better looking at flows organized by person. So I also made a developer-view flow, organized by task.
Even with padded time, this estimate came under the next challenge of 40 work days. So instead of further slicing my flows thin, I had an opportunity to choose what to do with extra days.
IV. Build for function before building for feature
What to do with 7 extra developer days? In my original flows, I had financial modeling tools and a cartoon financial advisor. But in the flows above, I’d also left off error screens and retries—what happens when you try to take an action you can’t or aren’t ready to take. I chose to add in 3 error functions I’d previously cut.
Setting the parameters for error functionality (how many times can I try to deposit a check before it’s denied?) requires liasing with the bank and their guidelines. So my developer had padded estimates for these functions at 1.5-2 days each. Taken together, this got me to 39 days.
Mapping it out to the roadmap looked like this:
Here, I aslo added in V1 and V2 versions for launches: What must be included for an MVP launch (at 3 weeks), and what would nice to have for a “more complete” MVP launch (in 4 weeks), on May 1.
Again, I also created a developer view:
… And created an MVP to launch on May 1!