« Your ability to use collaboration products in the future is in serious jeopardy. | Main | Good blogs, and bad blogs »

Collaborative Technology Conference report - everybody's got their own priorities

At this week's 2006 Collaborative Technology Conference in Boston, the first-day keynote speakers are painting a fascinating picture for how people work together. The bad news: Their “visionary” opinions reflect the products they each hope to sell. The good news: Many vendors are finally beginning to look more carefully at what users' real needs are, and not building the same old thing over again. Like we did.

Technorati Tags: ,

IBM

IBM's pitch is for the “Hanover” release of Lotus Notes (eventually to converge with Workplace). Despite a significantly heavy rework (and most likely totally-rewritten) design, they still don't give you simple. It's a packed user interface, with zillions of bits of information. While very powerful-looking, it doesn't give me the sense that I'll be able to focus on getting work done. I'll have lots of gizmos to use, but whether they help me create results faster or not remains to be seen. At least they're not totally web-based; their users will be able to work while on your average airplane - something Google Enterprise can't yet claim.

Google

Speaking of Google, two things are clear:

  • They're taking aim at Microsoft (in particular, MS Office);
  • Their approach is decidedly different. It's not just that they are building web-based software (vs. desktop). They are approaching enterprise software from a consumer user point of view. They say they're driven by a model knowledge worker - but it's still consumer-perspective-driven.

Google can alternately be inspiring and frightening. Bottom line, though - like IBM, they've got lots of gizmos, and I'm not sure how much they'll help me yet.

37signals

37signals (maker of Chirp competitor Basecamp) was also there. Their CEO's speech was provocative (which is apparently typical for him), but naive and a little simplistic (like Basecamp, IMHO). His basic points have both good, and bad, in them:

  • Have small teams; they get more done, because they have to. I agree. Sometimes big projects — like building a call center — need bigger teams because the amount of work that needs done is so big. Breaking big projects into lots of small teams can sometimes add too much confusion, and lead to silos that aren't working well together. Use Chirp to avoid this problem. :-)
  • Keep them physically apart, and don't have meetings; interruptions keep things from getting done. I agree - to an extent. But part of having meetings is to enroll people who have to be on your team. Doing things without talking about it doesn't bring about this enrollment. And, sometimes 15 minutes of conversation can save 45 minutes of typing.
  • Make lots of small decisions, quickly. I generally agree. He approaches this from his own perspective as software developer. But he doesn't give credit to those who actually started this trend in development - those who created the Agile Programming model. He takes an absolutist position with it, and doesn't recognize that the model doesn't always work. Good for a speech; too limiting in practice.

All in all, I'm gaining a variety of interesting insights, though, that should benefit users of Chirp. There will be things from here that make their way in to the product over time. Stay tuned.

TrackBack

TrackBack URL for this entry:
http://ceoblog.plumcanary.com/cgi-bin/mt/mt-tb.cgi/4

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)