Stowe Boyd and Jason Fried: Where Should Basecamp Focus its Resources?

Jason Fried responded to my criticism of Basecamp in a comment to a recent post, Michael McDerment on Software Should Be Social Because No One Works Alone. I had stated that I consider it a basic flaw that Basecamp doesn’t support a federated model of work: that is to say, if I am working with four companies who each have a Basecamp instance, I wind up with four account/login/password combinations, and worst of all, no unified dashboard view to consolidate all my Basecamp information.

Jason makes some well-reasoned arguments in favor of the current status quo:

Thanks for your thoughts. A couple things.

1. Most people are not like you. Most people are not as connected as you. Most people, the vast majority of our customers in fact, have one Basecamp account that they use with their clients or just internally. Yes, there are folks with multiple accounts, but they are the slim minority exception, not the norm. The majority of our customers aren’t well connected techies, they are small business owners that use a tool alone or with their clients. They have their own small world. Multiple Basecamp systems are rare among these folks.

2. We are working on a product we’ve code named “Compass” that will provide single-sign-like capabilities to customers that use multiple versions of our products. We don’t comment on release dates so I can’t share any additional information, but it’s something we’re planning.

The inconvienent truth for techies is that most people don’t have the problems that techies do. Most people aren’t roaming between multiple Basecamp accounts. Most people also use the same username/password everywhere so they already have “single sign-on.” But we do agree — a more unified sign on across multiple products is useful so we are working on it, it’s just not the most important thing right now.

Another thing to remember is while it feels like we’ve been at this for years, it’s only been 2.5 years since Basecamp has been released. Backpack just turned 1 a few months ago and Campfire is just a few months old. We like to nail the basics in our apps first and then work on the more complex issues later. Multiple products with multiple logins is a more complex issue. It’s time is coming, but it would have been wasteful for us to spend our time on such a complex issue a year ago.

Jason’s point about me being abnormal is true, as far as it goes. I made the same observation last week at Reboot 8, where I outlined the Basecamp Federation Bug as an anti-example in my talk on Social Architecture. I am more connected than others, and so I have encountered this basic flaw earlier than the majority of Basecamp users.

However, anyone who is a free agent — working for multiple companies, or across multiple projects in a big company that has more than one Basecamp account — will encounter this problem just as soon as I have, although they may not have the situation that I do, with over a dozen account/login/password triples in the past 12 months.

Note: the admin of the account picks the name for the instance, such as awm.seework.com, which is my A Working Model account. Other instances could be on any other the five or so non-intuitive domain names that 37signals maintains for Basecamp account. Then the admin picks the login name for users. I picked stoweboyd for myself, but my clients have picked stowe, sboyd, and other variants. And, yes, I can change the passwords to all be the same, but that is a minor part of the whole thing.

And I think that nearly everyone will encounter this issue in time, as more and more companies adopt Basecamp, and seek to collaborate with other users. And what about those “clients” that Jason mentioned? Aren’t they likely to be clients of other companies, even if they aren’t the one paying the bills?

I am happy to see that Jason is planning to work on this issue at some point, and regret that he doesn’t think that it is critical enough to address right now. And I still believe that this is a design flaw in the basic social architecture of Basecamp, not a feature that only supernodes like me need. Although Basecamp has had great success, a flaw like this retards growth of the user base. If this worked in a federated fashion, it’s easy to imagine that the product would be spread more easily.

At the present time Basecamp is super dominant in the market for online social project management, but they aren’t alone. And I can safely predict that the eventual Number 1 in this space will be the player that gets the social dimension right, not just the best list of features. That could very well be Basecamp, if they focus on that tier of social architecture. But some other enterprising players could enter the market with a stronger focus on the social dimension, and by virtue of that focus could move more quickly to create a marketplace to support whatever the larger context is for all that project work. And that marketplace is worth billions more than project tools.

And, remember that Basecamp is not really winning today based on the quality of the features: writeboards, as just one example, work well enough, but let’s face it, textile is a pain in the ass as a markup language. Have you tried to indent paragraphs, or stick images into writeboards? Very kludgy.

So the strength of Basecamp’s competitiveness is the intuitive social media approach to sharing of project information. That’s the key to the product’s strength, and at the same time, hedging in that area may prove to be its Achilles Heel.

Jason and I will be attending the upcoming Collaborative Technologies Conference 2006, in Boston, in a few weeks. I think he is a brilliant entrepreneur, author, and developer, as I have said on numerous occasions (see my review of Getting Real, for example). So I hope that we will get a chance to discuss this again, in some forum or another at the event.

1. rankandfile likes this
2. stoweboyd posted this