You’re reading Signal v. Noise, a publication about the web by Basecamp since 1999. Happy !

Launch: The 37signals Suite

Jason Fried
Jason Fried wrote this on 47 comments

This has been five years in the making. We didn’t know it at the time, but ever since we released our second pay product (Backpack) in 2005, we’ve been building up to this moment.

Today we officially release the 37signals Suite. The Suite is a bundle of our four big apps: Basecamp, Highrise, Backpack, and Campfire for one low price (starting at $99/month).

37signals Suite

The core benefits

For the initial release of the 37signals Suite, we targeted three key customer requests:

  1. Big savings over purchasing each app separately. Basically you get four for the price of just about two. Depending on which apps you have, and which plans you are currently on, the savings can be significant.
  2. Simplified billing. Instead of getting charged separately for multiple apps, you’ll get a single charge from us on your credit card every month. You can update your credit card, upgrade your plan, downgrade your plan, or cancel all from one screen as well.
  3. Unified users across all your apps. Before the Suite, if you had Basecamp and Highrise, you’d have to create the same users in multiple apps. That was a pain. The Suite shares uses across all the apps. You can create and manage all your users across all your apps from a single screen. Much easier.

The plans

The Suite launches with three plans: Starter at $99/month, Pro at $149/month, and Elite and $249/month. Each plan is well equipped and generously stocked with plenty of file storage, Basecamp projects, Highrise contacts, Backpack pages, and Campfire chatters and conference call minutes.

Abolishing the “participation tax”

Basecamp never had a user limit. From the free plan to the most expensive Max plan, you could add an unlimited number of users to your Basecamp account. However, Highrise, Backpack, and Campfire followed the industry-standard “charge per seat/user” model.

We’ve never particularly liked the charge per user model. We call it the participation tax. The more people involved, the more you pay. That’s not the best way to encourage collaboration.

So with the launch of the Suite, we’ve abolished user limits on all our apps. When you upgrade to the Suite you get unlimited users on Basecamp, Highrise, Backpack, and Campfire. Invite all your employees/collaborators to your account and get work done without having to think about cost-per-user.

How to get the Suite

Currently the 37signals Suite is only available for people who already own a Basecamp, Highrise, Backpack, or Campfire account. If you own any one of these apps you can upgrade to the Suite in less than 60 seconds. We will be offering the ability to sign up for the Suite from scratch down the road, but we just don’t know when yet. Note: If you don’t own one of our products yet, and you’d like to purchase the Suite, just sign up for Basecamp, Highrise, Backpack, or Campfire and then follow the upgrade instructions above.

The team

We’ve been working on the tech and design to make this all work smoothly for many months. It may look simple from the outside, but it involved ripping out and reworking huge chunks of code in every app. We wanted to do this carefully, thoughtfully, and properly. We’re really happy with the results.

Credit for this project goes to Ryan, Jeff, Pratik, and Jamis. These guys were the core contributors to the project. Lots of other people were involved too. Jason Z and Jamie D made everything look great, and the whole sys admin crew (Taylor, Joshua, and John) made sure the team had everything they needed. Sarah, Michael, and Jason in support have been helping customers with any questions that have come up. Incredible teamwork from everyone.

The start of something great

Today the Suite saves people money, simplifies billing and account management, and unifies users across all the products. But that’s just the beginning. We have a lot of ideas for how to make the Suite even better. Stay tuned as we continue to improve.

Thanks for listening. We hope to see you on the Suite!

Two products of software development

Ryan
Ryan wrote this on 14 comments

Here’s an interesting quote from Kent Beck. He says:

The product of software development is two-fold:

• The behavior of the system
• The options for extending and modifying that behavior in the future.

That second point summarizes what good software design is about. Each feature we build in our code gets us closer to release. But the way we build each feature can set us on different paths. If we don’t care how it works, as long as it works, then our launch may come and go without a problem. But when it’s time to return to that feature and make a change or an improvement, we’ll likely find ourselves wading through a tangle of spaghetti.

We want to take the other path, where each coding decision carries a question with it: What will I think of this code when I need to change it in six months? Will I understand it? Will changing this break other things, or will the change be isolated? This habit, to the extent that we can keep it up, allows us to keep improving our apps instead of getting stuck in spaghetti.

On Writing: How Conan wrote his pitch-perfect "People of Earth" letter

Matt Linderman
Matt Linderman wrote this on 19 comments

When you think of great writing lessons, you usually don’t think of late-night TV hosts. But Conan O’Brien’s “People of Earth” letter was a pitch-perfect response to a crisis situation. It became big news and set the tone for everything that happened afterwards in the NBC/Conan/Leno debacle. And it offers lessons for anyone who needs to put a public face on a shitty situation.

A closer look
The note starts off light by addressing readers as the “People of Earth.” Then he declares himself lucky.

I want to start by making it clear that no one should waste a second feeling sorry for me. For 17 years, I’ve been getting paid to do what I love most and, in a world with real problems, I’ve been absurdly lucky.

“Don’t feel sorry for me” is a great way to endear yourself to people in a time of trouble. Though this is obviously nowhere near a life-and-death situation, the approach here is vaguely reminiscent of Lou Gehrig telling a stadium of fans that, despite his illness, he considers himself “the luckiest man on the face of this earth.”

Conan then lays out an argument that is based on the legacy of the Tonight Show as opposed to himself.

I sincerely believe that delaying the Tonight Show into the next day to accommodate another comedy program will seriously damage what I consider to be the greatest franchise in the history of broadcasting. The Tonight Show at 12:05 simply isn’t the Tonight Show…My staff and I have worked unbelievably hard and we are very proud of our contribution to the legacy of The Tonight Show. But I cannot participate in what I honestly believe is its destruction.

Now it’s about history, tradition, and Johnny instead of just some celeb moaning about being wronged.

He closes by admitting that he has no idea where things will go from here.

There has been speculation about my going to another network but, to set the record straight, I currently have no other offer and honestly have no idea what happens next.

Instead of playing hardball, he plays heartfelt. And the honesty worked. People rallied to his side and Team Coco was born.

The backstory
Now the behind-the-scenes story of how this letter came to be is coming to light. According to “The Unsocial Network,” which looks at the Conan/Leno showdown, it started when Conan’s team first learned what NBC was up to. They reached out to “the best, toughest” litigator they knew, Patty Glaser, and she got together with Conan and his team.

Continued…

The class I'd like to teach

Jason Fried
Jason Fried wrote this on 94 comments

During Q&A at a conference I spoke at a few years back, someone asked me “What’s your take on the true value of a university education?” I shared my general opinion (summary: great socially, but not realistic enough academically) and ended with a description of a course I’d like to see taught in college. In fact, I’d like to teach it.

It would be a writing course. Every assignment would be delivered in five versions: A three page version, a one page version, a three paragraph version, a one paragraph version, and a one sentence version.

I don’t care about the topic. I care about the editing. I care about the constant refinement and compression. I care about taking three pages and turning it one page. Then from one page into three paragraphs. Then from three paragraphs into one paragraph. And finally, from one paragraph into one perfectly distilled sentence.

Along the way you’d trade detail for brevity. Hopefully adding clarity at each point. This is important because I believe editing is an essential skill that is often overlooked and under appreciated. The future belongs to the best editors.

Each step requires asking “What’s really important?” That’s the most important question you can ask yourself about anything. The class would really be about answering that very question at each step of the way. Whittling it all down until all that’s left is the point.

I hope to be able to teach this class one day.

You can’t improve a design when you’re emotionally attached to past decisions. Improvements come from flexibility and openness.

Another round of lessons learned from our new team-based way of working

Matt Linderman
Matt Linderman wrote this on 24 comments

Back in January, we began working in teams.

A team is made of three people: One designer and two programmers. A system administrator will also assist the team when necessary…

Each team will stay together for two months (a “term”). When two months are up, the teams split up and form again with different people. This way everyone gets to work with everyone else…

During the two month term, there will be four iterations. An iteration lasts for two weeks. An iteration can tackle one feature, a variety of smaller features, or part of a bigger feature that will require multiple iterations to complete.

It went well and we’ve stuck to this model while also evolving it along the way. This two-month recap offered up the results of the first term and some lessons learned. For example:

Lesson: Get out the scope hammer early and often
For two week iterations, true scope should be nailed down no later than half-way through. We found ourselves up against the wall a few times because we didn’t cut scope early enough. So we decided that on Monday of the second week we’ll review the work done during the previous week and the work remaining to complete the iteration. Since humans are notoriously bad estimators, we’ll be extra conservative with scope. We’ll bring out the hammer and beat down the scope. And then we’ll do it again on Wednesday, two days before the end of the iteration.

It’s now nine months later, so let’s check in again and see what else we’ve learned since then.

Lesson: Deploy is not the finish line
After an iteration is deployed, teams now go into a cooldown phase — something we didn’t have originally. This means team members go into support mode and deal with issues related to the deploy and any general concerns coming back from the Support team. That means fixing bugs, revising copy in the help section and/or email responses, and responding to queries at our Answers forum.

There’s no set length for this phase since you can’t plot exactly how it will play out. So we wait and see. We only assume the latest deploy is good to go once Support is in the clear for 6-12 hours. Then, and only then, is it time to move on to a new iteration.

Worth noting: It’s usually not a full court press on Support in this phase so this period also serves as a general cooldown and cleanup period. If one of the programmers is chasing an on-call issue, the other can refactor some code from the iteration that could be a general plugin. Meanwhile, the designer can help someone else explore an idea.

Lesson: Get away from calendar mode
We originally thought it best to have teams work strictly in two week iterations. But we’ve realized mapping iterations to calendar days causes problems. If you go from this Monday (the 1st) to that Monday (the 14th), you ignore vacations, holidays, summer schedules with 4-day workweeks, etc.

So we now measure iterations in number of working days. We’ll estimate how long it will take a team to finish a unit of work. If it’s seven working days and it’s during the summer, that means we’ll work on it Monday-Thursday (4 days) and Monday-Wednesday (3 days). We’ll then deploy on Wednesday night.

If something pops up that distracts the team for a day — say a major emergency or the need to help some other team out — everything just shifts forward a day. The deploy that was scheduled on Wednesday moves to Thursday. This means that iterations can end on any day of the week and start on any day of the week.

We noticed a similar issue with the length of team terms. It can be hard for a team to gel if it’s two-month term is during heavy vacation times (say, August or December). We’re now trying three-month terms to give teams more time to work together.

Lesson: Track your iterations
It’s important to stop and take a look back at how the time was spent. A term time card for a two-month term might look something like this:

Iteration 1: Estimated 7 days, actual days 7, quiet period 2 days
Iteration 2: Estimated 5 days, actual days 6, quiet period 1 days
Iteration 3: Estimated 10 days, actual days 9, quiet period 3 days
Iteration 4: Estimated 4 days, actual days 5, quiet period 3 days

When we look back at this time card, we see that Iteration 4 had the most problems. It was off a day and it had the longest quiet period relative to its duration. At that point, we know to dive in for closer review and see what caused issues with that iteration.

Lesson: Have a project “scribe”
At our last meetup, one of our Sys Admins expressed feeling out of the loop with the teams. Of course, we’re now at 20 people so no matter how we try, it’s going to be harder to keep the same intimate vibe we had when we were half that size. But we are taking steps to keep that tight-team feel whenever we can.

For one thing, we plan on meeting in person more often. The new office has helped spur more face-to-face meetings and trips to HQ for out-of-towners.

Also, we’ve added a role for project “scribe.” There’s one on each team and that person’s responsibility is to keep everyone else informed of what’s happening. The scribe posts a summary at the beginning and end of each iteration explaining what’s being tackled, what we got done, what issues arose, what delays occurred, etc. When everyone knows what’s going on with everyone else, the company feels more connected.

Continued…

Win a free Griffin iPad Stylus along with a copy of Draft

Matt Linderman
Matt Linderman wrote this on 7 comments

stylusWe’re teaming up with Griffin Technology to give 10 people their iPad Stylus along with our Draft app. Visit Griffin for full directions on how to enter.

Griffin’s Stylus is among the most popular iPad Stylus on the market. Bob Tedeschi from The New York Times recently wrote about it in his Gadgetwise column:

Use a good stylus like one from Griffin Technologies. It’s $20, but unlike other products on the market, it feels like a pen and its metal clip holds fast to your iPad notebook. And it won’t snap easily, like the many plastic stylus devices on the market.

Jason Zimdars is one 37signals designer who uses the Stylus. His thoughts on it:

It gives you a little more precision than using your finger because the tip is smaller than your finger, especially because you can see better. Your finger covers more of the image when you’re drawing. But for me I think more than anything it just feels more natural to use a pencil-like tool rather than a finger when you’re drawing. So it’s more natural for me to grab an iPad and the stylus just like I would a pen and my sketchbook.

Draft is a straightforward sketch app for iPad. You can get it in the App Store for $9.99.

More details on the contest and how to enter.

The IV drip of pleasure you get from solving one little problem at a time

Matt Linderman
Matt Linderman wrote this on 16 comments

closeThe overwhelming way: Head down forever and hope there will be a big payoff at the end.

The problem: The finish line always seems like it’s miles away. You spend 99% of your time anxious and only experience joy at the end (if ever). Sometimes you’re so intimidated by the idea, you give up.

A more soothing approach: Break what you’re doing into smaller, incremental units. Then you get to celebrate each step of the way instead of waiting until the end.

Artist Chuck Close is someone who chooses this approach. He’s famous for his portraits of faces despite suffering from prosopagnosia — aka face blindness. He overcomes this by working in incremental units. He uses a pixilated approach to painting that turns faces into a grid of individual squares. In this interview, he explains why.

The fact that there are incremental units is driven by my learning disability. I was overwhelmed by the whole. How am I going to make a head? How am I going to make a nose? It’s too overwhelming. It makes me too anxious. But if I break it down into a lot of little decisions…

This was a coping mechanism I used all throughout school and everything that I did. Take something overwhelming and anxiety provoking and make it into little, not-so-scary decisions and have it be a positive experience. Because every time I completed a square, I didn’t have to wait until the end to get pleasure. I could solve one little problem at a time and the pleasure came with each one of those.

Solve one little problem at a time and you get a steady IV drip of pleasure. And that’s great motivation to keep going.

Continued…