Tag Archives: 37signals

37signals rebrands to Basecamp

I first blogged about 37signals a couple times back in 2002, and I’ve been a fan ever since. They had a huge influence on the way I approach design and the way I like to build products, not to mention a big impact on a whole new class of “software as a service” web apps.

The decision last week to go all-in on Basecamp left me puzzled. Daniel and I discussed this at length on Core Intuition. It’s one thing to focus all your efforts on a single product, but seems quite another to rename the whole company around it. I still feel that once you make that choice, your hands are tied from ever thinking big again, from ever wanting to grow beyond the scope of a single product. It’s like saying “our best product ideas are behind us”, and I know that’s not true for 37signals.

On the other hand, I’m sure 37signals understands their business better than I do. And maybe even big decisions are temporary anyway. I’m excited to see how it plays out in another year or two.

You can listen to Core Intuition episode 123 and let us know if we’re off base or not. Last week’s show also has more about choosing a product lineup, managing time, and thoughts on App.net’s Backer. Thanks to Smile’s PDFpen for sponsoring the podcast.

Making time for marketing

Like many programmers, I’m often fooled into thinking that it’s enough to build a good product — that people will find it on their own, instantly recognize its value, and pay for it. It’s easy to forget that even great products need marketing to succeed. For a one-man shop it’s important to take a break from writing code and work on how the app is sold.

Building a business is hard. I started Riverfold Software 6 years ago and in many ways it has fallen short. And for some of the past year, I’ve squandered the success of Tweet Marker, failing to practice and experiment with how to make money from it.

Jason Fried of 37signals wrote for Inc Magazine last year about how making money takes practice:

“One thing I do know is that making money is not the same as starting a business. For entrepreneurs, this is an important thing to understand. Most of us identify with the products we create or services we provide. I make software. He is a headhunter. She builds computer networks. But the fact is, all of us must master one skill that supersedes the others: making money. You can be the most creative software designer in the world. But if you don’t know how to make money, you’re never going to have much of a business or a whole lot of autonomy.”

In the last week I’ve taken a couple steps in the right direction. I’ve finally redesigned the Watermark home page around a simpler marketing statement of what the app is about. And as discussed on the recent Core Intuition, I switched from PayPal to Stripe in an effort to make payment smoother and subscriptions easier to track. There’s still a lot to do, but I hope to make even more time for marketing before the year is up.

The neverending feature backlog

Excellent piece from Joel Spolsky yesterday on software inventory and bug databases:

“The trouble is that 90% of the things in the feature backlog will never get implemented, ever. So every minute you spent writing down, designing, thinking about, or discussing features that are never going to get implemented is just time wasted. When I hear about product teams that regularly have ‘backlog grooming’ sessions, in which they carefully waste a tiny amount of time and mental energy every day or every week thinking about every single feature which will never be implemented, I want to poke my eyes out.”

Reminds me of the original Getting Real from 37signals. Back in 2006:

“So what do you do with all these requests that pour in? Where do you store them? How do you manage them? You don’t. Just read them and then throw them away.


“It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones. Don’t worry about tracking and saving each request that comes in. Let your customers be your memory. If it’s really worth remembering, they’ll remind you until you can’t forget.”

10 years and 37signals

Every year on March 9th, as SXSW is getting started, I like to mark the anniversary of this blog. This time it’s the 10th year.

“My second post back in 2002”:http://www.manton.org/2002/03/ernest_kim_and_jason.html was about a panel run by 37signals. I wrote:

“Ernest and Jason really get it — I hope they inspire some designers to think about web sites in a new way, and finally start focusing on usability and page load time and cut the fancy graphics, roll-overs, and animations.”

This was a couple years before they reinvented themselves as a software company with Basecamp. As the “new Basecamp launches this week”:http://37signals.com/svn/posts/3129-launch-the-all-new-basecamp, it’s fascinating to think back on how far 37signals has come. The web is bigger now and more complex. Subscription web apps are everywhere. But I think the focus on performance that drove Jason Fried and his original co-founders to promote simple design in that SXSW panel a decade ago is still very much at the heart of what 37signals does.

Focusing on the wrong things

“Great post from Garrett Dimon”:http://garrettdimon.com/post/6724266888/my-biggest-mistake, on his biggest mistake building the bug-tracker Sifter:

“I got bogged down watching our bottom-line even though we’ve always been comfortably profitable. I worried about preventing fraud even though the only instance we ever encountered only cost us $200. I constantly worried that Sifter could go down at any moment even though we’ve had 99.96% uptime since launch. […] All of these little things were distracting me from the work that really mattered.”

For a small company, focusing on the wrong things will make or break a product. I’m guilty of the same thing. I sat on “Tweetmarks”:http://tweetmarks.net/ for 6 months without launching it because I was worried about how to pay for hosting and how to get developers involved.

Sometimes there’s no obvious solution until you ship. Eventually it becomes easier to know when to be patient — to solve a problem right the first time — and when it’s needless worrying over something that may or may not even happen. And as 37signals says: “decisions are temporary”:http://gettingreal.37signals.com/ch06_Done.php anyway.

Interruption and collaboration

Jason Fried, “from a recent interview”:http://37signals.com/svn/posts/2494-the-big-think-interview-take-two: “Interruption and collaboration are different things.” If you haven’t listened to a Jason Fried talk recently, this one covers a lot of good stuff.

I also like “episode 19 of their podcast”:http://37signals.com/podcast/#episode19, which is edited from a live recording of a planning session for Rework. My first impression of Rework was that it was too finely edited — that to get to the essence they threw away too much material. I wanted to hear more case studies from their business, approaches that worked or didn’t, and lessons learned.

But I’ve flipped through the book again, a few months later, and it holds up. I don’t know if it was intentional or not, but the lack of filler text gives it a certain timelessness. Each chapter is one core argument, and whether that topic resonates with the reader or not depends entirely on what you and I bring to it from our own job experiences.

Campfire Beep

I’ve been living in Campfire quite a bit over the last few days. It’s a great app, well designed and very fast. But it suffers from a problem that iChat and other AIM clients do not have: it’s easy to forget about a chat room while working on something else because there’s no audio or visual notification that you missed a message.

I whipped up a tiny AppleScript that monitors the chat and beeps if there have been any changes. It’s simple but it works fine for me, and should make do until someone writes a full WebKit-based Campfire client app with more options, or until 37signals releases a supported public web services API.

Requirements and how it works:

  • Requires Safari. Does not work with Firefox or Camino.
  • Campfire must be in its own web browser window, or the front tab in any window.
  • Every 2 seconds, it grabs the HTML from the <div> that Campfire uses for the chat messages. If it has changed since the last time, it beeps.
  • Only beeps if Safari is not the frontmost application.
  • If you are in multiple chat rooms, only works if they are in their own window and visible on screen.

Download: Campfire_Beep.dmg (90K)

Just open the application in Script Editor to edit it. Or view the full source.

Comments? Email manton@manton.org. Enjoy!

Update: I updated the script so that it doesn’t display errors, more correctly identifies URLs, and supports multiple open Campfire chat windows.

This just in: 37signals added sound notification to Campfire today! So this little AppleScript is officially obsolete. I’d like to take credit for convincing them that such a feature was needed, but we all know how they love to build features that won’t roll-out until the 2nd week after launch. :-)