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.
dan mcweeney says:
January 26, 2007 at 3:25 pm
This gets nearly impossible when you work in Enterprise software because your customers ( the business ) work for the same company and decide your budget for next year so, people feel like “No” isn’t an option. So, I resort to the following analogy:
We have two options we can sit here and talk about building a huge massive cruise ship with staterooms and multiple dining areas, maybe even a rock wall then launch it and realize to everyone’s horror that we weren’t launching the ship into water, but something that looked like water but with totally different properties.
OR
I can quickly build a row boat and send it out on the lake, when that sinks we lose one person ( boo-hoo ) and have learned a vast amount in a shorter time. We can now launch a better designed ferry that carries most of our group and cross the lake, all before the cruise ship even launches once.
-d
Berkay Mollamustafao says:
January 26, 2007 at 4:14 pm
I can’t believe you buy into the junk coming out of 37Signals, let along you promote it. First time I find myself disagreeing with what James writes on this blog.
IMHO, brilliant folks in 37Signals suffer from (or guilty of) generalizing based on small set of data. “read them and throw them away”? what happened to conversations, having direct access to customers? http://www.redmonk.com/cote/2007/01/25/5-tips-for-systems-management-20-folks/
Wonder Cote agrees with this suggestion.
Ignoring your customers and listening to your software developers may only be a option when your developers are natural consumers of the products they’re developing.
If not (which is the case for many many software developers, dare I say most) , how would the developers know what’s important, what the users need?
I strongly recommend Eric Sink’s article on this topic, usware vs themware http://www.ericsink.com/articles/Yours_Mine_Ours.html
Sure the developers should be able to reject feature requests but it’s much better to err on listening customers especially if you’re developing themware
Ignoring your customers makes a sensational headline which works great for 37Signals, but it has so nothing to do with agile!
jgovernor says:
January 26, 2007 at 5:35 pm
Cheers Dan- i love that analogy. may have to ahem repurpose it for monkchips…
Berkay – there is a first time for everything, and i believe this is also the first time you have commented here, so i am actually glad i said something you feel strongly about. I really meant 37Signals as an edge-case that tells us something, rather than as a formal recommendation their approach is the only one worth taking.
I am a big believer in talking and the primary point of the post was to say orgs should listen to developers they may have something valuable to say. The notion that every feature request must be met makes no sense.
But I am very glad to have you both commenting.
Berkay Mollamustafao says:
January 26, 2007 at 8:06 pm
Point taken. I’m sure many developers who are shaking their heads because of a crazy feature request will sympathize.
In fact, I think the real problem is developers talking to middle man (sales folks, etc.) rather than having direct access to the users to understand what they need.
It is actually the second time I’ve commented 🙂
dan mcweeney says:
January 26, 2007 at 9:02 pm
Darn forgot my creative commons license disclaimer on that post… 😉
Paul Cooper says:
January 29, 2007 at 11:42 am
Although I’ve never worked for an ‘Enterprise’, in my experience with small business one of the advantages of an agile approach is that it helps the customer say no – to be able to take their list of 20+ must have features and say, ‘in a month I will deliver a working app but with only 2-5 of those features, so which are the most important’ helps them very quickly discard the fat – and while it might be hard the first go round the cycle, once they become accustomed the list of required features get shorter and more focused over time.
People Over Process » Blog Archive » Re: Just Say No… agile is simple, or, Escape from Your Ghettos, Suits and Coders! says:
January 29, 2007 at 11:59 pm
[…] Here’s some commentary to amplify and fortify some of the points in one of James’ recent posts, the thrust of which is that software vendors (and, we’d assume, projects) need to reject feature requests more often. On the topic of Agile, he adds: 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. […]
People Over Process » Blog Archive » links for 2007-01-30 says:
January 30, 2007 at 7:27 am
[…] On Software Requirements: Just say No… agile is simple Big ups! (tags: agile smellsofagile requirements) […]
James Governor says:
November 23, 2010 at 10:42 am
looking at back at this i have to chuckle. i still think the essential point is sound. apple has shown us all the difference between requirements and great user experience. 37Signals- great at rhetoric, full of useful lessons. but we stopped using its software. that said Ruby on Rails is opinionated software- it does a great job of erring on side of convention rather than configurability. it says no to developers…
Stephane says:
November 23, 2010 at 12:26 pm
Very good post – I totally agree with the point. However, in the middle of an org, if it’s possible to say no to the worst feature requests, it’s really hard to say no to most. I think that a possibility to escape that complexity/bloating trap is to provide some sort of plugin architecture when the context allows it. After all, special feature requests are well… special, so most other customers won’t use it. In this case, providing a plugin for that feature allow the users to be happy without bloating the standard code base. In an extreme scale, this is actually what app stores are also doing.