Early in my career I worked on a new service called Venues at an MIT Media Labs spinout called FireFly. The service was an early version of a social network like MySpace that was focused on engaging consumers in chat, message boards, and content around user-driven topics. I poured my heart and soul into this product, writing requirements, producing the design, creating a project plan, and then working tirelessly to deliver on-time. After delivering the service to our business team four months later, I received some tough news: the core assumptions of our business plan were flawed, ensuring the product I built would never see the light of day. It was a tough blow early in my career but also a formative lesson. Up until this time, I had always thought the greatest risk in building software was in its development. But what FireFly Venues taught me was that the single greatest risk was actually in building something that didn’t matter.

As a technical leader, it is important you ask yourself the following critical questions when delivering a new feature or service:

  • What are the critical assumptions to success? - FireFly Venues was an innovative concept ahead of its time (1996). At its core was an assumption our company could attract high value producers to self-publish their content on our service, and that we could drive businesses to pay to present advertisements to our users. Unfortunately both assumptions proved to be flawed. The first step toward managing risk is to identify the critical business and technical assumptions for success.
  • Is there an incremental way to validate these assumptions? - We as a business had no track record in attracting content producers or signing up advertisers for user-driven content. Had we identified these assumptions, we could have looked for a lower cost way to validate them. For example, instead of starting development we might have assigned a sales rep to try to sign up a single partner and/or advertiser. When these assumptions proved false, we would have had the necessary knowledge to quickly pivot our business idea.
  • Is there a subset of the product / feature you can that would be used by a segment of the target market? - We chose to build a functional, scalability and high quality service instead of a much narrower version of our product. If I had focused on delivering the smallest subset of the service that would be useful to a subset of content providers and/or advertisers, we could have forced validation of both our known and unknown assumptions. When you know your critical assumptions, it becomes easier to trade off functional and non-functional value for rapid delivery.

Incremental delivery will almost always come at a cost. In many cases, it takes more time and effort to deliver incrementally than in a single “big bang” release. Incremental delivery can also encourage a reduction in non-functional investments (e.g. scale, quality, extensibility, maintainability), which can incur technical debt that will have to be paid down in the future. In fact, there are many downsides to delivering incrementally and only one upside: it ensures you never build software that doesn’t matter.