Minimum Stable Feature-set
From time to time this blog will reflect a decision we take as a company, this is one of those times. We're currently working on a product called Citrus, a better way for agents to sell property online because frankly existing stuff sucks, scheduled for launch in the autumn.
One of the key decisions we've taken is not to implement everything on our feature list. We'd rather build half an app than a half assed one. As flippant as that sounds, it's true- we could spend years analysing all the competition, ensure that we've not only bested them at the key features we know we need to implement, but at everything else as well and some day in the distant future launch a product. Or we can look at our feature list, choose the killer features we know our application needs to have to achieve everything 80% of our potential customers need from our app and forget the rest.
We've chosen the latter. It's going to help us get to market faster, it's going to help us get customers quicker and it will allow our customers actual use of the product drive our vision for it- not some paper list. Also if we're totally wrong in assumption that a good product can gain traction in a poor market, we know and can move on sooner.
UPDATED: I renamed the title for consistency - we refer to the stage of development as either both the Minimum Launch Feature-set or the Minimum Stable Feature-set internally - the latter being the best really since it's useful both for an initial launch and for discussing post launch updates.
Subscribe via RSS