37Signals: "We Compete With Email" | Hacker News Reader

37Signals: "We Compete With Email"

sebastianmarshall.com

48 pointslionhearted28 comments

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.

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.

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.

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.

Absolutely. With email, business knowledge gets hidden in someone's inbox. It's of absolutely no value to the business in there.

It's a hard sell to get a business to change its behaviour and keep its information elsewhere where it can be shared for the greater good.

It's a big problem for a business.

Plus, email works on 99 44/100ths of the available hardware and software platforms, natively :-)

If "works" is reduced to the act of shuffling 7-bit characters around, then sure, and indeed, that's a big chunk of what e-mail does.

But trying to make sense of a large thread from five months ago with reply from many people (with little, or at least varying, ideas of quoting etiquette) on many different clients and platforms is not my idea of anything "working"...

Considering that 37signals products are web-based, they also work natively on a pretty large percentage of available hardware and software platforms (at least the ones you're likely to be using).

I agree that web-based solutions could reach enough people for them to be a feasible replacement for email in terms of availability. The point I was trying to make by talking about access is that everyone has an email address I can send mail to, but generally access to project-specific tools are limited to folks on the project. So if I hash out an interesting technical approach with someone outside the project or outside the company, it will likely be done in email or via the phone.

Once I have resorted to using email, eventually I will forget to move a conversation over or I don't think it will be important and our "repository" has gotten out of sync, which leaves me with a merging issue (do I trust what my email says or the website), and eventually a duplication of effort (I know we talked about this, but my email says x, and the website says y)

As an aside, as I was writing this, I also realized that I tend to use email as my "archive of knowledge". When I move on to a new project I can search back through my email to find relevant discussions and apply them to my new work. I have not seen a tool with a similar ability to archive and take with me my lessons learned (whether because of company policy or lack of feature in the tool). I know lots of managers who religiously archive their email to avoid losing some obscure piece of information or process from years ago.

True, but people are already using email. Everyone knows how email works and how to attach files. Not everyone knows what a "writeboard" is and how it's different from a "message"

I agree fully that everyone knows how email works, and I'm not debating the point that email-capable devices outnumber javascript-web-capable devices. I'm questioning the point that because there are more email-capable devices, email is a superior medium for project communications -- because there are enough devices with modern web browsers to let people use more advanced tools.

email is a very generic communication, and in my opinion, it is possible to build tools on top of email that can give every collaboration/crm/project-management tool in the market a serious run for their money.

Every email front-end now supports extensions/plugins (for gmail, its gadgets+contextual api or DOM scraping), and of course there's imap to interact with the data, labels, headers and attachments. These two together yield a lot of potential to build a lot of tools that can be very useful.

We have built GrexIt (http://grexit.com) which allows Google Apps mail users to store email discussion from their inboxes to a shared area, where others who were not a part of the discussion can see them. This helps our users very easily create a knowledge base out of their work email. Some of our users are also now using GrexIt as a collaboration tool.

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.

There's certainly a lot to be said for seeing email as your platform to improve upon rather than your competitor, and remembering that the luddites who prefer it to sexy Ajax GUIs quite possibly include a lot of the senior management who sign off enterprise apps.

That's what I originally envisioned with DuctMail. It's a simple reminder system at the moment, but the basic idea was:

command@ductmail.com Subject: Plain English Arguments Body: whatever else we might need.

For example:

Email: reminder@ductmail.com Subject: Today at 5PM Body: Buy milk! Also, don't forget to buy some KY, and a lawn chair.

The problem with other systems is they usually try to put the arguments into the email.

I'm working on a todo system as well.

Email: todo@ductmail.com Subject: Name of Todo List Body: One Todo For Every line Of the email

Sends you a reminder every so often, and you can reply back with what you've accomplished by putting a - in front of the item.

Their are other ideas being worked on. One I'm trying to find time to finish up is a daily habit system.

It would email you in the morning reminding you what you want to do every day, and then at the end of the day, it will email you, asking you for an update on how you did, and you could reply back, etc.

I've done this, almost exactly, with a client by using Redmine rather than email. Forcing communication through the web interface, but sending notifications via email. It worked really well. And folk (all non-tech) adjusted very quickly, since they benefited from lots of shared info.

It also has a wiki and file storage, and folk started using these without them ever being mentioned. Kinda supports the idea of: give folk the tools and let them get on with it.

(I am not recommending Redmine, per se, it was just what I grabbed to quickly bring sanity to an out of control situation at the time. It's not bad, though.)

I was about to suggest the same thing, except it basically turns you into a computer. If the app (/api) is small enough, this could work really well. But even for something as "small" as Basecamp, the "protocol" could get decently complicated fast. Somehow this equates to the Terminal vs. GUI apps debate to me.

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.

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.)

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.

"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.

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.

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

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.

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.

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

Excel => Access => SQL Server / Oracle.

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'.

Reply on news.ycombinator.com