Archive for June, 2008

Information Overload Research Group news wrapup

Saturday, June 14th, 2008

Wow.  We publicly launched the Information Overload Research Group yesterday, thanks to Matt Richtel’s NYC article Lost in E-Mail, Tech Firms Face Self-Made Beast (which was originally titled Creators of E-Mail Monster Now Try to Tame It – not sure which one I like better).  The article is currently at the top of the NYT most-emailed tech stories list, high on Techmeme, and is being blogged about all over the place.  It’s really great to see this much interest and excitement about information overload and IORG.  A lot of smart folks have given their perspective on information overload and Matt’s story.  Here’s a wrapup of a number of the blog posts:

Merlin Mann asks the question  “What does a company get out of its employees spending half their day using an email program?” and provides his perspective on using email as a tool.

Beth Kanter suggests that we "Turn Off the Damn Email Software and Get Some Work Done (Or go for a walk)!" and shares a number of tips and links to numerous articles and resources on information overload.

Tony Wright worries that "the increasingly personalized infoporn delivered to us through a
broadening array of channels (like RSS, alerts, Twitter, Digg, Email,
IM, Social Networks and more) is a looming disaster."

Paul Mooney points to "Meetings about meetings, emails about phone calls, efficiency tools and
methodologies that nobody can figure out, it’s no wonder burnout is so
prevalent." as a root cause.

Henry Blodget keys in on the claim that "American workers waste $650 billion a year checking email too often."

TJ Kirchner acknowledges the problem, but cautions that companies shouldn’t "use this to
implement really stupid rules and codes of conduct that will only
reduce company moral[e]."

There were also some very good alternate perspectives/counterpoints to the article:

Stowe Boyd posts a lengthy and very insightful rebuttal/counterpoint to a number of the points raised in the NYT piece and much of the conventional wisdom around information overload. "The old school thinking is about individual productivity: but the
social revolution has moved past that into network productivity, which
entails connectedness and social meaning. The personal hit on
productivity is real, but it’s not a cost: it’s an investment; and the
juice is worth the squeeze."  I think Stowe brings up a lot of very interesting and valid points that remind us that there are many moving parts in play here and the best solutions are not necessarily the most obvious ones.

Mark Evans
asks "Is Digital Productivity Dead?" and "is today’s knowledge worker
unproductive or do knowledge workers operate differently?"

And on a related note:

Maggie Jackson, the author of Distracted and a featured speaker at the IORG Conference, writes in BusinessWeek about distractions and interruptions.

Nathan Zeldes shares his observations and provides a detailed update of results from the "Quiet Time" and "No Email Day" experiments at Intel.

That should be plenty to overload you with information about information overload!

Posted in Email, Web/Tech | Comments Closed

Information Overload Research Group launches

Friday, June 13th, 2008

About a year and a half ago, I participated in a workshop with about 20 other people focused on the problem of information overload.  This group included academics researching the impact and novel solutions to the problem, researchers from huge companies like Microsoft, Google, Intel, and IBM, analysts in the space, and a couple of people like me from companies working on information overload solutions.

We had a lot of great discussions, many of which really just got kicked off at the workshop.  A number of us thought that it would be worthwhile to continue these discussions across this cross-section of people doing cutting-edge work in this field.  We formed a steering committee and decided to build on the workshop and create a nonprofit organization focused on the huge and growing problem of information overload.

It took a lot of work, but after a year of meetings, discussions, and debates with an incredibly knowledgeable group of colleagues in this field, we’re now ready to officially launch the organization.  I’m really excited about the opportunities ahead of us.  Matt Richtel just wrote a great article in the New York Times that talks about the Information Overload Research Group
, some of the things we hope to accomplish, and why we think it’s so important.  A couple of my fellow IORG board members, Nathan Zeldes and Jonathan Spira, are featured prominently in the article.

Our first annual conference is going to be held in New York on July 15th.  The final agenda is still shaping up, but we already have a number of great speakers and panelists lined up, including Maggie Jackson, the author of the new book Distracted.

I’ll be writing quite a bit more both here and on the Information Overload Research Group blog over the coming weeks.  A big thanks to all of my friends at IORG who have helped make this happen.  It has been a real pleasure working with them, and I’m very excited about the future of this important organization.

Posted in Email, Web/Tech | Comments Closed

Interruptions, context-switching, and flow

Thursday, June 12th, 2008

Mike Gunderloy at WWD writes "The more you allow yourself to be ping-ponged around from IM chat to
email to what you should be working on to social network to phone call,
the less likely you are to ever hit a flow state."  He points to a great post by Darren Rowse on "batch processing."

There has been a lot recently written about the time cost of working in an interrupt-driven fashion.  This Microsoft Research Study by Mary Czerwinski, Eric Horvitz, and Susan Wilhite documents the level of task-switching and interruptions user face.  We’ve mentioned this topic on the ClearContext corporate blog and the IMS methodology is built around batching concepts like only checking your email every few hours.

Mike’s post touches on what I consider an even greater issue with the interrupt-driven information overloaded world most of us work in – the impact that has on the creative flow of ideas.  Nathan Zeldes of Intel wrote in  Infomania: Why we can’t afford to ignore it any longer that "because of Infomania, employees are not creating new ideas to the extent they could."

This is not a new issue by any means  Back in 2003, gavinb writes "this translates to the idea that 2-3 interruptions per hour can halve productivity" and points to an article by Bryan Dollery that describes why that’s the case:

Flow takes time to achieve, and it is fragile. If a programmer’s flow
is interrupted it can take a large amount of time for her to regain the
state, sometimes up to an hour. That’s an hour of lost productivity to
your team. If a programmer is interrupted many times during the day she
may never reach this state. Without this state, creativity is crippled.

I highly recommend reading the rest of Bryan’s article as well as the others referenced in this post.  They provide some really valuable insight into the second-order impacts of interrupt-driven work styles beyond the basic loss of time and productivity.

Posted in Uncategorized | Comments Closed

The beta excuse (part 2) – is the private beta BS?

Thursday, June 12th, 2008

Longtime readers of the blog have been eagerly waiting on this post for quite some time, as it has been almost two years since I wrote part 1.  Sorry to keep you waiting so long!  In that post I wrote about some of the frustration and confusion around the use of the term "beta" in the software release process, largely due to the way it has been used in the web 2.0/SaaS world.  Brad Feld just wrote a post bringing up the subject that largely echoes this key point from my previous post (and questions whether "Private Beta is Bullshit"):

And this is where things start to become a potential problem as I see a
lot of this trend spilling over into non-web based software products as
well.  Because now all of a sudden, "beta" can become an excuse to put
out shoddy, bug-ridden product that is really more an ad-hoc market
test than anything else.  For companies like ours that still deal in
real product that we sell to people on a traditional software basis (as
opposed to an ad click revenue model or something), this is an
important step in the product development process, and the blurring of
"beta" lines definitely makes things more confusing to a lot of users
out there.

"So – why not get rid of the "private beta" label and call all of these things alphas." he asks.  Well, because they often aren’t alphas!

I think this issue is actually about two very distinct points.

One point is Brad’s key point (and I made in 2006, the WSJ made in 2005, and zephoria made in 2004) – the fact that the way this term has been used has largely made the term meaningless, and "betas" now range from bug-ridden early alphas to true beta quality almost ready for GA software.  Brad’s post has a lot of great comments, including a couple that point out "beta" is also sometimes used as a marketing tag to denote "new" features – even after they are in widespread general release.

There’s a second point, though, and a valid reason for private betas to exist (funny timing on Brad’s post, as our ClearContext Personal product is currently in, you guessed it, private beta).  In the old world of disks and distribution through traditional channels, you as the developer were able to control who you gave access to the beta and push out in waves you selected.  With both web-based apps and software that uses the web as its marketing and distribution channel, the way a lot of companies reach their users is by putting something out on the web.  A number of Brad’s comments describe scenarios where a limited beta is a very useful and valid part of the process.  And logistically, what’s now commonly referred to as a "private beta" is often the best way for companies to accomplish that.  With our latest product, we did an alpha with a small existing group of customers.  Then we did an initial beta, again with existing customers only.  Next we opened our private beta to a few thousand users.  I posted about the different types of beta testers and the part they play in our release process.  On our corporate blog we posted specifics about what we gained from the private beta – the biggest thing was getting usability feedback from brand new users who had never seen anything like this product before.

A lot of companies still use beta as an excuse for taking shortcuts and not having a really rigorous development and release process, but the advent of web-based deployment and/or distribution of software has also somewhat changed the nature of the beta process. Perhaps companies will standardize on usage so people can have some understanding and expectation about what it means for something to be called a "beta" release, but I doubt it will happen without any external pressure.  It would be nice to see some of the leading tech blogs call companies on this and evaluate whether their "beta" releases are really deserving of that tag.  A "how close to ready for primetime is this app" rating would be a very useful service to their readers.

Posted in Uncategorized | Comments Closed

The different levels of beta testers

Thursday, June 5th, 2008

We recently launched the beta program for ClearContext Personal.  I was planning to have my next blog posts here be about our product planning process and how we put together the product plans for our ClearContext Personal and Pro products, and the things we learned by first focusing on the needs of very sophisticated email power users with an incredible pain point of dealing with huge volumes of important and time-critical email.  I’ll get to those soon, but first I wanted to make some observations about our recent beta push.

When we first started ClearContext, our initial beta testers were friends and colleagues.  These people all provide valuable input, but no matter how  much you push them, they are biased towards you and often give you the benefit of the doubt – and are typically pretty forgiving in terms of the finer points of product functionality and user experience.  We still use these people as the first wave of people to give us friendly input on new stuff we are working on, but we recognize that it’s just that – friendly input.

As we’ve developed a base of customers, one big benefit is that we’ve grown an active beta group of users eager to try out new technology while it is still pretty early in development and provide feedback.  These users are quite vocal about what they want to see in the product and very active and important to us when it comes to defining the final feature set we ship with and the details of how certain features work.  Not to mention helping us find that final round of bugs to fix.  These users have been the core of our beta testing process over the past few releases and are a key part of our release process.

We utilized those two groups in testing early versions of our Personal product, including helping us make sure the product was as easy to install and use as possible.  They provided a lot of really good feedback and helped us release a great product that is getting lots of good reviews. 

When we opened up the beta program to a wider audience, though, we now had a new type of beta tester in the mix.  Many of these beta testers had never heard of ClearContext or anything like it and hadn’t seen any videos or tutorials on the website before installing the app.  Things like ranking your contacts based on how important they are, prioritizing and color-coding incoming email, and providing context around email such as related messages, contacts, and attachments – these were all brand new concepts to them.  We received a lot of useful feedback that was very different from any of the prior feedback when we presented the app to a large group of users who had never seen anything like this before.  One of the biggest things we learned from this process was that even for a lot of very tech-savvy email users, for them to take full advantage of some of the brand new concepts we’re introducing, they could benefit a lot from more guided setup and explanation.  So, we’re adding a lot more of that type of functionality (and a lot more of their feedback) into the product to make it easier for users to understand how best to take advantage of ClearContext – so we can help make their email experience better and reduce their stress and frustration with email.

It’s really amazing that the web provides the ability to get so much great input from such a wide range of users interested in and excited about new technology.  But that input is only really valuable if you understand the perspective of your different beta groups and really listen (and act on!) to what they are telling you.  We’re very thankful to everyone who has helped us in this process and hopefully other companies understand how valuable these people are as well, and how important it is to take full advantage of that valuable resource. 

Posted in Email, Startups, Web/Tech | Comments Closed