Fred writes about why VCs should say no more often to startups.
Startups can go in many directions. There’s always the desire to please the customers. But knowing what you are going to do and focusing on it is so critical. Saying yes might seem like no big deal. It’s only a few lines of code, right? Wrong. It’s never just a few lines of code. So say no as often as you can. It’s counter intuitive to the entrepreneur mindset, but it’s critical.
The same is true for software development.
Every enterprise software salesman has come back to their company with a must-have feature request. “But the customer won’t buy it without this feature, and its a million dollar deal…”
Microsoft has seemingly never met a feature it didn’t like, but then its operating systems come to market years late. Very often, less is more. With that in mind it is critical that the development organisation is in a position to say no to feature requests. The 37Signals mantra (thanks Rick) to customer suggestions is:
“Read them and then throw them away”.
Instead 37Signals focuses on execution
We believe most software is too complex. Too many features, too many buttons, too much confusion. We build easy to use web-based products with elegant interfaces and thoughtful features. We’re focused on executing on the basics beautifully
You see, lesscode isn’t just a function of the language you choose to develop in, ie less code to get more work done, but also how many features you choose to implement in the first place. This is perhaps the key problem with so much Waterfall development- it ends up including every feature that might be needed, rather than focusing on what needs to be done to solve a specific part of a problem at hand. With Agile, on the other hand, features are built with some isolation. Agile development can potentially say no more easily, because there are fewer interdependencies between all the features as specced. Perhaps we should add this sniff test to the smell of agile – you can tell an organisation is agile when development teams can reject feature requests.
What am I saying? Listen to your software developers, not just your software salesman. Listen to your chief architects not just your vice-presidents of marketing. Listen to that little voice saying “this really wasn’t in the plan.” Successful development is a conversation between code and requirements. What’s the story? What are you trying to achieve? We can implement that like this…
Once the feature spec is nailed down you need a bloody reason to add a new feature. Saying no more often will allow you to develop products to time and to budget. And oddly enough will probably make customers happier. No sane person would argue that customer satisfaction is a function of number of features.
There is a reason why football is the beautiful game. It has so few rules.
Can you imagine how many times Sergey and Larry refused “awesome” ideas for new functions on Google.com? If I had a dollar for every time Google turned down a search page feature request I would probably have nearly as much money as them. Well not that much, but you know what I mean.
Philips has a simplicity advisory board. Perhaps we all should, well assuming we’re big enough to need one. I would argue the simplicity advisory board should even be involved in M&A activity. Acquisitions, not organic development, are the surest and fastest means to a feature glut. There is a reason IBM only buys companies that build on IBM infrastructure…
Simplicity is better. Avoid the tyranny of choice. Just say no.