Watching out for feature creep in a world of possibilities

Jun 15 2015

For the past two weeks, my team has been trying to figure out the most desirable features to include in our product.  As the group tasked with increasing court transparency in North Carolina, we decided to focus on the lack of digital access to public records. Anyone who wants to obtain court files from the district level must currently make the trek to the county court’s office, search the case on the 15-year-old software and ask the clerk to find the paper file. This process poses a pretty obvious problem for lawyers who work regularly with public records, so my team decided to try to fix it.

Our idea started out as an easily searchable database that would include scanned copies of all district court files in North Carolina.  Then, after talking to a bunch of lawyers, we decided to add analysis of the cases, including case summaries, timelines, and links to related cases. After talking to a few more people, we decided that links to judge profiles, expert witness profiles, and overall statistics about cases across North Carolina would also be desirable. We created a basic PDF prototype of our product. This is where my team and I ended up at the beginning of this week. We had four or five major features to our product.

The courts team went through their original prototype and got rid of all the extra features. Photo by Emily Gregoire.

The courts team went through their original prototype and got rid of all the extra features. Photo by Emily Gregoire.

Throughout the week, I began feeling more overwhelmed by everything we had to do to prove the feasibility of all the features of our product. My team and I were spreading ourselves thin by trying to research and create the next iteration of a prototype with everything in it. Then, we had a Lab meeting, and Executive Director John Clark told us about feature creep.

Feature creep is when extra features keep getting added to the product idea. Since those features aren’t integral to the basic product, they take focus away from the what really needs to happen to make the product work. Our prototype had 12 different pages, each with a different feature. We had fallen victim to feature creep.

After talking with John, my team spent half an hour discussing our priorities for the product. We had to get back to our roots.  By the end of our discussion, we narrowed our prototype down to 2 pages of the original 12, and I felt much less overwhelmed.

Now that we can focus on court dockets and files in Orange County as our test, I feel better that I can concentrate on a narrow set of tasks instead of spreading my attention across a broad set of potential features.

Throughout the process of figuring out the features that are most desirable to our customer segments, I learned to beware of feature creep. Too many features, which might each be desireable individually, become undesirable when they take focus away from the foundational idea. As my team moves forward into the feasibility and viability stages of the process, we will remember to keep the focus on one product and not add features unnecessarily. We’ll keep the other 10 pages of features from our prototype for reference in the future, but for now, we have enough on our plate.


Leave a Reply

Your email address will not be published. Required fields are marked *