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.