# Why the enterprise cant reach consumers DevFeed: [Why the enterprise cant reach consumers]() Original publisher: [Read original article]() Author: Map Published: 2009-09-08T03:21:08Z Content type: opinion Language: en Sources: [Craig Kerstiens]() Topics: [Development](), [Users](), [enterprise deployment](), [Requirements](), [X (Twitter)]() Tags: [development](), [enterprise](), [requirements](), [twitter](), [users]() ## AI overview The article contrasts enterprise development, characterized by established corporate structures and waterfall planning, with startup development based on releasing early and often. It argues that consumer products should be launched quickly so real users can reveal what they want, rather than relying primarily on requirements gathering, user groups, laboratory tests, or invite-only betas. ## Source excerpt Most of my working career has been in what many would call an enterprise environment. Corporate structure well in place at most of them and in those cases any development followed closely to a waterfall methodology. You laid out requirements strictly and then built to those requirements. You essentially had nothing to show until you got to the end product. Having been in the valley for several years and interacting with some startups and in other settings, I've seen a very opposite mindset. The "release early, release often" concept. First you never have clear requirements when dealing with anything a startup should be tackling, if it's a very clear easy to solve problem, then someone else will have already tackled it. If you're doing something new, which you should be you can't gauge how users react, until you actually have something in front of them. A prime example would be twitter. Twitter was a simple concept, yet it has been done before in many ways, what's the difference in blogging and twitter? Well twitter requires you're shorter, has no title, just content, and centralizes the data. It actually incredibly reduced what the user could do, and in doing that created new and broader functionality. As a more general principle users don't know what they want. Users will complain about how gmail doesn't have folders, but they use folders in outlook only because they can't properly search. If you take away something from a user, they're going to complain about it. This is fine, it's not a problem, as long as they didn't actually use the feature, and there's other steps you can use to manage this backlash. But I'd believe the over arching key is that you can't ask users what they want. If you presume to know you're going to be wrong, so what does this mean. This means that you build something and you launch it. You don't test it in user groups, you don't test it in a lab, you don't test it in an invite only beta, you launch it. You launch for users, and if they don'