Feature estimates are often blindly used for cost benefit analysis. This was no more apparent than when I once worked with a product manager named Bethany. She was responsible for what, in hindsight, was always a doomed social network for lovers of the North American Brown Bear. Bethany would routinely ask her developers to provide implementation costs for a long list of features. The developers would grumble and complain they need more detailed requirements before they can put together detailed estimates (because they had been burned in the past on being held to commitments based on changing scope). Bethany retorts that she just needs “T-shirt sizes”, which is code for wild ass guesses, so she can do cost benefit analysis. Logically, this makes sense. Like any savvy businesswoman, the product manager wants to get a return on her investment. You wouldn’t buy a piano without first knowing the price, right?

The developer would always eventually relent and give her the feature estimates she asked for. The feature to let people upload pictures of their favorite bear for example would take 2 weeks to build. The feature to translate English into Bearease was estimated to take between 1 month and 2 years. The bear picture upload feature was a clear customer win and a frequent ask from the sites three customers, but the English to Bearease language translation was a real opportunity to differentiate their site from the other bear lover social networks. If the bearease translation feature cost only 1 month it made more sense to prioritize that feature, but not if it took 2 years.

Bethany went back to the developers and asked why there was such a wide estimate in the translation feature and if there was a way to bring it down to the 1 month side. The developers came back with a bunch of mumbo jumbo about corpuses and having to maintain the translator by hand. They could develop a version of the feature in 1 month, but they wanted to do something fancier. Bethany heard that it could be done in 1 month if they really wanted to and said “go forth and develop my Bearease translator.” (she literally said that, it was weird then and it is weird now)

A month later, as expected, the developers had cranked out a Bearease translator just like they said they would. Bethany and the developers had a big launch party, people drank a bit too much and they talked about all the money they were going to make when the site went IPO.

Horribly hungover (likely due to the preponderance of blended whisky drinks), Bethany then tasked the developers to start working on the bear picture upload feature she had put off earlier. The developers went to work and two weeks later Bethany came back to check in on their launch. The developers said they were still working on it, and it would take them another two weeks. Bethany was furious. The feature was only supposed to take 2 weeks, she demanded to know why they couldn’t make their commitment. The developers started venting about how they were spending half their time maintaining the Bearease translator, constantly adding new words to the dictionary as users tried to translate words that they didn’t already have translations for. Bethany was angry at the developers for not being able to develop new features quickly enough and the developers were similarly angry they were spending so much of their time maintaining dictionaries rather than coding new features. They spent so much time being angry with each other that they stopped developing features all together. Facebook swooped in and stole their Bear loving user-base (with the ability to upload bear pictures even!), and the rest is history.

Bethany and the developers took away opposite lessons from the whole experience. Bethany said working with developers is lame because they are lazy and don’t understand business. She started her own hedge fund and now has a net worth measured in billions of dollars. The lesson the developers pulled from the experience was to never again do a feature quick and dirty, and the next time a product manager asks them to build a Bearease translator, they will say it takes 2 years, end of story.

While Bethany can now afford to send several teams of highly trained ninja assassins my way for saying this, I put forth the contention that both Bethany and the developers pulled away the wrong lesson. Bethany’s real mistake was equating implementation cost with the true cost of a feature for cost benefit analysis. Software features, like most business investments, have operating costs associated with them. Those operating costs can vary wildly and there is frequently a trade off between initial investment cost and operating cost. If Bethany had taken into account the full cost of the features, she may have decided that uploading bear pictures was actually the wiser investment (something Facebook was smart enough to pick up on). Or at least she would have come in with the right expectation on what she was getting with her initial Bearease translator, and budgeted for followup work to make the feature more operationally maintainable if it was a success.

The developers on the other hand learned too simplistic a lesson on technical debt. Technical debt, like any form of debt, is not evil. Without the ability to go into debt (i.e., taking out a loan), most new businesses couldn’t even get off the ground in the first place. If the demand for a Bearease translator was uncertain or if the immediate rush to market of being the first to have a Bearease translator justified it, the one month implementation with high technical debt could absolutely be the correct decision. For example, if they launched the Bearease translator and it completely tanked, they at least would have only lost out on 1 month of work rather than 2 years worth of work. Requirements and customer adoption are so subtly variable and changing in software development that this is often in fact the best approach to take. As long as ongoing operational cost is measured and time is continuously budgeted to reduce it, everyone can benefit from such a rapid iteration methodology.

This post is also available in spoken Bearease.