Keep requirements frozen

One of the hardest things to do when creating software is to freeze requirements. I personally suck at it, considering creating products is something I enjoy it is very easy to get carried away when starting a new project or designing a new feature. "Wouldn't it be cool if the app can predict the future?", "What if some user from China sleeps on their keyboard and accidentally lands on the product, should we have the site localized to Mandarin?". I can go on an on. One of the things that is quite hard and I feel is heavily underrated is knowing where to draw the line. What is the minimal viable product? What is good enough for now and yet still a great experience for the user. Companies like, Apple, 37 Signals and Nintendo have historically known when to make that call and still release a hit product. Apple did that with the first iPhone, ignoring features like Multi Media SMS, Multi tasking and Group texting that were normal on other smart phones to focus on what they thought was important. 37 Signals has always done this with basecamp. They consistently produce a project management tool that has less features than the competition but execute their product really well and it resonates with a bunch of people. Nintendo made a fantastic call on the Wii, when they decided not to care about HD games like the Xbox 360 and PlayStation 3, reducing the price of the console and focusing on their new interface for gaming. All this could not be done if they did not know when to stop adding features to the list.

Walking on water and developing software from a specification are easy if both are frozen. — Edward V Berard

Agreeing to stop adding features to the list is something that is hard to do with clients but is very essential to a consultancy. You have to define what the end of a project looks like at the beginning of the project. In a product company you really have to know what your priority is, if not you can easily drift into paralysis and end up doing nothing at all or you do everything and your software ends up sucking.

Actually it is kind of ridiculous how crucial it is to lock down the requirements of a project that is easy to tell if your project will succeed of fail from a mile away. Here are a few symptoms of not having frozen requirements I have noticed:

You can't tell if the project has ended
It is hard to manage the expectations of your client
The morale of the team is low
You feel like you are shooting a moving target
Watching cat videos on YouTube inexplicably is more fun
You catch your self playing the "What if" game
You hear your client say, "It should be real quick"
Insomnia, runny nose and headaches

How I tend to deal with freezing requirements now is by deciding what the requirements are early on with the client, or if I am making a product, it would be decided on by myself or with the team. We then discuss what a finished project should look like and there is a status meeting every week where these milestones are re-iterated and the status updated and any new item is scheduled for a later time.

In the last couple of projects, this seems to work well as long as I emphasize to the concerned parties the consequences of what deviating would be.