
37Signals: "We Compete With Email" - lionhearted
http://www.sebastianmarshall.com/?p=318
======
raganwald
+1

I have been building custom office automation software for some little time,
and the reality is that any new system is always trying to wean people off
managing all their communication and process by email.

Even as we speak I am building something for a client and we are taking the
view that writing things on "walls" and commenting on "stories" just like
Facebook as some potential for diverting information from email into the app.
We don't know if we're right, but that's how we're betting.

We could simply tell people to use our app for everything, but my experience
is that if whatever you build is dictated by managers in the hopes of
straightjacketing people into some new process, they will route around it
using email as a back-channel.

To beat this, you have to be better than email in some way that the users
themselves appreciate.

~~~
bbarthel
The problem with trying to force people out of email is that everyone

a) Knows how to use email

b) Has access to email

Don't underestimate these things. If I'm at home and I need to log into a
company VPN just to update my status for my manager, that's a lot more effort
than sending off a quick update via email or just picking up the phone.

Conversely, if someone asks me for some help on a project and then asks me to
learn an entirely new system for an hour of my time (including new logins, new
bookmarks, possibly installers, etc) it is often a net loss for me and for
them - by the time I am up-to-speed I am done with what they needed anyway.

Basically, I am happy to use whatever system can help me do my job better, but
too often I am forced to drop back into email anyway. Eventually I am trained
to just use email first, because once your tool gets out of sync, its
usefulness decreases.

~~~
roc
And the problem with keeping things in email are numerous and insidious.
Consider:

email hides embedded knowledge and frail processes (Jane asks Bob for A in an
email and only Bob knows that B and C are implied when Jane asks. If Bob is
out, the process to ask for A can be completely paralyzed.)

no actionable meta-data (no easy way to harvest project name, members, status,
dates, etc. Good luck trying to find out who you need to invite to an
integration-of-two-systems meeting.)

no easy way to bring new people up-to-date, save massive retyping.

no easy way to know current progress without sending out a mass request-for-
status email

history tracking problems (all it takes is one or two people to not hit reply-
all, for an email history to be completely untrustworthy from any one inbox)

Naturally, people should aspire to make replacement systems as easy or more
easy to use than the ones they replace. But email being easy is never a good
argument for leaving a process in it. Particularly not project-management
tasks.

~~~
bbarthel
Please don't mistake my comment as an argument for using email in all
situations. I think that source control is widely accepted and about as
frictionless as it should be. There are a variety of task-management tools and
processes that can be used pretty easily within a team and also generally hit
about the right level of friction. I love being able to integrate the two and
further reduce needless friction. It is all the different discussions and
conversations that go on around those items that are difficult because I don't
want any friction in those discussions. I should be able to see what my client
thinks of the new GUI, or ask an old roommate of mine to review some
performance-critical code and see how he would approach it without requiring
them to create a new account, get access from IT, purchase a license, or any
of the other impediments usually placed on using these sorts of tools.

Basically, my thought is that if you are attempting to compete with/replace
email, you need to address the friction issue for those items. Otherwise
people will eventually revert to email at which point updating the repository
becomes another item in the todo-list, and the reality I've experienced is
that it will ALWAYS be the bottom item.

In short, I agree with all the problems you cite, I simply have not been able
to experience the ideal because none of the systems I have attempted to use
reduce the barriers to communication sufficiently to replace email.

------
pluggerguy
You could embrace email and build a super simple task system.

Issue commands via subject line.

Add / Update / Close Task

Assign / Transfer Task

Timesheet Task

Share Task

User could add whatever they want to save about a task in the email body.

Archive the emails centrally and provide full text search.

Hook into the customer database and tag the content.

Centralize knowledge in the organization.

Use a tool everyone already owns and understands.

~~~
stephen
A really simple version of this is on my "next hobby project" list.

Seems like it should have been done before though.

My impression is that a lot of bug tracking tools integrate with email (e.g.
lighthouse, surely others), but usually it's a minor support role to the
webapp, instead of being the main focus.

~~~
aaronblohowiak
Doesn't matter if it was done before if you do i "right" (for some new
function of right or a competitive edge in market-finding.)

------
Udo
Of course people who build messaging systems can see themselves as competing
with email. It is, however, a bad sign if they feel that way.

Specialized applications, such as task and project management, should have
nice and efficient user interfaces. In the best cases, these UIs reflect the
nature of the operations the product is designed for. Email, on the other
hand, is a general-purpose messaging system and it really excels at two
things: notification and also communication in small groups.

Taking this into account, it should become obvious why there is something
wrong when a company considers themselves threatened or limited by email. And
there is an even greater problem if it's the other way around and vendors feel
like they are replacing email with something much better. Those ever-so-
overwhelmingly celebrated visionaries at 37signals should consider why people
use email in the first place, and then possibly take a step back and chill
out.

~~~
jamesbritt
"Those ever-so-overwhelmingly celebrated visionaries at 37signals should
consider why people use email in the first place, and then possibly take a
step back and chill out."

I've had to use Basecamp lately because of a client, and it is an exercise in
frustration. Basecamp uses E-mail that isn't E-mail.

I get E-mail that my E-mail client says it's sent to me from
manager@someco.com, but it's really not. I have to look carefully to see that
a reply is not going to go back to that address, but to Basecamp instead. And
I have to format my reply in a special way do that it can be machine parsed at
the other end. Compulsory top-posting :(.

I often get messages that refer to "the attached image". But it's never
attached. The image lives at the other end of some link. Often that link takes
me to a page that then gives me the real download link.

All these intermediary steps just makes stuff take longer while breaking the
mental model of how something (E-mail) works.

If the goal is to capture all of the messages exchanged among project members,
and E-mail gets involved (as it inevitably will), then you're better off
letting E-mail be E-mail and working _with_ it instead of trying to supplant
it.

------
joshklein
If you read Steve Blank's book, 4 Steps to the Epiphany, or come across any
other "customer development" style methodology, you'll recognize this as the
unique characteristics of a market you are creating (or in this case, re-
segmenting).

The primary competition for an immature or re-segmented market is inaction,
not actual competitors.

------
antidaily
And yet, email (messages) is the best part about Basecamp - messages all get
posted in one spot.

------
karterk
The biggest issue I see is that people are really very comfortable to emails.
It's about changing their mental model. Email is something I notice people to
use all the time and something which they check religiously. Convincing people
to use a project management software X - entirely for all their project
related communication is a great challenge.

~~~
auxbuss
Yes. You need to change behaviour, which in a business (depending on many
things) often requires an edict from the top. Not always, I know.

I have worked with clients who grasped this need.

One wrote their own call management system for sales staff that forced all
calls to be logged and emails were templates (with appropriate substitutions)
sent via the system. Thus sales' histories could be kept and anyone could pick
up the thread. Email could only be sent by the sales' manager and his
assistant.

This provided huge amounts of marketing stats. None of this would have been
available from email. It was worth a fortune on future product launches.

It's really a business problem, not a technical problem. When you pitch this
at board level, it always gets attention, ime.

------
recoiledsnake
And most intranet software's competition is a Excel sheet.

~~~
aaronblohowiak
Excel => Access => SQL Server / Oracle.

~~~
iuguy
You missed out the bit between Access and SQL Server where the Access frontend
is stuck on a Citrix server and the backend is stored there for 'concurrent
multiuser support'.

