Screen Shot 2018-04-02 at 9.37.33 PM

Kill Your Darlings and Frankenstein

As the next phase in Product Management following the estimate received only a few weeks ago for a banking app redesign, I developed a product roadmap to guide development and to communicate when features and capabilities will become available.

The first release still provides value to the user even though features were removed from the flows: account transaction details, view and save a copy of a check, edit check description, adding a note when sending money to an individual, and adding new people from device contacts.
The first release still provides value to the user even though features were removed from the flows: account transaction details, view and save a copy of a check, edit check description, adding a note when sending money to an individual, and adding new people from device contacts.


 

The second release includes functionality that was removed during the thin slice. Several of these features were deemed high-risk by the developer. With additional time, I should be able to de-risk the features by learning more about external partners, banking requirements, and build additional flows.
The second release includes functionality that was removed during the thin slice. Several of these features were deemed high-risk by the developer. With additional time, I should be able to de-risk the features by learning more about external partners, banking requirements, and build additional flows.

Here’s a quick step by step for how I got here:

Assumptions

I began by making sure assumptions to ground myself in a real-life scenario. Fundamental assumptions include: two developers working 8-hour days; product launch within three months; banking is a competitive consumer market which makes baseline features must-haves (accessing accounts, depositing a check, and paying bills); there are many things we don’t know, and new relationships are complicated.

Constraints and Priorities

Kill your darlings

To bring something to market within two months, I began by taking away features that I had planned to develop for the first release. This is called thin slicing. The idea is to balance development capacity while still providing user value. It’s sort of like killing your darlings when writing and editing something you wrote. However, a product roadmap has a silver lining: you can later add what you took away to a future release. With proper planning and communication, you can make sure it’s not a Frankenstein moment!

I created a rough cut thin slice flow by removing things so that capabilities and capacity were balanced. In this example by removing a feature to add new payees from a user's device (marked with an orange x), I deferred 20 hours of estimated development time while still delivering value and capability for a user.
I created a rough cut thin slice flow by removing things so that capabilities and capacity were balanced. In this example by removing a feature to add new payees from a user’s device (marked with an orange x), I deferred 20 hours of estimated development time while still delivering value and capability for a user.

New flows

After removing capabilities (account transaction details, view and save a copy of a check, edit check description, adding a note when sending money to an individual, adding new people from device contacts), I created revised flows to make sure they still made sense and provided value to the user.

Rationalize with the estimate

Then I took the new hero flow, assessment of time, and compared it with my capacity and launch goal. From there, I cut additional capabilities (what if and spending analysis features). The features reduced during the second round of thin slice were based on the insight from the developer who provided the estimate: we didn’t know enough about the features that will be provided by a new acquisition.

Capacity planning

I began by briefly describing the capabilities, sequencing the capabilities over a period, and rationalizing the estimate several times to make sure that I had the confidence to deliver on the roadmap. Knowing that banking is a competitive consumer market, I focused on providing basic functionality in less than three months (release 1.0), and then add functionality to those basics within the next three months (release 1.1).

With the first release I am able to provide critical functionality.

 

 

With the second release I am able to provide additional features, such as adding contacts from a users device for payment, and accessing transaction details.

Anticipation

I included 40% more time than projected since it is the first time I’ve worked with the developer, and I have approximately 50% of the necessary flows. I pushed off several features that were deemed high-risk to release 1.1. This will give me more time to plan for the second release and develop additional flows (I see another thin slice in my future).

For additional information on my process, see the rough cut thin slice flow, updated flows, estimate rationalization, product planning and roadmap documentation, and presentation deck.