Andrew: Before we get started, this interview is sponsored by Fast Customer. You ever have to make a phone call, say, to your bank, but don’t want to wait on hold for half an hour until a real person gets on the phone? Well, with Fast Customer, you just do what I do. It’s right here on my iPhone and I’ve had it since it launched. You just type in the person you want to reach. In my case, I’m going to go CitiBank, Credit Card, Support. They will call them. They will get a person on the phone and then they’ll connect me. I don’t have to press one, or press zero, or do any of it, or wait on hold. I get to go back to work and they call me when the person is available to talk to me.
And I do this with AAA, if I needed to, and I did a few weeks ago. I do this with CitiBank, with tons of companies. Any company you want to reach, just about, is going to be in there. Go to fastcustomer.com and get the app right now for your iPhone or Android device. And, if you’re a company, and you don’t want to keep your people on hold forever, and maybe you want some insight into their customer satisfaction, go to fastcustomer.com and partner with them.
My second sponsor is Shopify. You already know that Shopify is the easiest way to get a store online and you know that Shopify stores increases sales for their store owners, but they don’t want to reach you. Shopify is sponsoring Mixergy because they know you’re an influencer and they want to reach your friends. So if a friend of yours says, “I need to sell something online,” I’m hoping you’ll remember to say, “Shopify is the number one way to sell online.” Anyone can set up a store right now on shopify.com.
And finally, Scott Edward Walker. You know what he specializes in, working with entrepreneurs like you, especially in the tech world. If you need a lawyer, don’t take my word for it, look at all these great testimonials by great entrepreneurs who you know and respect. They all say the same thing that I do, “Go to walkercorporatelaw.com.”
Here’s the program.
Everyone, my name is Andrew Warner, I’m the founder of Mixergy.com, home of the ambitious upstart and the place where you come to listen to successful entrepreneurs tell you how they did it.
How does one of tech’s most trusted entrepreneurs use his past experience to launch a new product? For ten years, Joel Spolsky taught us about software development on his blog, Joel on Software. He also built up his own companies, Fog Creek Software, makers of web-based project management systems, and Stack Exchange, a collection of authoritative question and answer sites. He recently launched Trello, an online collaboration tool, so I invited him here to teach how he built and launched it. Joel, welcome.
Joel: Thanks. Thanks for having me on.
Andrew: Hey, last time I had you on here was the day that you announced that there was a big setback with Stack Exchange, or the direction you were planning to go in didn’t work out.
Joel: It was a pivot.
Andrew: It was a pivot. How are things now? How many pages now on Stack Exchange?
Joel: Oh boy. Gee, I’m not exactly sure. Five million a day, or something? It’s a lot.
Andrew: Five million a day.
Joel: Yeah. We had sort of mis-launched the first version of Stack Exchange. And just to clarify for our listeners, Stack Overflow was our first programmer-oriented website and that’s sort of the tent pole. And the goal was to try to expand that technology into as many other verticals as possible. And our first attempt at doing this was sort of the intuition of having been a software company, Fog Creek, saying, “Let’s take this awesome software that we built and sell it.” And our very modern twist was that it’s going to be a software as a service as opposed to installable software. But the idea of selling the software was still the interesting idea there. And that didn’t really work out.
It turned out that very few people had the coincidence of being willing to pay for the software and having an audience or the ability to build an audience that could reach the critical mass necessary for a successful Stack Overflow style knowledge exchange Q&A site. At the time that seemed like the right thing to do. In reality, a few small sites got off the ground that way, maybe five small sites and one big site, which is Math Overflow, and all those sites are more or less in the process of now being merged into the new Stack Exchange 2.0 model, which has worked much better and in a very short amount of time, we’ve gotten to fifty successful sites.
Andrew: Really big, this is clearly the better direction to take the company in, but I remember at the time I said to you, “Joel, we all trust you. We turn to you to teach us how to build companies. And here you are, you took your business in a direction that failed. How do feel about that?” And you were actually just, “I feel okay. I mean, it’s part of the process.” Why did you feel that way, that it was part of the process? Especially with so many people at the time who were angry at you. Why are you taking this away? Why are keeping them from creating their own huge success story along the lines of Stack Overflow.
Joel: Yes.
Andrew: How did you do it? I want to learn how you did that. When I have a big set-back and when my audience does, we won’t see it as the end of the world and we will be able to think the way Joel thought about it, which, clearly, has worked for you now.
Joel: Maybe I’m just a mellow person.
Andrew: There is a reputation on the line. You’re selling a course about programming. You’re selling a blog, not selling it, but you’re teaching us.
Joel: I hate to use a sports metaphor, I don’t really follow the sports but nobody bats a 1,000.
Andrew: Yes.
Joel: It’s an impossible thing to achieve in Soccer or in whatever other sports have, Cricket, where do they bat? Or if you look at politics, I think a national-level politician would be super lucky if they could get 55% of the people to think they were doing a good job and the perfect politician would get a 60% approval rating.
As an entrepreneur, you’re going to get about 30% of things right, if you’re doing really well. I would say that is about my ratio. Listeners who are following at home, I think I’ve launched 10 products for all intents and purposes, since creating FogCreek. If you evaluate those, some are humongous successes. StackExchange became its own company. FogBugz became a huge cash cow and enormously important project management tool.
One of the products that I launched is what we called the Indian Job Board. It was a version the Indian market of the Joel on Software job board. It got one job listing, 50 rupees. Our biggest failure ever. I’m very proud of that but a lot of things that we launched we thought were going to be very successful turned out … And we can tell you afterwards why they were failures or successes but that happens a lot. Not everything really works.
It is really important to set yourself up in a system in which you can try things rapidly, you can close things down that aren’t going to work. We were going to do a conference called StackOverflow dead days. We did one a couple of years ago. That was a big success. We tweaked it and raised the price, a little bit, from $99 to $500 and the new version was a flop. It was not going to sell out; it was not going to cover its costs.
So we canceled it, after putting a lot of work into that and ended up taking a write-down but it feels great the day after you cancel it. You’re like, ‘Phew, now I don’t have to worry about that anymore, that’s behind me.’ You just hope that 1 out of 3 of the things you’re trying is working out well.
Andrew: What about this now? You just talked about three different things that didn’t work. You have in Trello a business tool, if used the right way, my team needs to depend on it. I need to train my people here. I need to say we are going to forget about our alternatives.
Joel: Right.
Andrew: We are going to start using Trello. How do you get us to use it and fully commit to it if you have a mindset ‘If it doesn’t work, I’m going to have to kill it’?
Joel: We have never really killed things that people were using, to be quite honest. The StackExchange 1.0 sites, anybody that had a site that was working, that site is still running, they have either migrated to StackExchange 2.0 or we are just continuing to operate the site on StackExchange 1.0. It doesn’t cost us that much to do it.
If you had starting using FogCreek CityDesk in 2000, our windows-based content management system which allowed one person to contribute to a website which they published manually by FTP. If you started using that in 2000, it still works today. We fixed a bug that showed up in Windows 7, maybe Vista was the last bug we actually had to fix.
You can still use that today and call up FogCreek and get support on that, usually redirected to me.
Almost nobody is. We try not to leave people behind on these things.
Andrew: I see.
Joel: I have a very good feeling about Trello. In the first couple of days since it launched, it got 50,000. It got probably 200,000 eyeballs that translated into those 50,000 users, about 1/4 of the people who try it out become users. I think I’m doing pretty well compared to say, the Indian Job Board or StackOverflow. I’m pretty good at telling when I launch these things, are people going to be excited about this or not.
Andrew: I have to tell you, I use StackExchange at Mixergy. You guys cancelled and that meant I was going to be left out without a site.
Joel: Yes.
Andrew: Man, I was better taken care of by you, after you changed directions on StackOverflow and said, ‘Andrew, you can’t use it’. I was better taken care of by you guys in that situation than I was by companies where I’m paying month-to-month, where I’m a long-term customer and where I plan to continue to be as long as their products continue.
Joel: Yes.
Andrew: It was really unbelievable care. Emails getting answered quickly, direction expressed very honestly, and when I needed something that was above and beyond what you were supposed to give me, you said, ‘sure, we’ll take of it’.
Joel: Yes.
Andrew: That’s what we’re learning today. Find a way to keep people supported even after you cancel, accept that it’s part of the process, and if it happens to Joel, it’s going to happen to me too and smile along the way.
Joel: Yes.
Andrew: All right, here’s another thing. I looked at blog posts where you announced what you said, where you talked about how to release. Here’s a line from the blog post: He said, “Also important, the new cycle is 12 hours, tops. If you call a journalist the day after you release the product, it’s not news. They won’t care.”
Joel: Yes.
Andrew: We are now Monday. You talked to me the day of the release.
Joel: Yes.
Andrew: You pushed me off until Monday.
Joel: I’m sorry.
Andrew: Why?
Joel: You’re not news. Well, you kind of are news, but I know that this video will go on Mixergy and it’s going to be useful to entrepreneurs for years to come. You’re building up this awesome library of terrific stuff that people can look at and I’m happy to look Mixergy interviews from eight years ago. I don’t know. You don’t go back that far but I’m happy to look at anything on the shelf. It’s just as interesting to me.
That’s really what you’re about, at Mixergy. You’re not breaking news. Again, if I were to go right now to say, the New York Times and they said this is a great story but this is from last Wednesday. I can’t run under the guise of news. They just wouldn’t run it no matter how much they liked it.
Andrew: Yes. That’s true. You know what, that’s exactly the way I want to be seen and when you were talking about the [Indian Job board], even though it’s been a long time since then, I said, ‘How do I get Joel to get back on here and tell me about the [Indian Job board]?” That could be a whole new interview. I want to know what worked, what didn’t work there, how they did it.
Joel: Yes. We had no entrance into that marketplace. We didn’t understand it. We had no reason to be in that marketplace. We had just imagined that it existed. What actually existed in the Indian Job market was something very different than our product.
Andrew: OK. I want to continue to learn from what you’ve done and your experiences. Let’s talk about ideation. How did you use to launch products and how did you now, with Trello, launch this product?
Joel: One of the biggest difference is that we took some of the, I don’t want to say lean start-up. The lean start-ups actually came from the Principles of Customer Development. Eric Ries’ teacher at Stanford, Steve Blank, has this awesome book. What’s it called, Four Steps to the …
Andrew: To the Epiphany. Yes.
Joel: Yes, very weird title. Actually, it’s just his typed up class notes. It’s kind of a brilliant idea of how to create something that is approximately like a product and immediately start talking to customers. It’s all about pivoting endlessly in the early stages to try and reach a fit between what your product offers and what your customers need.
The idea that you would iterate so many times is something relatively new to me. I was always about ‘Hey, let’s launch something simple and see where it goes.’ I have always tried to do that. This idea that you don’t even have to have a product in mind, you can start with something that is almost a stand-in for a product, here, is a pet rock. What do you think about that?
Just to get those conversations going, try to figure out what people need. There is this actual process that Steve Blank describes in his book and Eric Ries has developed into the Lean Startup movement. There is a process whereby you can start with absolutely nothing and find a product need somewhere.
Andrew: What was the ‘nothing’ that you started out with?
Joel: Our main product at cash cow at FogCreek is a product called FogBugz. It’s project management specifically for software team. It’s all about keeping track of the millions of little tiny details that you need to keep track of. It’s great for that. One of the things that is terrific at is, if you need to release a product.
Let’s say it’s going to be going into hardware and it’s going to be manufactured or there is some reason you can’t iterate rapidly on that product or you’re Google and the 1.0 has to be perfect. Or it’s a game and it’s going to get stamped onto CD ROMs and they better be awesome.
All those reasons why you have to get to zero bugs on day one and the product has to be perfect, that’s what FogBugz is super great at. It has worldwide, 100,000 users keeping track of all the details of their software development projects.
One of the things that used to drive me crazy is I couldn’t get Jeff Atwood to use it. He’s the co-founder of …
Andrew: Stack Exchange.
Joel: Yes. Jeff and I disagree about many things but there was something to it. Stack was so successful in the absence of the formal bug tracking a lot of software development teams considered to be a best practice. Intellectually, I couldn’t leave this alone.
There was a certain aspect he didn’t want to use FogBugz because of what the call ‘Second Wife Syndrome’. In other words, it was a thing that came from my first company, not the company that I had with him. Anyway, forget the psychology behind it. It occurred to me there had to be something else going on here.
One of the things that I noticed about the way Jeff Atwood works is, if you try to talk to him about a feature that is three weeks in the future, he will not discuss it. he will not talk about long-term plans, six month plans, one year plans not interested. really when you realize you’re talking to Jeff about the future of Stack Overflow, you’re talking about the code that is going to be written over the next seven days for all intents and purposes. and that’s an extremely lean flash agile philosophy, it takes it almost to an extreme. and it occurred to me is that what he is doing is keeping track of exactly what everybody is working on right now and forgetting about everything that is stuff that you need to keep track of for work the future, and there had to be a kind of project management tool where I could, as a manger, keep an eye on that.
And I looked back on FogCreek and said, you know what the problem is? I got 13 people, programmers on this team here and I don’t know what they’re doing. I don’t know if they’re doing the right thing. Every time I asked them what they’re doing, they tell me something that makes no sense whatsoever, I don’t understand it, let alone understand that it’s the right thing to be doing. Like why are you working on that we have problems X, Y, and Z that are much, much more important. So it occurred to me, the first idea that I had, which lasted about 15 minutes was a little bit too risky, but if somebody wants to do this I think it’s a great idea.
The idea was called, Five Things and Five Things says that every person on your team can have a list of five things. Two things that they’re working on right now. You have to have two because if you get bored with the one you’re working on in the morning, you can work on a different one in the afternoon, switch between the two. Three things that are in queue, that they’re going to do when they finish the first two, but that’s it. You cannot keep anymore things on a developer’s queue than five things. I’m talking about big things like, finish all the bugs for version 2.0. Bugs are not a thing, all bugs together become one thing. If you’re not focused on, I’m going to build that feature, I’m going to deploy, whatever those things you’re doing, if you’re not focused on a couple of big chunky things, you start to despair. Like, I’ve got a million things on my queue. I can never catch up with them so, I might as well go home at 4:00 and life is just not good.
I feel there is really a fundamental part of getting things done for teams that involves trimming down what everyone’s working on to a very, very limited number of things. Ignoring everything else and just keeping that big picture. If you see, actually on the board behind me, can you see that? Who are the people? What are they doing? What are they working on? What are their big things that matter right now? Management then becomes very easy. Once a week you get together with your team, you go over that list from left to right, and you say, ‘Do we still care about this? Is this still in the right priority? Are they still in the right order? Check, check, check, check, and you scrub that list, maybe once a week. Then during the week you refer to it, you keep track of it, of what you think you should be doing.
Andrew: By the way, if someone for example were responsible for customer service that card, as you guys call it on Trello, would be on his, in his list week, after week, after week you just want to know what are his . . .
Joel: I’m the customer service guy, right? You don’t necessarily want, you could use Trello for every single customer service outstanding thing that you can keep track of and that’s one way of using it. It’s pretty good at that too, just keeping those long to-do lists so, that you make sure you check everything off, but actually if you look on the back of those cards, we have checklists on the back of the card. If you’re thing is to handle customer service, you have a customer service card, and it’s your number one priority thing, and on back of it you have a list of all the open customer service projects that you can do . . .
Andrew: . . . issues like check responses, set up a new phone number, or whatever it that you got to respond, you got to do.
Joel: Yeah. Then you can check those things off. It’s sort of long story short, Trello evolved out of the fact, 11 years I’ve been managing development teams, software development teams, and also customer service teams and sales teams and everybody. I’ve just been managing these companies and I’ve always felt that I just don’t have a grasp on who’s working on what and what the priorities are. I worry that they too must also not have a grasp on what they should be working on, if I don’t have a grasp on what they should be working on. Every time I look to FogBugz to solve this problem I realize it was just too fine grained. There was a fine grain details and then you can roll it up and get these big summaries like, Alex is working on 47 hours worth of stuff. That doesn’t mean anything to me, but just to be told, hey, Alex’s number one project is . . . and Seth’s number one project is . . . and
Andrew: The idea originally started with no more than five things per person. I’m going to create a list of five things they all work on and when they’re done they can check it off and move on to something else and I can always keep track of what it is. How do you go then from, actually what do you do with that? Do you then take that to your partner and say, ‘Hey, Jeff does this make sense? Would you use this? Do you do conversations like that?
Joel: That was kind of interesting actually, because I’m never going to get Jeff to use anything. One of my important design principles, I’ve always designed group ware, what we used to call all in the mid-90’s groupware, i.e. software meant to be used by a team of people. Fog Bugz, Kiln, Stack Overflow, Stack Exchange and now Trello, it’s all software designed to be used by team people.
The trouble with software designed to be used by a team of people is that if they’re not all on the same page, some of them are just not going to use it. And to get people to change their habits enough to start using a new piece of software is next to impossible, no matter how perfect the software is. There’s always going to be people that just won’t use it or don’t look in there or that just can not change their habits.
And so, the best groupware is the kind of groupware where the first value arrives when one person starts using it, and they can almost use it as a proxy for the team for a while. And then, the more people that they use it, the more value you get, maybe but you still never need everybody.
And so, for example, early on in Trello development when I couldn’t get people around here to use, I said to one of my development leads, not Jeff, I said, “All right. I’m making a list of the stuff that I think you’re working on. And he’s like, “Well, can I see it?” And I was like, “No. This is my list. I’ll talk to you about this once a week at our weekly meetings.” And he’s like, “Please let me see that.” Now, he’s begging to get into Trello so that he can see the list of what I have of what I think he’s working on.
It’s useful enough for me. If nobody else wants to use it on my team, just to have the one-on-one for the team members and to keep my own list of what I think and hope and dream that everybody’s working on this week.
Andrew: OK.
Joel: And then, I can ask them at the end of the next week, “Well, last week you said you were working on this. Are you still working on it?” They’re like, “How did you remember that?”
Andrew: So, going from the concept of five and no more to the concept that was more flexible, that was just you thinking, I don’t think I can get people to limit themselves to five. I don’t think I could create a product with that kind of limitation.
Joel: I sort of felt like five, specifically, was too risky, kind of. That was a little bit like taking too big of a bet. One of the interesting things that sort of evolved is when you look at Trello, it’s really just a list of lists. You’ve got the columns, and each column has cards in it, and there’s stuff on the back of the cards, including file attachments and conversations. If I describe that to you, when I describe that to people, they all come up with their own use cases that are so far removed from anything I’d even be thinking of.
So, for example, within hours of launching this time at [??] I got three emails. I got one from my dad who I have never shown Trello to. He’s 80, and he’s working on renovating a new apartment that he just moved into. And so, he made columns for the plumber, the contractor and the woodworker and all that kind of stuff immediately, and he was like, this is perfect. I’m already using this.
I got a comment on the blog from Kathy Sierra. She writes these awesome books, and she said, “I’ve got a million Post-It notes in this one hallway that keep blowing away every time . . .
Andrew: Excuse me, Joel. I get it. I [??] with it, and I love it, and I can see all the uses. What I’m trying to get at is this. How do you go from a concept that just occurred to you to a product that gets that kind of openness and that kind of eagerness from its users? It seems to me like you didn’t go the formal customer development process where you go and have conversations with customers.
Joel: Oh yes, we did. We sort of did.
Andrew: Tell me about that.
Joel: So, what we did is we essentially agreed around this idea, and at this point it’s mostly a development team at FogCreek. I had no real involvement, but we agreed around this idea of list of lists, somewhat inspired by their combine boards and things like this. Everybody has Post-It notes in a million different versions of this. A list of lists is not all that intriguing.
We started with that, and we said, “Could this be used to keep a list of what everybody’s working on. They wrote about 700 lines of code, and we already found it to be a very useful project management tool internally. So, we started using it internally right away and started seeing the value right away.
And then, we started showing it to our friends and showing it to a few outside beta testers and I think we had, all told, about 100 beta testers. We got feedback from them. We paid attention to that, and so now we’re doing . . .
Andrew: How did you get feedback from them?
Joel: We just talked to them. These are our friends.
Andrew: So, it was just you give it to your friends, and you call them up and say, “What do you think of this, or did you shoot them an email and say, ‘Did that work’?”
Joel: These are all our friends, so we talked to them all the way, and they sent us email and they give us feedback anyway. We’re talking to them anyway. These are not like random customers out in the wild. These are people we actually know.
So, for example, one of the teams that started using it was a company that I was mentoring from TechStars, [??] and there’s about three of them. They started using it right away, and so I could go over there and see them using it. They gave me feedback all the time when they had ideas.
One of the interesting things is a whole bunch of stuff developed that we never expected. So, for example, we tried to use a Trello board to keep track of good product names for Trello. We were calling it Trellis internally, and that was just a random name somebody figured out. We did a lot of brainstorming using Trello boards of what some good names might be.
We wanted people to be able to vote on the ones that they liked. And so, at first we told people, well, just attach your picture to the ones that you like. But, that was sort of unwieldy, and so we built a vote feature and we loved it and we left that in. The other thing that happened, something completely unexpected, is that each card becomes a conversation on the back of the card and that was a thing that we discovered we could somehow use. People started having conversations by modifying the comments. We said, we got to support this use case, this is important to support this use case.
One of the last features we completed before we shipped, was a good notification system. If somebody’s sending you a message on a card that you haven’t looked at for a long time, you find out about it. Otherwise you have to check every card to see if anyone’s talking to you. Once we got that working it became a communication tool as well as, a keep track of things tool. So, all that stuff evolved through actual customers, real customers using it in the field, including ourselves, and having ideas, and then focusing in on steer it into well, if we do this, that will meet that use case better.
Andrew: I’m going to come back to the word you used there to describe your users, customers, and find out about the payment model, but one of the things that I’ve noticed when I share a new idea with friends, is that they have lots of feedback. Because they’re my friends I feel like I have to either use it or explain to them why I’m not using it. It’s hard to figure out which ideas to use. When you get all this feedback from people who you care about, who are doing you a favor, how do you know what to use and keep and what to say no to?
Joel: That’s interesting. It depends on who they are, as a general rule, I would say don’t listen to individual feedback items. Wait until you see trends and look for the trends. Then use your own brain to try to solve that trend.
Andrew: Trends. Not items that are, or suggestions that are repeated, but a trend. What’s a trend?
Joel: Well, I’ll give you an example. In Trello for example, the one thing we discovered the day we launched, people started asking on Twitter — I see a lot of people asking for random features that we already had, and I realized that a lot of these things were board properties, a board has properties. It occurred to me that not a lot of people were not finding the fact that you could set board properties because the icon didn’t look like a thing you would want to click on. It just looked like a travel icon. I suggested to Bobby, ‘Hey, let’s make that a gear or something so people know that that’s a settings thing that you can click on, because I just keep getting requests for the same category of things on Twitter.’
Andrew: I see. So that’s a trend. If you were to listen to individual items that were repeated over and over, you might take individual items from the settings section and make them more visible on the top of the card, but because you’re recognizing that they’re not picking up on this big trend or on this big message, that all these settings are behind this button, you just change the button.
Joel: Think about occasionally people will go to the doctor and say, ‘I need Xanax or something.’ The doctor, rightly gets frustrated saying, ‘Please don’t diagnose yourself. Please tell me just the symptoms that you’re having and I will figure out what the disease is. Then I will find the best treatment for you, for that disease. Don’t just come to me with the prescription you want me to write. I’m the doctor here’. And it’s a very, very similar situation you are the designer. You are the product design. You own the product. We do this on all our products and the users will tell you what they’re frustrated about, but sometimes they’ll tell you what they’re frustrated about by suggesting a feature.
The trouble is a lot of times users will suggest a feature that they don’t want, they don’t need, and wouldn’t use. They’re only suggesting it because they’re just being friendly. They want to have a nice email with you. They’re like Trello is — often, ‘Hey have you ever thought of using Trello for cake recipes?’ It’s like, ‘Yeah, it sounds great. Would you use this?’ ‘No, no, no, but it sounds like a great thing for cake recipes,’ and I’m like, ‘All right. Thank you,’ and then you can’t use that information, you just can’t. You have to ignore it for a long time until enough of it starts to build up in certain areas, that you come up with your own theories.
You start to say, ‘Hey, you know there are a lot of people talking about recipes. What the heck is going on here with recipes?’ Then you delve into that and come up with your own ideas for how to do it. Your users are very rarely product designers and their suggestions for how to design your product are very rarely exactly perfect and appropriate. Sometimes they are, sometimes it’s just, wow, yes that’s what we should do. Usually it’s better just to see where the limitations, how can I as a designer, make my own decisions.
Andrew: OK. Now I see how the idea developed and I see how you got feed back from users. Someone at Hacker News, when you released this said, ‘Hey Joel, you told us to create this kind of spec sheet before we launch a product. It seems like you’re doing something different. With all do respect he said, what’s going on here?’ You explained it a little bit, but you said it’s too long to really fit in the comment on Hacker. We have a little bit more time, explain to people who don’t know you’re writing as well, what was it before? What were you telling? What the history behind that?
Joel: What’s the history behind that is for years and years people felt that you should write technical specifications before you build things. They would write long functional specification documents and technical specification documents the difference is functional describes how it works. Technical describes how it is implemented. They would write these long specification documents before they started writing any code, and for a long time I said this is a good thing to do, this is valuable.
When you’re writing a document in English, or by drawing things and sketching things and explaining how they’ll work with lines and arrows, that spec itself is much easier to change than lines of change than lines of code, no matter how good your programming environment. Lines of code are very tedious to change, and a lot of work goes into getting simple functionality on the screen that you could describe in two sentences in English. During the design phase and when you’re figuring things out, you want to be able to iterate very rapidly, and you should do that with a white board, with boxes, with diagrams, and finally with a written document that tries to go into as much detail as you can think of about the code that you are about to write. That was the old way of things.
A new movement emerged, which is now almost completely gone, I haven’t heard this term in years, called extreme programming. Extreme programming said no, never write any specs, ever, just start coding because you can always change the code. I was in disagreement with this model, and said well you know, that’s sort of silly because if you write code you start to become attached to it because you spend a lot of time working on it, and you just can’t iterate, you just can’t change your design as quickly when it’s written in C# or Java, than you can if it were written in English text. So start with something that you can mold, and figure out the idea very, very quickly.
Then people said ‘Well was there a big spec for Trello?’ and I think that the truth is that there’s kind of an interesting middle ground here, which is that I’m still a believer in doing things in this lean way. I’ll define lean, it’s going to be the wrong definition later. Do things in a way where you’re working in small chunks of features; you say ‘Alright, I’m going to do this much, give it to the customer, see what they say, and then do another tiny little thing, then give it to the customer that week.’ My definition of lean, here, is continuous deployment, continuous delivery of value from the developer to the customers.
Every week there’s a new thing, and it arrives continuously. It’s not like Microsoft Windows where every five years there’s a new version, it’s more like Gmail where you’ve never noticed a new version because the little tiny things have accreted over time, that have gotten better and better and better. However, for each of those things, each of those development tasks, I’m still a very strong believer that you have to figure it out in advance; you have to figure out how it’s going to work before you start writing code. That’s what I call the spec. It can be a long written spec in English, which I like, where you literally, and maybe this is because I’m a good writer, where you write out this is what it does, and you see this, and you try this, and that thing happens. Then you work on that, you iterate that, you show it to people and you have conversations, and you get that really good before you start committing to the code.
It could also be a lot more visual if you’re more of a visual person; it could be Balsamiq Mockups of what the screen should look like, but it has to have those little lines and arrows and descriptions; so when you click on this, the following happens. For example, if you know that people are going to forget their password, there’s got to be a button that says “I forgot my password”. Then you put that on the mockup and now you realize all of a sudden you realize ‘Oh, wow, I have to implement my password system in a way that I can email them a reset link,’ and you have to decide about how that should best work before you start writing the code, otherwise you might realize ‘Wait a minute, my password system never captured an email, so now I can’t email them a password link, oops, I forgot.’ There’s a bunch of stuff like that.
The lean part that I like is the continuous, almost like an assembly line, from the designer to the coder to the tester to the deployment guy to the customer. There’s stuff always in this conveyor belt coming from the designer’s head and arriving in the customer’s lap so they can use it on a continuous basis. It’s just very different from the Microsoft Office 2011 or Windows 8 ‘big humongous thing’ model. Even with a continuous deployment model, though, you have to design things. You have to think about them using a language that’s easy to edit, easy to modify, like English or drawings, before you commit to code.
Andrew: Alright. Talking about customers. When David Hanemeier Hansson was on here he told me that you have to charge, because that’s how you get the best feedback. If someone says “You should create a recipe card,’ and you say ‘Alright, how much would you be willing to pay for it,’ and they say nothing, it tells you that it’s not a good idea. If they tell you that they are willing to pay then you should reconsider. You intentionally decided to push of charging until later; why?
Joel: Yeah, we’re not going to charge for the core Trello product. Basically, what David is referring to is a class of business models which are based on simply, ‘I create value and I deliver it to one person directly.’ That particular class is really, really interesting, and it’s a great way to get started and I’m a big fan of it. I’m all in favor of that, however there is another class of business models which is a little bit more complicated. Advertising is a classic example where you say, I’m going to build up a product that is of value to two sides and one side pays and the other side doesn’t. Or one side pays for access to the [??] essentially, or one side pays for attention, that’s like advertising.
If you look at the traditional magazine model, they would make ten times as much off of the advertising then they would off of the subscriptions. [??] is not necessarily an advertising business, Stack Overflow is also for more advertising oriented, but what the Internet lets you do is get massive, massive scale, by making things free, cheap, and highly available, which let’s you build eight different business model that you charge for on top of that.
I don’t think anybody is making things for free because they believe in voodoo economics or some kind of magic will happen. They’re making things free because they need a large audience because an audience is an asset that you can almost always monetize.
Andrew: How would you monetize it then?
Joel: The idea for Trello, we haven’t really announced exactly what we’re going to do, but let’s start with the big picture. The big picture is make something that 100 million people can use of whom 1% of them are deriving enough value that they would pay $100 a year. So, it’s free for 99% and 1% of them are somehow deriving this extra value. That was the guidance that I gave to the team, think in those terms. We got to make something that 100,000 people can use that means, it can’t be a software development tool like Pivotal Tracker, which is awesome, very similar to Trello, but a software development tool. Because they are not 100,000 software developers. So, you got to think bigger than that, immediately.
You can’t charge for it because there is no product that I know of that a 100 million people are paying for. You can’t charge for that core product. Those things sort of fall into that and then you think, if I had an audience of 100 million people, it is inevitable that the top 1% of those users would be getting some serious value out of that thing. You could possibly find a way to sell them a premium services and that’s sort of the traditional premium model.
It’s starting to work a lot better as the Internet reaches scale. It didn’t work so good in the ’90s. If you look at companies like Drop Box and Ever Note, they’re making money hand over fist with this model of somehow charging the top 1% of the users who need the most storage, in their cases.
Andrew: Why not create a product that just hits that 1%. Forget about the other 99% and focus, and use the extra money that you’d earn from the 1% to advertise. Instead of hoping that you create a product that a few people end up buying?
Joel: I can’t think of a better advertisement than letting people use the product. Essentially the cost is so low these days, that is the cheapest possible way to do that that form of advertising, is by having a free product. The cost is a rack of service somewhere, it’s a few thousand dollars a month, it’s almost negligible. When it’s $100 million it may make it slightly more substantial, but I think that you sort of have a choice of I’m going to go very, very slowly and I’m going to pry one customer at a time out of the dry earth, but I’m going to individually find those people who are going to derive great value out of this thing.
That’s a very, very tedious and slow process and you’re not going to find all the people that might derive value out of that. There are a ton of people that can use say Base Camp and might be able to derive value out of it, who never bothered trying it because it looked like a pay thing. I can’t imagine my dad looking at the Base Camp website and ever consider using it for his construction project on his new apartment. On the other hand, if you can somehow massively reach huge number of people, some of them just don’t give a crap, some of them care a little bit, like they’re using it for organizing their book or their renovation,, and some of whom are actually deriving power from it then you immediately cover a global number of people. Imagining how you can get 1% of them to pay you something is much, much easier than trying to imagine, how can I claw another paying customer out of the vast world.
Andrew: It seems like your thinking has changed a lot because of stack exchange or around stack exchange. It seems like before stack exchange, you wanted a very focused product on a specific kind of customer. Now you’re going horizontal you said, you want to be like Excel spreadsheet or Microsoft word where anyone can use it. Before you were building products that customers would actually pay for. Now you’re building products that you’re giving away for free. Before you were going smaller. Now it’s massive. Tell me about that.
Joel: Well, I always I had this philosophy of bootstrapping and for bootstrapping, that’s where you want to get paid from your very first customer. I can’t, I don’t know how you would bootstrap a product like Trello. You would need capital, because you’d have to buy some servers, and you’d have to pay. We do have 3-4 developer years. If you had to do this from scratch it might cost you half a million dollars to develop Trello.
You could accept VC money for that. We didn’t. We paid cash from FogBugz earnings. As a bootstrap thing, getting paid by your first customer is amazing. Having done that, and now having cash flow, and having the ability not to have to do this gives us the freedom to go after slightly more interesting business models that not everybody can go after.
It’s slightly trickier. We’re talking about two kinds of users: the paying users and the not paying users. In the case of stack overflow for example, we’ve got the stack overflow programmers writing questions and answers. We also have the advertisers advertising on the site, and those are two different audiences.
Andrew: So is bootstrapping something that you do when you have no other choice? The non-bootstrapping funding method, whether it’s internally with enough cash of your own, or externally with venture capital, that’s a better model because it allows you to grow bigger and it allows you to have the best form of advertising which is a free product that many people use?
Joel: There’s about a million trade-offs. One of the very first blog posts I ever wrote was called ‘Amazon vs Ben & Jerry’s,’ and it was about that dilemma which is sort of to just decide what you want to be. I really like bootstrapping. It allowed me to learn about business slowly and gradually.
At any given time in the development of Fog Creek over a decade, there was one thing going wrong, and I was able to deal with just that one thing. In larger companies, there are 16 things going wrong at once. Sometimes you’re sitting there, you’ve raised a lot of money, you have a bunch of employees, and nobody wants to use your product because it’s not that good.
That happens, and now all of a sudden you have this monumental problem. That doesn’t happen in bootstrapping companies. You would have given up. You wouldn’t have made any money, and you would have given up. Or you would have completely changed the product. They’re just different models.
You have to decide how important is it that this particular company succeeds? In which case, bootstrapping is a good way. How much capital you have, social capital, venture capital? Do you have the resources? We launched Trello and we got a lot of attention because people know my name. People have read [??] software over the years, and people have heard of stack overflow, and heard of FogBugz.
When we launched Trello, we had some credibility and we got some eyeballs. If you don’t have those eyeballs, it may not work as well. Maybe you should try bootstrapping and charge your customers first. I think they’re both utterly and completely valid models for different purposes.
Andrew. All right. I have at least two other agenda items I want to cover. The first is bugs. You’re saying that you’re dealing with bugs in a different way. What was the old way, and what’s the new way?
Joel: All right. Wow. There are a lot of differences here and there’s a lot of changes that have evolved over the years. Number one, I think the healthy way to use a Trello board if you’re a software developer is that bug fixing is just one card. You don’t make a card for every single bug. You can, but the whole concept of bug fixing is just one card because Trello is meant to be an overview of what are people working on, not that super detailed to-do list.
The other thing that’s really important to remember about bugs, is there’s a very high likelihood that if you use traditional bug tracking, you’ll get yourself in a state where you’ll have more bugs than you’re actually going to fix. It doesn’t happen if you have a smaller number of customers.
Let’s say that you’re developing a product for a client, you’re a consultant and you’re developing for a client, when they report things to you, you put them in the bug database and you make sure they all get checked off. One thing that we noticed happening is when you have a large number of customers, let’s say you have a product with 100,000 users out in the world, [burps] excuse me, every time they report something to you…
Andrew: Did you just burp on the show?
Joel: Yes, yes. Roll back, roll back.
Andrew: We don’t edit anything. We let it all out there.
Joel: Well, I don’t even remember what we were talking about.
Andrew: No, no, go ahead. Sorry, go ahead.
Joel: If you have 100,000 customers and they report bugs to you and you say this is very important I’m going to log this, and you log every single bug, you’re not going to fix them all. You’re just not. All that logging was wasted times and all those bugs and assigning them and deciding how important they are, wasted time. Prioritizing them? Waste of time, because you’re not going to fix them.
The only bugs you’re going to fix when you have 100,000 customers are the ones that keep recurring statistically that are really important. I’ve seen on a lot of teams that use FogBugz a really strong tendency because there’s just too much stuff in FogBugz, too much detail, a really strong tendency for the managers to go around and say to the developers, ‘All right. I know you’ve got all this stuff to work on in FogBugz, but this one is really important. I’m not even going to put it in FogBugz, just do it now.’
Andrew: Gotcha.
Joel: So there comes a tendency to say we’re declaring bug bankruptcy. We’re going to delete all these bugs, and hope that the important ones come back. That’s sort of depressing, because a lot of work went into editing those bugs and creating them, but you never had time to fix them. Now the way Trello tries to address this is by making sure that you can see that your queue is getting too big, and discourage you from putting things on that queue, because it just doesn’t fit in that height of the screen. You could scroll, but it starts to get irritating, and at some point you say, you know, don’t tell me about another bug. I’ve already got enough work for the next four weeks. If that bug is more important than anything you see here that I’m doing in the next four weeks, fine, tell me what to displace, but you got to push something off, because just adding it to the bottom of the list, it’s lower priority than four weeks of work. It’s not going to get done. So that was one philosophical change that applies to some categories of product companies, not all.
So I would not do this if you were Windows. I would not do this if you’re firmware. I would not do this if you’re a game. I would not do this if your 1.0; you’re going to have a lot of eyeballs on it. Has to be really good. I wouldn’t even do this if you’re a customer service organization and you’re trying to track stuff. I wouldn’t do this if you really are trying to get to zero bugs when you ship and that there’s a testing team and that’s important. But, if you’re a small, informal kind of start up and you’re just going to knock some stuff out there for the customers to see right away, the Trailways is going to be more fluent, is going to be more intuitive than the detailed bug tracking way.
Andrew: You can really keep from being overwhelmed.
Joel: Yeah.
Andrew: I feel like a lot of times in business and in life, we don’t get stuff done because we feel overwhelmed. So instead of doing a small portion of this big thing that’s overwhelming us, we do nothing because –
Joel: You go home.
Andrew: We feel overwhelmed, and we’re stuck.
Joel: Yep. That’s one of the important principals of GTD, actually, is psyching yourself into thinking, this is awesome. I got one thing to do today, just one thing.
Andrew: Right. Our mutual friend, Jason Calacanis, and you were both going to the questions and answers phase. And I remember actually you were on in Startups and you said that you have an Apple question and answer site and you have an iPhone question and answers site. He seems to have shifted away from it, to pivot it, and you’re focusing on growing in the Q&A space.
Joel: Yeah.
Andrew: What’s he doing differently?
Joel: Well, I can’t speak for him. Recently this week on Startups I heard him say that he gave up on Q&A because he thought that at scale it just became Yahoo! Answers. In other words, once you get to 50 million users, the quality of necessity decreases. I don’t really believe that. I believe that the stacks exchange model that we’ve come up with maintains quality even at scale.
Andrew: So philosophically, what are you doing differently to get different results?
Joel: A lot of it is a lot of focus on moderation and community moderation to maintain a high standard, and that those community moderators are the subject area experts, and so in stack exchange that manifests itself in things like voting, flagging, tagging, community editing. There are a lot of mechanisms that we have to basically bring up quality and to keep the place clean and to throw away things that are low quality. I think that those things will allow us to scale as a Q&A product, so I think that Jason was a little bit wrong saying that this doesn’t scale. That may have been his experience at Mahalo, but it’s not our experience at Stack Exchange.
Andrew: I see. In his model, he was also looking for discussion. You were looking for clear answers, questions that can have a solid answer.
Joel: And that’s a very good point. We focus like a laser on things that actually have an answer. You can’t just ask something highly subjective or something that creates a conversation, because that’s when you hit the YouTube phenomenon or Yahoo! Answers phenomenon of very low-quality, user-generated content.
Andrew: You know what, I remember on the Apple question and answers site – I use your sites all the time – and I went on there and I said, “Is it time for me to install a virus scanner?”, because I wasn’t sure. And to me, it didn’t seem like an objective question, but they said hey, it is subjective, there isn’t a clear yes or no answer. Sorry, we’re canceling it. I was bothered by it for myself, but I also respected the environment I was in, because I felt like, this is why I get good answers.
Joel: Right, right. Essentially, we see ourselves a lot more like… In the early days, I would describe Stack Overflow as the long scale of Wikipedia. Stuff that Wikipedia considered not important enough to have a Wikipedia article, but it’s still very, very fact based and very, very yes no oriented. There is an answer, and I have to be able to tell you, yes, this is the best answer or this is the not best answer. The trouble is, your question in that case was a little bit broad. We needed to have a conversation here. How do you use your computer? Are you this kind of user or that kind of user? Have you been bit by viruses in the past? It just becomes very conversational and it’s like half of the arguments would be on this side, and it would convince you that you do. Half of the arguments would be on the other side and convince you that you don’t. Essentially, not a lot of knowledge is transmitted. Maybe some knowledge is accidentally transmitted. What we try to do is get down to very, very specific questions like, in this particular case, you could probably ask, how would you evaluate anti-virus software, or what are the criteria for anti-virus software to consider, what are the top ten most important criteria I should look at in anti-virus software to consider whether or not to install it. Something where the answer is factual and not just monotheism or not monotheism.
Andrew: Is there or is there not a god? Your model now is to launch multiple products, small groups of people doing it, kind of like Tech Stars we talked about before the interview started, true?
Joel: It’s all in-house.
Andrew: All in house. Eventually spin them off into their businesses?
Joel: Not necessarily. The reason we might spin something off is if we thought that it would benefit from a different ownership. What that means is specifically if we thought we should take venture capital for one of these ideas then we might want to spin it off so that we could take venture capital just for that idea. But realistically I don’t see any reason these things shouldn’t stay inside [??] for the most part. And have all kinds of little ideas that we do; some of them become awesome products and some of them don’t.
Andrew: Beautiful set up, by the way. I like that you’ve got the brand there behind you, the product is demonstrated right there, it’s a great set up.
Joel: Full credit to producer Alex over here who came in and said, ”Wait. You’ve got a video interview in half an hour?’ and he set up a studio. I got LED lighting, I’ve got high res cam, I’ve got the lavaliere mike, I’ve got the earphone. This is all a prop.
Andrew: I hope the connection is recording us clearly enough but the audio is spectacular and I know most people listen to it and the video looks like you put a lot of work into it and I appreciate that. Thanks for doing the interview. And thanks for what you said about Mixergy in the beginning: that you understood what the mission was here and I appreciate you being a part of it.
Joel: Well, thank you for doing it. I think it’s an absolutely amazing resource. Every time a new one appears on Hacker News or something like that I immediately go. Sometimes you’ve got the transcripts up there and I read that because I haven’t got the patience to watch through the video.
Andrew: I learned the transcripts from you. I think you were letting your audience write your transcripts, is that right? I tried to do that and the audience came up with junk.
Joel: We would get about a quarter of it. People would transcribe the important parts but not everything. And our podcast was not that important so it was a little bit harder.
Andrew: I really enjoy the podcast. Is it back?
Joel: It is back. The [??] podcast. We’re back to doing a [??] that’s a little bit broader but it’s really the same general idea. It’s me and Jeff talking about the same things again and again.
Andrew: I’ll tell everyone to go check that out and, of course, check out Trello. Let me put in my own plug for my own stuff. In addition to interviews like the one you are watching if you want to take this to the next level and get a course, maybe you say, ‘I like this idea of talking to customers. I don’t know exactly how to do it,’ we’ve got Cindy Alvarez from Kissmetrics. She doesn’t just tell you how to talk to your customers to get feedback from them but she gives you the exact scripts she uses, she shows you where she finds potential customers to ask these questions and how to make all the information that they give you useful.
That’s just one of dozens of courses that we have to help you out. They’re all available on Mixergy.com/premium. If you’re a premium member you have access to them, if you’re not I hope you go to the next level with us and become a premium member to get courses like that. Mixergy.com/premium. Thank you all for signing up, thank you all for watching me and one of my heroes, Joel Spolsky. Thanks for doing the interview.
