There is a reason why the web 2.0 social apps that you cite are so impressive - it's because they were made to "scratch an itch". Indeed, they were made by the

There is a reason why the web 2.0 social apps that you cite are so impressive - it's because they were made to "scratch an itch". Indeed, they were made by the very people who use them day in and day out. Note that this pattern is seen at the sub-application level as well, in the emerging agile frameworks like Rails and Merb, where developers got fed up with the old way and decided to create a new way instead. So how do we bring this to business? How do we break through the metaphorical gate? First we have to realize that this "scratch an itch" pattern simply cannot play out in business exactly as it does in the social web. There are two reasons for this: 1. Business people - i.e., the people with an itch to scratch - are generally not programmers on the side 2. Even if they were programmers on the side, the applications are so big that if they decided to start programming one, they would have no time for their day job! So how can we (a) know enough about the space we are working in and (b) think enough like our users to build compelling, user oriented business applications? To my mind the answer is both simple and obvious: by involving the customer as often as possible. Only by getting feedback can we fill the gap between users and developers. And the more often we get feedback, the better. Here we converge on the agile methodologies that have seen a rise in the past 6-8 years. Couple this with a startup that is fun to work for, and that attracts the smartest, most creative web developers, and you just might have a solution. Of course there's still one missing piece: a couple of passionate founders who can attract that kind of talent to this kind of software business. I guess that's left up to the reader, as an exercise.