Jared Spool: Welcome, everyone, to another episode of the SpoolCast. I have with me today Jason Fried, who is the founder and guy in charge of that wonderful design firm and business, 37signals; the people behind Backpack and Campfire and Basecamp and all of the great two-syllable products that are on the Web. Jason, welcome.
Jason Fried: Hey, thanks for having me, Jared.
Jared: Hey. So we are a Campfire and Basecamp shop here, and you guys went through this little change in the way that features work on your site—in particular, how you log in. I'm guessing that was just a simple thing that you guys whipped up in a weekend, right? [laughs]
Jason: Maybe about—let's see—about 100 weekends, almost, it took to actually get that.
Jason: Well, actually that's a little bit of an exaggeration. 75 weekends, roughly, it took to make this work, yeah.
Jared: So 100—75 to 100 is not that much of an exaggeration.
Jason: Yeah, it took a while. This is a project—by the way, it's called 37signals ID—and what it did was it finally unified our login system across all of our products. Prior to this thing we launched, which we launched in December of 2009, people had different logins for every product that they used from us.
You might use Basecamp, and you might use Highrise, and you might use Campfire, and you had different logins for each. If you had five different Basecamp accounts, you'd have five separate logins. It was just a total mess. It was fine—it just was a mess.
We undertook this big project to unify sign-ins, or logins, or whatever you want to call them. Now everybody has a single user name and password they can use for all of our different products. We thought it would take a few weeks, originally, to build this, and it ended up taking about a year and a half.
Jared: The fact that you had all of these different login things—this was because these features just—it was an evolutionary growth, right? When you were creating—I guess Basecamp was your first product, right?
Jason: That's correct.
Jared: And then as you added these other ones, at the time it didn't feel like this was something that needed to be consolidated. Is that the case?
Jason: Yeah. That's typically the way we work. Sometimes it's good, and sometimes it's bad. In this case, I guess, ultimately it was bad, although it served us quite well for five years, so “bad” is probably the wrong word.
Each product had its own sign-in system because we just built the products separately over time. We didn't think about unifying things because it really didn't matter. It's one of those weird things where you look back and you're like, “Yeah, we probably should have done it a different way up front.”
It didn't really matter. We built great products. For five years, people figured out how to log in just fine. It was something we were not really satisfied with. It also prevented us from doing a variety of other things which we wanted to do this year—which is integrating products and sharing data back and forth and stuff.
You're right to say that is was just this organic thing, and there are some other reasons, too. One of the things, within a specific product—so let's take Basecamp—each Basecamp account had its own special URL. So every site had a sub-domain, and then it had “.basecamphq.com” or “.somethingelse.com.”
What happened was that usernames were scoped to each sub-domain. So there could theoretically be 100,000 people using the same username in Basecamp, because the usernames were only based on sub-domains.
Jared: Oh, wow.
Jason: So you could be email@example.com, and you could also be firstname.lastname@example.org. That was fine, but what it ended up meaning was that we didn't know who joe123 was anymore. If there was a joe123 in Basecamp and a joe123 in Highrise, we wouldn't know if they were the same person or not because there could be 100,000 people with the same username. So we really had to fix that up, and that's what this project was all about.
Jared: Well, it's interesting…A lot of our clients actually have this exact problem, right? Because they have—for example, large banks, particularly banks which have been growing through acquisition, they've acquired…
You have a company like Chase which has acquired Washington Mutual. You used to log in to your Washington Mutual mortgage account with one user name and password and you have your Chase credit card with another user name and password. How do you get it so that you can have a single login for each of those things, even though you're the same customer? It's not unusual for large organizations to actually have this. Single sign-in is like the holy grail of IT problems to solve.
Jason: Yeah, it is a big problem to solve. The thing is that it sounds fairly simple up front to do this. Not really simple, but kind of simple. When you really dig into it, you find so many spots and places where it just makes things complicated. All sorts of edge cases. All sorts of situations where you need to reveal someone's username. Or, who can change it now and where can they change it? Is it centralized in a place to change it, or do you have to create change username and change password functionality in four different places now, or can you centralize it? And how does that effect the URL?
There are all sorts of things that just start revealing themselves over time as you really dig into the problem. Of course, there are various ways to do something. You can sort of just do it the—what we call Judo, which is basically the dead simple, easiest possible way. That would have taken a lot less time.
But this sort of thing, since you're dealing with user names and passwords, people are really sensitive about their credentials. We really wanted to make sure that the experience was really polished and really well done. I have used exactly what you're talking about.
I'm originally—I used to be banking at Bank One, and then Chase bought Bank One. Bank One, I think, was just originally banking in Illinois, or maybe—maybe it was just Illinois at the time. Anyway, I remember that login process changed, and that was really confusing, and people are really sensitive about that, especially when money is involved.
It is one of these things where you have to take a lot of time and give a lot of attention to the small, little bits of interactions that actually happen in order for people to feel comfortable.
Jared: You mentioned this project took a year and a half. Was it always planned to take a year and a half?
Jason: [laughs] Yeah, wow. It was planned, unfortunately, to take a few weeks.
Jason: Yeah. So [laughs] it kind of ballooned for us. Now, we typically don't really plan anything that's long-term. We thought that we could do this in phases. Looking back, we probably could have done it in some phases. But again, as I was saying, we just started digging into it, and it just started taking longer and longer and longer. Then, one of the issues is—that after it took more time than it was supposed to initially, we didn't start putting deadlines on things, We always thought, “Eh, it would be another week. It would be another two weeks. No big deal.”
As you just move on, and move on, and move on, and things get later, and later, and later, it just kind of balloons. This happens, probably, in a lot of projects. It's the only project that has really happened like this for us, but we learned a lot about how to scope things better and make things work better.
Jared: If you were to share with folks who could be facing a project like this that you start thinking is really short, but then starts to get longer and longer, what lessons would you share with them as to ways to harness this thing in and get it under control?
Jason: Yeah. I think this was sort of a unique case because it involved changing, for us, the inner workings, almost every line of code, basically, for four different products at the same time.
This was one of those projects where we kind of had to do everything at once. I would encourage people to continue to break big projects down into smaller and smaller and smaller bits—which is something we're doing now, which we can talk about later, maybe.
But my suggestion is to never allow a project to take a year and a half. There are always simpler versions. You can always cut it in pieces. You can always get certain things out, launched first, before you have to launch everything. And I say “always” and I do mean “always.”
There are probably just a few edge cases where you can't launch things piecemeal, which might have been our situation, but in most cases I would just keep cutting things up as small as you can and getting to smaller and smaller and smaller bits, and launch them.
It might still take a year and a half total, but at least you're seeing momentum when you launch something every three weeks, perhaps. The thing that really kills morale is a lack of momentum. No one wants to work on a project for a year and a half and not see anything come of it until the year and a half goes by.
If you can launch something occasionally, and get it out there to the public, the developers who are working on it, and the designers who are working on it get to see the fruit of their labor actually being used by real customers. That really perks them up and helps them deal with long-term projects.
Jared: Was there anything, in doing this project, that surprised you in terms of something coming together in a way that was much better than you actually had hoped it would?
Jason: Jason: Well, the actual launch surprised me. I had thought we were in for just a disastrous few weeks after we launched. I thought it was going to be just a big mess, just because it was so big. And it turned out that it was actually very smooth. I mean, that’s to the credit to the people who built it, who worked on 37signals [ID], but I was just surprised by that.
One of the things, though, that we missed was we had this thing… So if you already have a 37signals ID, and you sign up for another product, you’re supposed to use your 37signals ID to sign up for the other product, too, so your accounts are linked. And we thought we were being really obvious about that, but we weren’t. And we were like, “We’ll put a big link in the sidebar, or we’ll make a big graphic to call people's attention to it.” And so many people still missed that, and are still missing it today.
We’re still kind of working on how to make it really obvious without freaking people out who don’t have one of these things. And that's kind of the interesting challenge is we want people to have a 37signals ID to recognize that they have one and reuse it, but we don’t want new customers who come in who don't have one of these things feeling like they can't sign up for our products because they don’t have this thing that they don’t know anything about.
So it’s a real challenge to be clear and not to confuse other people, and we’re still working through that issue right now. So that was a little bit surprising to me. I thought we’d be able to nail that a little bit easier, but that’s been a real challenge, and it still is a challenge.
Jared: A few years ago, you were at our Web App Summit. And this year, you're going to be at our Masters Tour in Philadelphia and Minneapolis. And when you were at the Web App Summit a few years ago, one of the messages you honed in on was how important the copy, just the text above a prompt, was there. I’m thinking, for this project, copy must have played a huge role for you guys.
Jason: Yeah. I feel like we probably spent more time on the writing than we did on the design, and we spent a lot of time on the design. We rewrote sentences over and over and over. I would say, out of the year and a half—it wasn't a full, solid year and a half, eight hour days, every day, sort of thing—but I would say a good 25 percent of the design time was spent on rewriting labels and sentences and descriptions of this thing.
We spent a lot of time on it because it is kind of a weird thing. It's sort of a confusing sort of thing. And it just took a lot of time to get it right. I think we did a pretty good job with it, but I look back at some of the stuff now and I'm still not thrilled with it. It’s really important to get the writing right.
Jared: What were some of the things that made that time longer and, therefore, sort of worth the investment? What were some of the things that you were catching and fixing? What types of things should people be looking for in their own copy?
Jason:The one screen we worked, probably, harder on than any other screen was this screen called the transition screen, which was the screen that everybody saw when they logged into Basecamp or any one of our products after we launched 37signals ID, where it said, “Hey, thanks for logging in with your old user name and password. You now need to create a new user name and password, which will also be known as your 37signals ID. And here’s why it's good and that whole thing.”
We probably redesigned that screen, I would say, eight times. And when I say redesigned, I also mean rewrote. We looked over every little piece of it. We thought we nailed it. And then we looked at it a week later and we're like, “No, this is not good. This is not clear enough.”
The trick is, when you’re so close to something, you think it makes sense. But when you really step away from it for a while and look at it again, and you start to think about, “No one else is going to have any idea what this thing is.” We announced it, pre-announced it, and all that stuff, but there's going to be so many people who still don't know it, because they don't pay attention to announcements, and I totally get that because I don't either. So we have to make this thing just be absolutely clear to everybody.
And I think we did a pretty good job, but there's always room for improvement on something like this. But it was fun, and I think maybe I'll go over some of these different screens at the conference.
Jared: I’m curious as to the test or rubric that you use to decide whether something is going to be clear enough, because like you said, you’re so close to it, and you’re thinking about it, at that point, probably almost 24/7. So, how do you go through that process of stepping back and deciding, “You know what? This probably isn't clear enough”? Do you do some sort of usability testing, or is there another trick that you use to tell if you’ve got it where you want it?
Jason: OK, so a couple answers. First of all, we don’t really do any formal sort of usability testing. I think that usability testing, or bringing outside people in to look at this, it clearly would help in some ways, but I think it’s also just, you only kind of really get this when you’re going through the real process.
And I think that’s one of the tricks with this sort of thing is it’s like you can bring people in to read a screen or to kind of fake go through the process, but it’s only when you’re hurried and you’ve just logged into Basecamp and you need to check a new to-do list, and all of a sudden you see this screen, for real.
Jason: That’s the only time you can really evaluate whether or not this is clear or not. And so I think it’s really hard to simulate those situations.
So the way we do it is we design something and work hard on it and put it up for ourselves, while we’re building the system, and then we kind of don’t look at it again for a week or so. And this isn’t formalized. We don’t say, “Let’s not look at it for a week.” But we think it’s done. And then we run through the process again.
We know what to do, but we kind of try and forget what to do, and really read it and go through it again, and then we just realize this is just not clear enough, or this is clear, or whatever. So it’s just kind of us trying to forget what we know, over and over and over, when we go through this process.
Jared: So, to some extent, you’re role-playing one of your users and you’re saying, “OK, but if I didn’t know how this was built, and I got this screen, what would I be able to get from this screen?”
Jared: Particularly, and I think you’re right, this idea of the context, the context being I’m logging in because I’ve got a deadline later this afternoon, and I know there’s to-do-list items I have to nail before the deadline, and I haven’t been paying attention to these announcements, or if I have, I’ve completely forgotten that today is the day. And so I’m logging in, and what’s on my mind is to get those things off my to-do list, and all of a sudden I'm confronted with this screen that’s preventing me from getting to my to-do list.
Jason: Yeah. And that’s the thing is you have to keep that in mind. The context is so important. People are rushed, and they’re in a hurry, and they don’t want to do this. Even though we can lay out all the benefits, they still don’t want to do it because it’s just in their way. And I totally get that. So we worked really hard to eliminate a lot of words, make the sentences as short as possible, make any paragraphs—we tried to explain everything in like three sentences, basically, and really brief.
While we were doing this, I think Facebook launched a new privacy- settings thing, where they required you to go to change the privacy…
Jason: And we looked at their screen, and I was completely confused by it. I thought there were too many words. I didn’t know what to do. And we just kept looking at that and going, “Gosh, we don’t want to be like that to our users. There’s too many things going on here.”
Jason: They had a lot of words.
Jared: They did, yeah.
Jason: So we really worked on making this as short and concise as possible, writing the paragraph and writing the sentences to a length that you feel like it’s worth reading this because it’s so short. But I remember looking at the Facebook stuff and thinking, “This is almost a short story, and I don’t have time for a short story right now.” So, length was really important for us.
I don’t know. It’s tough. It’s really tough. But we did work really hard on it and focused most of our attention on this one particular screen, because it was so important.
Jared: I think that makes sense. And I think the idea that you would come back to the same screen over and over and just keep sort of making sure you got it just right, knowing that that’s sort of the linchpin of the success of this project, is something that people forget. They check it off their list and they say, “We’re done with it,” and they move on to the next thing. And they don’t say, “Should we go back?”
But you guys were really sort of focused on making sure that this went as smoothly. Finally, like you said, it paid off, because the launch was not the customer-support flood that you expected it to be.
Jason: Right. The reason why we kept going back to it is because we kept using it. So what we would do is we would do some other stuff in the system that we needed to update, and we’d push the stuff to the staging server, and we’d start from scratch every time because that’s just how we wanted to go through the process. We never started from the middle. We always started from scratch, which means we always had to see this screen every time we did this conversion from our old account to a new account.
And I think that’s really the lesson here. The screens don’t ever stand alone. They’re part of a flow. They’re part of a process. And you can’t skip over the early ones and get to the later ones, because the early ones are the only way you’ll get to the later ones, if you understand the early ones. So we always started from scratch, every time we went through this process, and we went through it often. And that’s how we kept noticing this process and understanding this process.
Jared: Well, kudos to you for not becoming immune to that screen, not having gone through it so many times that it’s like you don’t even notice it’s there anymore; you just answer the questions and move on. A lot of folks in the testing process, they get that sort of immunity to stuff.
Jason: Yeah. And one of the reasons why we weren’t as immune as we maybe could have been was because we kept changing it so often.
Jason: And so you kept seeing new things each time, and you’re like, “Wait, this is different than I remember it, so it’s kind of new to me, and so let me see if I know how to do it.” So there was a lot of that going on. I think we kept a pretty good record of all these variations in this design, so It’d actually be fascinating to go through these again in front of your audience.
Jared: Yeah, I think it’d be a lot of fun to walk through these, so I look forward to that.
Now, you mentioned to me that you guys have sort of changed the way you’re working together. I’d be curious if you could say a little bit about that.
Jason: Yeah. So, actually, we changed the way we’re working together starting in 2010. And we did it, basically, because what we found was, at the end of this 37signals ID project, we changed the way we were working to work with small teams again. Prior to the end of the project, we basically had one programmer working on it and one designer working on it. And near the end, we brought another programmer on and another designer. So we had this small team of four people working on this whole thing, and we found it worked a lot better that way.
In the past, we’d typically been working very independently. Anything that had to get done was pretty much one programmer did that, and another programmer did another feature, another programmer did another feature, or infrastructure project or whatever. And we found that when we broke back into small teams, we got a lot more stuff done. Morale was better, that sort of things. And it seems kind of obvious right now, but at the time it wasn’t so obvious for us.
So what we started to do in 2010 was we have a whole new system of working where teams organize. We have enough people to make two teams, and a team is two programmers and one designer. So a team is three people. And we have enough people to only create two full-time teams, really. So these teams organize, and they work together for two months, and during the two months, they work together on four iterations. And an iteration is two weeks.
So they pick features from a list, or they come up with the ideas that they want to do, and they only have two weeks to finish those things. And at the end of two weeks, if those things are not done, then they basically go to die. Those features will not be picked up. They could be picked up in a later iteration, but you don’t get another week to finish them. You either finish the stuff in two weeks or it just doesn’t get deployed. And that really focuses you on getting stuff done in two weeks, which basically means you have to cut scope further back.
So you really just pick stuff that you’re going to be able to do, and if you can’t get it done, you start pulling stuff out instead of saying, “Well, let’s give it another week to get it done.”
And what we’ve found is that by forcing teams to only have two weeks to work on something—and something could be three small features, or it could be one bigger feature—we’re able to really get down to the essence of what’s important in a feature, and we’re able to get it done and get it launched and get our customers excited about it and then move on to the next thing. And there’s this constant state of launching and this constant state of enthusiasm, because the work you just did is now live, and customers are talking about it and enjoying it. So it’s been working out great.
And we’re almost done with the first two-month term. At the end of two months, which will basically be March 1st, the teams will break up, reorganize again into new teams, and start the process over again.
Jared: Dare I say this smells a little agile-like?
Jason: [laughs] I’ve heard that. We don’t really follow that methodology, necessarily, but maybe we do in some ways.
Jared: Well, the key components are that you’re time-boxing, right?
Jared: So you’re keeping things within a particular scope. You’re working in a team together. And you’re letting the time sort of bubble the most important features up. You’re letting the time constraint bubble that up, versus letting some other business requirement keep adding features until you’ve got this big thing that you can’t possibly get done.
Jason: Right. So, in some ways, that is very similar, yes.
What I don’t know about the agile process is if they change groups up often. So, we think it’s really valuable for the teams not to get too used to working together. They can work together for two months, but after that, it’s time to break up and reorganize.
And the reason we think that’s good is because, first of all, everybody gets to work with each other that way. People who’ve worked on other teams that might have worked better can share some of the learnings with their new team. And I think it’s just, in general, a good idea to break people up every few months and get a new team together and some new momentum together and work together that way.
I can say that the last six weeks have been the most productive six weeks we’ve probably ever had as a company, so I’m pretty excited about the new system.
Jared: Well, yeah, and it’s showing in all the new features you guys have been rolling out lately. There’s been a whole slew of stuff, in at least the products that we’re using, and they’re all for the better, I think.
Jason: Thank you. Yeah, thanks. We’ve made some huge improvements to Highrise. We’ve made some huge improvements to Campfire. We’re almost done with our two week—actually, today’s the last day of this Basecamp thing we’ve been working on, so there’s a lot of new stuff coming for Basecamp.
The other thing we’re doing, by the way, is we have a slack team. So the slack team is, again, two programmers and one designer…
Jared: And these are people who just slack off permanently. That’s their job.
Jason: [laughs] That’s correct. Yes.
Jared: It’s good work if you can get it.
Jason: I like that idea, though, because I’m on the slack team, so I like this.
Jason: But the slack team, basically, is like a free-agent team, where they can help any of the teams that need additional help to get something done in their two weeks, or they can take on other projects, or they can deal with stuff that crops up, like a bug fix or whatever. So it’s a pretty great system. We’re very, very happy with it so far. It’s still early, but people seem to really like it, and I know our customers are pretty pumped about the stuff we’ve been releasing so far.
Jared: Yeah. Well, the cross-pollinating thing, I’ve seen other people who do that, where they break up teams intentionally and disperse them and bring them back. That really has positive effects.
Jared: At first, people who are on the teams are a little disappointed, because they’re just sort of getting used to the people they’re with and they like them…
Jared: But the benefits of sending people out into the world with the knowledge they just gained and letting them bring that into other projects has the advantage that it’s like, “Hey, wait a second. We’ve already solved that problem over here. And you probably weren’t paying attention because you were heads-down on your stuff.” You get a lot of benefit from that.
Jason: Right. I agree. And the other thing is we’re a small company. Maybe four months down the road, you’re going to be working with the same people again. So it’s not like we have 100 people and you never get to work with anyone that you just worked with again. So, you get to work with everybody pretty frequently here.
But yeah, I totally agree. And I’m eager to see how the team shakeup works, because we haven’t done that yet, since we’re still in the first version of this. So March 1st is when we split the teams up again, and curious to see how that works out.
Jared: Well, cool. Well, I want to thank you for taking this time for talking to us today. This has been really fascinating, and I’m very much looking forward to it. As you may have noticed, everybody, Jason’s going to be at our Minneapolis and Philadelphia Web App Masters Tour stops. You can find out more about that at uietour.com. Of course, you can find out all about Jason and the work that his company does at 37signals.com. And I’m very happy that you were able to join us. Thank you very much.
Jason: Thanks, Jared. I’m looking forward to the two shows. Thanks again.
Jared: Excellent. And thanks to everyone for listening. And as always, thank you for encouraging our behavior. Talk to you next time.