Fog Creek

Success and Failure at Fog Creek – Podcast

podcast_fogcreek15_MainBanner



In this podcast, coinciding with Fog Creek’s 15th Anniversary, we take a look back over the years at the various successes and failures we’ve had at Fog Creek.

We discuss the early days of Fog Creek and how we recovered from a doomed first product. As well as dealing with technical debt, the missed opportunities we’ve had along the way, and what we’ve learned from them. We also get into how we develop new products and the impact of bootstrapping, before finishing with tips for those starting companies themselves.

Contributors

Joel Spolsky – Co-Founder of Fog Creek, CEO of Stack Overflow and Founder of Trello
 

Michael Pryor – Co-Founder and President of Fog Creek, Board Member at Stack Overflow and Trello Founder and CEO
 

David Fullerton – Former Fog Creek Developer, now VP Engineering at Stack Overflow
 

Justin Gallagher – Former Fog Creek Program Manager, now VP Product at Trello
 

Jack Bowman – Veteran FogBugz Developer at Fog Creek
 
 

Allie Schwartz – Host of the Podcast and VP People at Fog Creek

Content and Timings

  • Introduction (0:00)
  • Early Successes and Failures at Fog Creek (2:00)
  • Developing Products for the Long-term (15:00)
  • Missed Opportunities (25:02)
  • The Impact of Venture Funding (36:12)
  • Hiring Smart People Who Get Stuff Done (41:27)

Transcript

Introduction

Allie:
Welcome. My name is Allie and I am the VP of People at Fog Creek Software. This is a conversation about Fog Creek’s first 15 years, some of our big successes, how they happened, and some of our failures and what we learned about them. With us today are a bunch of people who worked at Fog Creek or still work at Fog Creek, and who were involved in the spinning off of the two products that came from Fog Creek and are now currently huge, successful companies of their own. I am going to introduce them and then they’re going to say a little hello, so that you can hear their voices. First, on my left, is Joel Spolsky. He is one of the founders of Fog Creek, Trello and Stack Overflow. Say hi, Joel.

Joel:
Hi, Allie.

Allie:
Hi. Next, we have David Fullerton, who is the VP of Engineering at Stack Overflow and he started his career at Fog Creek.

David:
That’s true, as an intern.

Allie:
As an intern.

David:
Hello.

Allie:
Hello. Then we have Justin Gallagher, who came to Fog Creek in 2010 as a designer.

Justin:
PM at the time.

Allie:
A PM.

Justin:
Yeah. On Stack Exchange Enterprise.

Allie:
Which I didn’t even know.

David:
That’s right. He worked on Stack Overflow too.

Allie:
Wow. Stack Overflow and FogBugz, and is currently the VP of Product at Trello. Hi, Justin.

Justin:
Hello.

Allie:
Hello. Now we have Jack Bowman, who also came to Fog Creek in 2010. First job straight out of college and he is one of our developers on FogBugz.

Jack:
Hi, Allie.

Allie:
Hi, Jack. He’s five years at Fog Creek, and he’s one of our old-timers, hilariously.

Joel:
Shocking.

Allie:
Last, but certainly not least, we have Michael Pryor, also one of the founders of Fog Creek, Trello and Stack Overflow.

Michael:
I’m just more like a bookkeeper. I was the bookkeeper at Stack Overflow.

Allie:
He was the bookkeeper at Stack Overflow and currently, the CEO of Trello. Hi, Michael.

Michael:
Hi, it’s great to be at this Quinceañera party. It’s awesome.

Allie:
Yeah. It’s great. Every day is a Quinceañera.

David:
We need music.

Early Successes and Failures at Fog Creek

Allie:
We’re going to start just talking really broadly. Joel, can you talk to me a little bit about … Fog Creek has had a lot of successes. Probably more than a lot of companies, although there have also been some …

Joel:
Sure. Companies have gone out of business with fewer successes than we’ve had.

Allie:
That’s true. We’ve had some failure too, but more successes than most companies. Do you have anything, just off the top of your head, that you think is one of the largest contributors to that?

Joel:
You mean why we have so many successes?

Allie:
Yeah.

Joel:
I guess it could be my brilliance.

Allie:
True.

David:
That’s what I was going to say, Joel.

Joel:
Yeah, go on. Sorry, okay. No, it’s really all about the people, Allie.

Allie:
Yeah, true.

Joel:
It’s about get the best people first and then good to great things will come from that.

David:
I think that’s the defining … Joel doesn’t want to toot his own horn, but I think the defining feature of a Joel and Michael company is putting people first, choosing people very carefully and then setting them up for success and letting them pursue the ideas. Everybody talks about people first and all that stuff, but I think the way that … The specific way that that’s actually done in Joel and Michael companies is a big piece of the success of all three companies.

Michael:
It’s also we’re looking at this from hindsight. We’re going to get to the failures, I bet, coming up, but it’s easy to point out the successes when we gloss over all the times that we failed. In fact, if you think about one of the first products that we even created for our company was a giant miss.

Allie:
Why don’t you talk about the first product you ever created?

Michael:
When we started Fog Creek, we were consulting and that was actually successful.

Joel:
Well, for 10 minutes.

Michael:
Right, it was successful for 10 minutes and then what happened was we were doing consulting and we thought we’re bringing in big bucks. We’re basically bringing in twice as much as we’re paying, and with the extra money, we’re going to invest it in building other products. That was 1999? 2000.

David:
Great time to start a company.

Michael:
Then, essentially, the market blew up and the first thing that people cut was their spending on outside consultants. There were actually a lot of companies, Scient, Viant…

Joel:
Razorfish.

Michael:
Razorfish. There were a lot of consulting companies out there.

Joel:
MarchFirst.

Michael:
It was easy for us to get jobs or get a business very early on, and so we hired two people, and then basically when the consulting dried up, we were like [gasp], okay, reset.

Allie:
Right.

Michael:
Then we thought, we were working on a product at the time. It was a content management system called CityDesk that we were building because it was much too hard to build websites at the time, because you had to install all these Perl scripts and you needed root access on the server. We were like, oh, you can just run it on your desktop. That’ll make it easier. It was, but also the people that were building those tools also realized that it was hard, and so they basically started hosting those things. So you got Blogger and Movable Type and TypePad and all that stuff. It was just a total miss to try to build a desktop app for content management.

David:
We made a reasonable bet, but it was the wrong bet.

Michael:
Right. We’ve done that a couple times, where we couldn’t get … We’ll probably cover some other things that we did that with.

Allie:
We certainly will.

Michael:
It was lucky at the time, because we had this other product that we were building, which was a bug tracking app, that Joel had built previously at a different company and then he used it at Viacom. What was it called then? JoelBugz?

Joel:
VisBugz?

Michael:
VisBugz. Then we used it a Juno, where Joel and I met.

Joel:
Where it was JunoBugz.

Michael:
It was JunoBugz, and then we used it at Fog Creek, so we called it FogBugz, and we’re like, we can make a couple bucks off this.

David:
You guys are really good at names, by the way. I’m just saying.

Joel:
They all had Zs.

Michael:
Joel’s a really good namer.

Joel:
I’m also good at setting prices for things, by the way, we discovered after 15 years.

Michael:
FogBugz is this slow and steady thing that was slowing gaining ground at the time and we had to cut back the company to just Joel and myself. We’re working out of his grandmother’s basement.

Joel:
It wasn’t a basement.

David:
I thought it was the brownstone.

Michael:
Bottom two floors. You’re right. Ground level. Garden apartment.

Joel:
It had a nice garden. Yeah, exactly. It was a garden.

Michael:
It was quaint, but it was just the two of us. Not that much money coming in, but every month we would make a little bit more than the previous month, and so that just started to build.

Allie:
With FogBugz, you talked about CityDesk a little bit and why it didn’t make a lot of sense, but FogBugz is the next thing that came out, it sounds like, from the Fog Creek mini-factory that was there. It still is our flagship product. It’s really been the thing that sustained us for a really long time. I’m wondering if, Joel or Michael, you have any thoughts, if you’ve ever thought about really what is it about FogBugz that’s allowed it to be this one big product that’s kept this company running.

Joel:
Wow, that’s a good question, I think I’m…

Allie:
I’m smart, Joel. You hire smart people.

Joel:
Part of it was that we had the right audience. The important part is not just having the right product, but also being able to market it in some way or get it to the right audience. There were probably 20 bug trackers that you could get in some shape or form when FogBugz first came out. Although, to be fair, probably in those days, those were like Windows apps that you installed and you had to probably get a special server.

David:
Yeah, web-based, there were only a few …

Joel:
There wasn’t a lot of web-based. There was Bugzilla. Yeah, but it was a matter of the blogging that I was doing at joelonsoftware.com, which gave us a big audience of people that might be willing to use it. Then I think the product sort of hit the right mark, because whenever it took an opinion on something, it took the opinion that, I think, made people more successful with their teams. Some of the things that were kind of hard-coded into the way that FogBugz works and is still hard-coded into it today, like the fact that when you resolve a bug, it doesn’t just disappear, it goes back to the person who opened it so that they can check if you really fixed it. That came from our knowledge since the beginning, that 90% of the time, the person who’s fixing the bug thinks they’ve fixed the bug. They’ve actually either fixed something else or for whatever reason, they haven’t actually 100% eradicated that bug and so it has to go back to the original person who checks it to make sure that what they think was broken is not broken anymore. That’s just built in to FogBugz, and in fact, some of our big competitors have that as a configurable option, as opposed to something that’s built in. FogBugz just kind of tricks you into doing the right thing.

Allie:
Yeah, so it sounds like FogBugz benefited from the fact that the people who built it were the people that would use it.

Joel:
Yeah, and also that we had … What I was doing on Joel On Software was writing blog posts for developers, saying, if you’re wondering, a good way to run a development team or how to manage your little software company or how to beat Microsoft at their own game … A lot of those were the kind of blog posts that I was writing in those days, so I got a big readership of people that were interested in improving their software development skills.

Allie:
Right. David, Stack Overflow, I think is really similar to Fog Creek in that you have this connection to your community, it sounds like, in the way that Joel on Software was a big connector for Fog Creek and the community of people that used FogBugz.

David:
I guess an interesting question for me, sorry … What was different about Stack Overflow from what we were doing on FogBugz? I think the biggest … Well, there were a few shifts. One was the shift to continually releasing software, actually, that FogBugz wasn’t doing at that time that I think led to a natural process of listening to people, taking their bug reports, tweaking things, showing it to them, seeing what they think, taking more feedback, tweaking it and seeing what they think. The other big thing was that really, really close connection with the community. I think it helped that it was developers building something for developers. That always helps, but listening, having that really close relationship to the people using the thing, to the community, was something that just didn’t really exist when we were building FogBugz.

We knew how we used it and we tended to assume, because it was opinionated software that that’s how everybody else used it, but I think, looking back, I never really, as a developer on the FogBugz team, had a really good idea of how different customers were using the software in different ways. Versus with Stack Overflow, with just having this open community involved in building the product, having a site where they can go and talk about it and suggest ideas and report bugs, and talk about what they’d like to see fixed. That gave and gives more insight into what’s wrong with it, what’s not working, what’s working well, what do they like about it, what do they not like.

Allie:
Right. Justin, I’m wondering, as Trello was growing, you know, Trello now has, what, like 10 million users? Is that right?

Michael:
Eight, we’re supposed to say publicly right now, until…

Allie:
Eight million users as of August.

Michael:
Until tomorrow.

Allie:
I’m wondering, same question to you. As you were building Trello, was that part of the thing in your mind, the community of users? Because it’s a very different thing, right? Trello is really, of the three, the one that appeals to the biggest community of not developers.

Justin:
Yeah. We definitely took the stance from the beginning that it wasn’t going to be a tool for just developers. We always had that as part of the plan. Doesn’t mean developers can’t use it, it’s just not only for developers, but it’s for anybody who’s collaborating on something with anybody else and it gives you this nice visual interface for it. That includes us. We are part of that audience. It’s not like we’re building a tool for grocery store managers and none of us manage a grocery store. We do have some example of how people want to use it and how they do use it. We do try to talk to people. We’ve always tried to … We get lots of support emails and things like that, but we try to interview people and talk to them about how they’re using it and build it up in a way that uses that, but still try to stay true to the original vision of the product, as well, those two things.

Michael:
I just want to bring up something. When you were talking about Stack Overflow and Trello, I was thinking about how Stack actually was almost a big miss, because when we first started out, in typical fashion, we were a software company. We built the software and then we sold it to people. The initial vision of … We built … Stack Overflow existed and we had this huge developer site, and we had built this community engine and our thought was, oh, great. We’ll license this Q&A engine to anyone that wants to build a site for whatever group of people they want. We were headed down that path…

Joel:
You mean making Stack Overflow into software that you could buy.

Michael:
Yeah. Basically selling the software behind Stack Overflow and it took us a little bit of time to realize but we did finally realize that the most valuable part of Stack Overflow was this community of developers. It was not the Q&A engine we built. That was cool but the reason the Q&A engine was important was not the code itself, but the thought behind it, the rules and the way that it worked and the things that made it Stack Overflow and not any other Q&A engine. It was opinionated in a way. It’s the same story with Trello. Trello, we actually do sell the software, so we’re back to selling the software, but it’s a very … When we built it, Joel’s vision was very contrary to all the other solutions that were out there, the project management solutions. His vision was, let’s strip it way down and make it this really simple visual metaphor. Everything out there was always just you have a big database of issues or cases or bugs, call them whatever you want. Leads. Even Salesforce is like this. It’s like, you have this giant database and you basically just have to build an interface on top of the database.

Joel:
Yeah, you look at the app and you see the tables.

Michael:
Trello was this … It was a totally different, it was like no one’s thinking about it like this. Let’s try this. That’s the valuable part to Trello. It’s not that we wrote a bunch of code. Certainly, we have a headstart because we had this big team. They understand the core mission. We have these mobile apps. If somebody tried to build exactly what Trello is, they could do that. There’s already a clone of Trello and there’s a thousand clones of Stack Overflow. Why are those things successful? I think it’s because a lot of times … This is actually attributable mostly to Joel, is that he has a vision for something that people aren’t understanding right now. It’s about seeing what’s going on in the future and coalescing there or trying something. Actually, sometimes it’s making an Indian job board, for example, was not that successful. It’s our classic mistake, but sometimes you miss and people don’t…

Joel:
Cowboy job board was pretty good.

Michael:
The what?

Joel:
The cowboy job board.

Michael:
Cowboy job board, yeah.

Developing Products for the Long-term

Allie:
Lots of cowboys out of work these days. Great. As you were talking, I was thinking, contrary to that, when you’re starting a product and you’re thinking, what do people need right now, and now we’re in this interesting place at Fog Creek where we’re 15 years in on this product FogBugz, that has become this really big thing and there’s a lot of technical debt and it’s a very … It’s like we’re not quite a startup anymore because our product is pretty mature. I was wondering, Jack, if you could talk a little bit about … Also because you were saying, Michael, that the thing about Trello, was that it was very pared down, right? It’s really in contrast to Fog Creek, where the product is very involved and it’s gone through a lot of different changes and there’s a lot of things that you can do in there. I was wondering, Jack, if you could talk a little bit about coming into a company where the product is mature and starting to work on it and what it’s like on the other side of that, where you’re working with a product that has been around a while.

Jack:
Yeah, it’s really difficult. That’s a fundamental question for a legacy product that you’re continuing to support. I guess technical debt is really interesting for me because it’s a great metaphor to use the word debt and to think of debt as you’re borrowing. That’s why you have debt. How can you capitalize on that? If you have a lot of old debt and it’s just continuing to increase, then you need to pay it down because you don’t want to continue to pay interest on that debt. If you want to do new, exciting things, then maybe you take out some debt, and that’s okay because you need …

Joel:
Debt is also leverage.

Jack:
Yeah, exactly. Debt is leverage. The technical side of things is balancing how much leverage you need vs. how much it’s going to crush you ultimately.

Allie:
Right. One cool thing about Fog Creek, I think, and the reason why we have Stack Overflow and Trello is Fog Creek has always been a place where we’ve continued to innovate and new products are always coming up all the time. Jack, you’re working on a new product right now so I was wondering if you could talk a little bit about as opposed to working … You’re leveraging your technical debt right now, right, working on this new product. What’s that experience like for you?

Jack:
Yeah, it’s interesting. I guess we’ve been going through a phase of prototyping as well at Fog Creek. Just trying out new ideas, giving ourselves the opportunity to make those same failures that Joel and Michael are alluding to in our past. We tried out a bunch of different new product ideas at the beginning of this year. Some of them seemed really interesting and some of them seemed like this is never going to actually become a product at all. A totally different ballgame. You’re not even thinking about those things like technical debt or your previous customers. You’re just thinking, how can I make a prototype of this product the quickest way possible, just to prove a concept? You want to make that concept as fast as you can and see that it will fail, if it’s going to fail. A lot of them are failures and that’s okay.

Justin:
For us, thinking back to when we were starting Trello 4 years ago, whatever it was, anytime we tried to think ahead, and tried to plan for the future and develop something in a way that was going to scale better or work out better in 2 years when we had … This was when we had literally hundreds of users. Thinking ahead to thousands or whatever users, we ended up doing it wrong. Checklists was a famous story. I’ve talked about this a hundred times with various people. We had these crazy ideas of how we thought Checklists would work in the future and we built it that way to start.

Allie:
What were they?

Justin:
We thought Checklists were going to live on the board and you would

Allie:
They live in the cards now.

Joel:
Actually, I forgot about that.

Justin:
They were templates basically, and you could have a checklist template that you could apply to cards, so if you had the same card that had the same checklist all the time, it’d be real easy to just put that checklist on the card.

Joel:
I guess we were concerned about … We were building a more complicated model than we needed to.

Justin:
Yeah, and it ended up backfiring. We had to redo it several times to simplify it. To make it more scalable.

Allie:
The original reason why you were doing that was because it was something that you would want in 2 years?

Justin:
Right. We were trying to think ahead and plan ahead for greater scale and more complex use cases and it just backfired.

Joel:
I think it speaks to, when you have a product that’s been around for 15 years, you realize that all the things everyone bitches about when they have to work on a product that’s 15 years old, are all there for a reason. There were really good reasons it was done that way. In fact, the first version of whatever you’re building, it just doesn’t make sense to build it to last for 20 years because who knows if it’s going to work at all or if anybody’s even going to want it. You make a very simple version of it and it probably has to get rewritten 2 or 3 times, even in the early days, just to get good enough to support a few users, if you have any success whatsoever. Then you’ll discover 5-10 years down the line, the technology is kind of old. We had that approach when we started building Trello, right, when we decided what technologies to use.

Justin:
Yeah, exactly. We only used the latest stuff. We only supported the latest browsers.

Joel:
That was, was it 5 years ago now? No, when did Trello start?

Justin:
We started working on it …

Allie:
2011?

Justin:
Yeah, January 2011. Then launch was September 2011.

Joel:
Those decisions were being made 4-5 years ago. We were actually saying, let’s not support IE. What was it? It would have been IE6.

Justin:
7. It was 7.

Joel:
IE 7. We don’t even have to support IE7. Today, IE8 is not even a thing. IE9 is barely a thing. It’s interesting that any work that we would have done then to support IE6 or IE7 would be a complete waste of time today. It wouldn’t have had enough value for us.

Justin:
And it would have prevented us from doing something that exists now.

Joel:
That’s because today, we got 10 million users and back then we had … Sorry, 8. Today, we have 8 million users and back then, we had 17, so all that work to get from 17 to 19 users is nothing compared to … Those extra 2 users today, are meaningless.

Michael:
When Jack was talking about stuff, when we’re talking about failures and stuff get thrown away and that culture of just building something and trying it out and testing it, it’s like, even at Trello, we built this whole feature around video chat that we threw out because it was just too janky. It was kind of not work because the WebRTC model that it’s based on is just not … It’s okay but it’s totally not up to speed. Our 8 million users wouldn’t have appreciated it. We do that all the time. I don’t know if they’re still throwing stuff away at Stack Overflow or not. David?

David:
When Joel was talking earlier about, you have to build one to throw away and then rebuild it and so on. I actually think it’s … What makes it harder is, you’re not going to have to rebuild everything. You’re not going to have to throw away everything. You’re going to have to throw away about 25%-50% of it and rebuild it and you don’t know which 25%-50% until it’s too late. Any time you try to guess and overbuild it … I think we see that with Stack Overflow. The things we’ve had to … I’ve actually been thinking about, it’s been surprising how stable the core of Stack Overflow has been. A lot of the core has really held up, but some systems, we’ve had to rebuild. We completely rebuilt the reputation system.

Joel:
And the tag engine.

David:
And the tag system. We wouldn’t have known that then, that those were the things we were going to have to rebuild. We haven’t really had to rebuild…

Joel:
Jack did.

David:
Well, we knew we were taking some shortcuts with the tags and stuff but that worked, right? Building the actual tag engine, which is the thing that lets you filter by … Basically generate an arbitrary list of questions based on the tags and some other things. Actually, building that thing was really complicated and you don’t want to do that until you’re sure you need it. That’s one of my favorite hacks that they built early on to handle tag filtering.

Michael:
Just a LIKE query?

David:
Yeah. Basically. It was, they actually abused SQL server full-text indexing and so they put all the tags … You could have 5 tags in a question. They put 5 tags in one field in the database but full-text treats it like it’s a sentence, right? You’re doing search on a sentence and you say, contains this word but not contains this word, which works great, except the full-text search doesn’t recognize certain characters or it treats them as word breaks because it’s detecting sentences. Hyphens or the # in C#, things like that would just be stripped out by the full-text search. They decided, okay, well, we’ve got these extra characters lying around …

Joel:
That nobody uses.

David:
That nobody uses. The E with a funny accent over it, or the O with the umlaut.

Michael:
C# became CE.

David:
Nobody needs those. Yeah, I think that was the O with the umlaut or maybe that was the hyphen that was replaced with that. They just had this switch statement that just replaced characters on the way in and out, and it worked.

Joel:
Until our first French website.

David:
It worked until we needed to go to the national sites. That part really broke down when we went international, but before then actually, performance broke with the full-text search so we had to half-rebuild it for performance, and then we had to completely get rid of it for internationalization. That was a lot of debt paid down.

Michael:
How many years did it last?

David:
It was a good shortcut. It lasted a few years. It shortcutted one of the more difficult problems in building. It was just like, yep. Let’s just take this quick path and we’ll pay it off later.

Missed Opportunities

Allie:
We’ve touched a little bit on failures and talking about features that have failed and different kinds of stuff. I want to just run through a couple other products at Fog Creek that you don’t know about, or that you may never …

Joel:
Wait, what? Do I know about them?

Allie:
No, you know about them. We’ve been building this in secret. You know that box fort in the back of the office? That’s what we’re actually doing. Okay, so there was a product called Co-pilot that Fog Creek no longer owns. It still exists.

Michael:
That definitely was not a failure. That was … One, we made a cool documentary out of it, which is super nerdy and difficult to watch now, but it was really fun and also was a cool marketing thing for us. We sold a bunch of DVDs. That site’s still up and one of the original creators now owns it and is putting a lot of work into it.

Allie:
Alright. I’ll take that one back.

Michael:
It’s a failure in the sense of if you think about at the time, we had 3 interns build it and it was …

Joel:
Four.

Michael:
We were probably right at the moment … That’s right. Four interns. Right at the moment where LogMeIn did not exist as a company at that point.

Allie:
Co-pilot is screen-sharing software.

Michael:
Right. We essentially could have built LogMeIn.

Allie:
Right.

Michael:
Timing-wise, we were ahead of the curve.

Joel:
The big mistake there, I think, is that we didn’t merchandise it like we did Trello. If the core version had been free and we had charged for a business version, we could have.

Michael:
That’s right.

Allie:
It was like $5, right?

Joel:
Yeah, well, it started at $10 a day.

David:
The whole positioning was also very much around tech support. It wasn’t quite…

Allie:
Right. We used it for tech support.

Michael:
It wasn’t like GoToMyPC.

David:
It didn’t take the Trello stance of well, you can do anything with it.

Joel:
…be for everybody.

David:
That would have been a little bit…

Michael:
The marketing was a little bit of a miss and the pricing was a little bit of a miss and also, there was a point where it would have taken a decent amount of technical work to make it as fast as it needed to be.

Joel:
Basically, we went as far as we could just leveraging this VNC protocol, and the next thing to do would be to write a Windows display driver or something, and get into the operating system. That would have been ten times as much work as everything we had done up until then and we just couldn’t afford to do it, really.

Allie:
Is that when you know when to pull the plug? When the work outweighs the …

Joel:
We still haven’t pulled the plug, in the sense that the product is still available and you can get it.

Michael:
Yeah, it was successful but it could have been ridiculously successful.

Allie:
What about, Michael, you mentioned CityDesk and then there’s WebPutty …

Joel:
Yeah, CityDesk could never have been …

Michael:
Yeah, CityDesk could not. It imagined a different future.

David:
You had the right idea but there was a fork in the road and you went the wrong direction. If you had gone the other direction, like the CMS thing

Joel:
You mean web-based.

David:
Right. A web-based CMS could have been huge.

Michael:
Right, yeah.

David:
…for a desktop-based CMS.

Michael:
Or even a hosting service that just hosted TypePad or something until they came along and did it themselves.

Allie:
Right, so how do you know? Is it different for each product, it sounds like? When do you pull the plug on something that’s just not working?

Michael:
When do you pull the plug? I don’t know. That’s tough.

Joel:
Don’t ask us. We’re not experts on…

Michael:
It’s hard but I think we’re getting better. We’re also getting better at understanding how to build … We were building the right thing but then there were a couple of tweaks we were missing the biggest impact that it could have had. I think we’re getting better at that, right? Understanding how to make the biggest impact.

David:
The hard ones, I think, are like … They’re like, I don’t know who talks about it. They’re like zombie companies or zombie projects, where they’re just successful enough that you keep pouring resources into it but they’re not growing. That’s kind of where Co-pilot was. It was a good product. People used it. It made money, but it flatlined and it would grow a little bit but not very much.

Allie:
We’ve also got …

David:
That’s when it’s hard, right? Because if it’s an outright failure, then it’s just like, okay, great. Shut it down.

Allie:
Yeah, when it’s in the middle … We can also talk a little bit about Kiln, which is …

Michael:
That was kind of in the middle.

Allie:
Sort of in the middle too.

Michael:
The bet there, the miss was, we bet on Mercurial and Git won even though … It was like VHS over Betamax.

David:
I think that was part of it. I think actually, the second mistake we made, and I was there for that, was we … I think actually, it was a mistake to bet so much on FogBugz integration. Tying it so closely to Fogbugz, if it had been built more as a standalone thing, it may have done better.

Allie:
David, you want to tell us what Kiln is for anybody who might not know?

David:
Kiln is GitHub without the social parts.

Joel:
It’s code reviews and version control.

David:
It’s code reviews and version control, that’s right. It was built originally on Mercurial, which is like Git but…

Joel:
Only better.

David:
Slightly simpler/less powerful. Anyway, at the time that it was made, distributed version control, which is what Git and Mercurial and a few others are, was clearly on the rise. Everyone was starting to recognize that this was probably a slightly better model than the centralized version control for certain things for most companies. It’s probably the direction people are moving, but you can only really pick one source control system. You never want to have two in your software company. That was the bet that Michael was talking about, that Fog Creek, we looked at it and we said, nope. Mercurial is going to win. It’s simpler. It’s easier to pick up. It’s way harder to shoot yourself in the foot with it. This is where things are going to go, so we’re going to build it on Mercurial, and GitHub had bet on Git and …

Michael:
Git won. We made a second mistake. Yeah, Git won because GitHub won. Where we made a second mistake was, we were like, okay, now we’re going to support Git because Kiln does support Git and has for a very long period of time.

Allie:
Was that Harmony?

Michael:
Well, our first idea was, we’ll support Git. We’ll do that work. With a little bit more work, we’ll allow companies to be agnostic. Anyone and their team can use either one. We’ll do all the hard work on the backend. Like David alluded to, people just pick. A team just picks. There was no market for this. If we had gone out and asked people …

Joel:
They might have told us.

Michael:
Yeah, we might have been able to find this out. We did…

David:
I think it’s the sort of thing that they would be like, yeah, that sounds great. In theory, but in practice …

Michael:
Right. Pay for it then and they wouldn’t … We accumulated a lot of technical debt because we over-engineered that product. We built something very complicated that we’ve now ripped out and now we either support Git or we support Mercurial.

Allie:
Right.

Michael:
There was a lot of opportunity cost of time spent doing both.

David:
Solving a problem that turned out to not really exist, basically.

Michael:
Right.

Allie:
It sounds like with Kiln, what you’re saying is if we had just gone out and asked people, and it sounds like that’s a huge thing of what David was talking about…

Michael:
We just got unlucky a little bit there.

David:
We made mistakes in retrospect. It’s easy to see the mistakes in retrospect. Just asking people, I don’t know if they would have told you the right answer. Like I said before, I think actually, tying it to FogBugz seemed like a good idea at the time, because it’s like, oh, we can leverage all our FogBugz customers and just get them to add Kiln and it’ll be this awesome upgrade for FogBugz, but then it didn’t … It prevented it from standing on its own as a product and it forced it into some … I think it ended up in weird UI that was trying to look like FogBugz but not, and then eventually, that was abandoned.

Allie:
It had its own bird.

Joel:
It still has a bird.

David:
It actually took a lot more work in the initial work to make it plug into FogBugz and act like a plugin.

Justin:
Right, which is not something we did with Trello.

David:
A one-time initial release, which didn’t add that much value for customers, really. I think the clean break of Stack Overflow, the clean break of Trello was just like, no. Build a new thing. Build it separate.

Justin:
Then you can build an integration.

David:
Then, yeah. Then you’ll know if you want integration.

Jack:
I guess I agree with what David was saying about Kiln and its …

Allie:
Did you work on Kiln ever?

Jack:
No, I worked on Kiln briefly, but not to a great extent. One of the things that we missed out on, which Michael was alluding to GitHub, Git winning because GitHub won. It was this social aspect of it. That’s exactly what the FogBugz integration with Kiln prevented, right, is that we couldn’t grow by becoming this social thing. That’s clearly the opposite of what we’re doing in Trello, because Trello is saying, hey, let’s give this away for free and everyone can use it. You can use it with your friends. That’s a great way to grow interest in something.

Joel:
I think if you look closely at Trello, one of the reasons it wins and it’s hard to notice that because we forced it, but we decided early on, the idea is you have your Trello account and with your Trello account, you can access boards that are your own boards, but you can also access boards from other organizations. It’s interesting because you can compare it and contrast it to Slack, where with Slack, you have to be part of an organization and you end up with 7 Slack accounts for all 7 organizations that you’re in, and if you’re not in an organization, you can’t use Slack even if you want to communicate with people. In the Slack-y way, there is no way. It’s this weird thing that I think we got right in Trello and part of that was looking at Kiln and saying, we got to give you something that creates a social network-type aspect to it here.

Justin:
It’s funny because we’ve been building out an enterprise product recently at Trello and having a lot of these discussions on how that works and how the security model works and all that. We’ve been reviewing and thinking a lot about the way we do accounts and the fact that we start user first instead of team first, even though it is a collaboration tool, which is different than most project management collaboration-y tools. You have to create a team and then you join a team, and then you invite people to your team.

Joel:
We would get into these debates with investors who would say, we only invest in network things with network effect. We would say, we have network effect. They’re like, what network effects do you have? We’re like, well, you will want to use Trello because you’re on these different teams and they’re all using Trello for different reasons, and you need to collaborate with all of them. They just didn’t see it. They saw it as … Well, some of them saw it and some of them didn’t.

Michael:
It enables both though.

Joel:
Some of them just didn’t buy it.

Justin:
We hear these stories all the time where you’re using Trello at your company, whatever, doing whatever. You get it and you see the value and use. Then you create a board to use with your spouse or whatever and you invite the contractor who’s helping you remodel your kitchen. Was actually a real story that we heard.

Allie:
We did that when we remodelled the kitchen at the Fog Creek office.

Justin:
Yeah.

Allie:
Our guy was on that Trello board.

Justin:
The fact that you can take it and use it with a different group of people without having to create another entity for those people, because you don’t need a team for your wife and your contractor or whatever it is. You’re just going to have one project once and then that thing can go away when you’re done. It feels very heavyweight to have to create that higher level thing and then invite people to it. I think it constrains it to grow in that way, from growing that way.

The Impact of Venture Funding

Allie:
Great. I’m wondering, one of the differences between Fog Creek and Trello and Stack Overflow, is Fog Creek is totally bootstrapped and has never taken any venture capital. I’m wondering, when talking about failures or different products or just things that haven’t hit, or when you’re trying to figure out what direction a product is going to go, how, Michael and Joel, do you feel like you’re able to take the same kind of risks when you have investors or are you more inhibited, or what are the differences, I guess?

Michael:
Think about Co-pilot for example. We’re bringing in, at some point, say we’re bringing in 30 grand a month in revenue for Co-pilot. We’re like, wow.

Joel:
Free money.

Michael:
This is awesome. Yay. Paid for a couple devs. You’re like, yay. But the problem was, that was real money to us because we’re a small, profitable software company, right? Then in some ways, I think that prevented … There was a little bit of that prevented you from taking this big leap and saying, hey, let’s just make Co-pilot free. Right? Because we got to pay the bills. The cash balance, the bank account can’t go below zero. Later on, when we knew we had something that was going be successful and it was going to be big, and we had proven the product a little bit, it was much easier to say, okay, let’s go for the gold. Let’s build the big thing and do the things that are necessary in order to make this hugely successful.

David:
I think that’s maybe the difference also between Trello and Kiln, right? I think Kiln, the decision to tie it to FogBugz was a safe, short-term bet for quickly getting to some revenue, instead of dreaming big. To build GitHub, you have to have a much bigger vision for what this thing is going to do, and like you said, to justify giving it away for free. I don’t think you have to be that way if you’re bootstrapped, but the tendency is going to be to dream small and be happy with a smaller revenue stream. Of course, then the tendency in venture capital is to go big and bust, right?

Allie:
Right.

David:
There’s a downside to it too.

Michael:
For Trello, it was actually, it keeps a lot of … Somebody could recreate Trello with a decent amount of work, but it’s not impossible. It prevents this tiny group of people from doing that, right, because they’d have to charge for it and because it’s free.

Joel:
Actually, there are a lot of people in that category. I remember in the early days of Trello, a lot of clones were showing up and a lot of other Kanban boards for software developers were showing up for some reason. It was a popular thing that year. I would go check them out every single time. There would be a Hacker News headline saying, look at the Trello that I made or something. I would click on it and be like, oh no. I would click through and I would see one of two things. One, I would see terminology from the software development world, and then I’d be like, oh whew. They missed that boat. They would just be like, and we have burndown charts or something that’s specific to software developers. I knew they could never meet Trello. More commonly, I would look for the little pricing button and I’d click on that and they’d say, it’s only $19.95 a month per person. I’d be like, oh, excellent.

David:
That works with a winner-takes-all product, right? I don’t know. Is that the same thing with … Well, I don’t know.

Joel:
They’ll make a little lifestyle business if they can support 3 people, like FogBugz.

David:
Yeah, that’s true. You make a niche product.

Joel:
Which was bigger and it supported more people and they could get to that, but they won’t make it GitHub type, like this could change the world and everybody knows it and everybody uses it type product, if they’re going to charge every single person.

Allie:
Have you ever given thought to if you had to do it over again, would you have taken money at Fog Creek?

Joel:
Oh, I wouldn’t have taken money at Fog Creek.

Allie:
You were pretty anti taking money for a while.

Joel:
For sure, because I think that you can lose control and a bunch of things changed. One is, cases at both Stack Overflow and Trello. We had much better opportunities for the investors, meaning that we got to dictate our terms. We did not lose control. The other thing that changed is there is a very small and limited group of VCs out there who now understand what it means to be entrepreneur-friendly, which didn’t exist or we were afraid didn’t exist at the time that we started Fog Creek. I still wouldn’t have taken VC. If I knew what I know now, I probably would have immediately gone straight to some much better products. In the year 2000, what would you build? First, you build Git.

Allie:
Facebook?

Joel:
Yeah, Facebook. There you go.

Allie:
Twitter? AirBnB?

Joel:
I literally had a friend who kept explaining something and it didn’t make sense to anybody and years later, I realized that what he was describing was Facebook, only instead of saying you have a wall and people come and write on your wall, he said you have a couch and people come and leave things on your couch. I was like, what? This is ridiculous. It was only after Facebook came out that I realized that much.

Allie:
Who likes people to leave stuff on their couch? Nobody.

Joel:
What he was describing, other than the fact that he used the word couch instead of wall, was just Facebook.

Hiring Smart People Who Get Stuff Done

Allie:
Okay, so we are nearing the end of our time here so I just wanted to see maybe if we could go around the table and maybe say like, if you had one piece of advice for somebody starting out …

David:
Have a brilliant idea at the right time and execute on it really well. It’s easy. Two things.

Joel:
Make a website. Make it really popular.

Michael:
No, it’s two things.

David:
Start with a super popular blog.

Michael:
You have to think about the world and imagine it in a different way in the future, and then prepare for that, right, in order to be a big winner because people aren’t … Basically, the idea is not that many people are going to see it that way. It’s like AirBnB. You’re trying to pitch it a couple years ago. You’re like, yeah, it’s cool. People rent out rooms in their houses and people are like, ugh. You’re crazy.

Joel:
That’s gross.

Michael:
I’m not going to have some weirdo stay in my house. Then it actually does work in New York and then it starts to take on some of the vacation rental stuff and it actually grows into this big thing and the world changes and the way people trust each other changes. So there’s that. The second thing, which is more along the lines of what you guys were saying was find an amazing co-founder who’s really smart and amazing person.

Joel:
Just generally hire good people that are smart and get things done.

David:
That’s one thing that you can actually do, right? Go have a brilliant idea is like, good luck. Where do I start? Gather a really good team is something you can actually work at and figure out and solve.

Justin:
Yeah, hire smart people. Give them room to operate. I think you have to have a lot of optimism, think about what could exist and try it.

Joel:
We also have tried 15 or 16 things over the years between these 3 companies.

Justin:
Yeah, when it doesn’t work out, think about why.

Joel:
Three or 4 of them are huge and …

Allie:
What do you do with the people who fail? Where are they now? Are they in a cave?

Michael:
We killed them.

Joel:
There is always an opportunity in the dog-walking of Taco, and washing of my car departments.

Allie:
Anybody else have any final words?

Michael:
Happy anniversary.

Allie:
Happy anniversary, Fog Creek.

Joel:
Yeah.

Allie:
Alright. Thank you, guys.

David:
Thank you.

Joel:
Bye, everyone.

Allie:
Bye.