Ep. #14, Flexible Collaboration with Michael Pryor of Trello

Grant Miller: All right, Michael. Thanks for joining.

Michael Pryor: Thanks for having me.

Grant: Cool. So, let's just jump right in. Tell us a little bit about your background, I know you started a couple of companies. Tell us what that's about?

Michael: Let's roll back the clock. 1998 I graduated from college.

Grant: Congratulations.

Michael: Thank you. I moved to New York City and I thought I would just stay there for a little bit of time, but I met someone there at my job.

His name was Joel and we were working at a company called Juno, which was a free email provider, and at the time it was competing with AOL.

You paid to sign up for AOL, this was free email but we'd show you ads.

So we worked at Juno for two years, I met Joel there and he had come from Microsoft.

Then the whole tech scene was falling apart a little bit, people were getting fired and laid off, and it wasn't as fun.

So we were like, "Let's go do something else."

I was really young and naive and dumb and privileged to be in the position I was in, a software developer in 2000 could make a decent salary in New York.

Grant: Sure.

Michael: So I was like, sure, let's start a company. I don't know anything--

Grant: Silicon Alley, as they call it.

Michael: Yeah, exactly. But it was like it was all ad tech or finance, so if you were going to start a company in New York in the software industry, if you were a programmer and you wanted a job it was ad tech or finance.

There were no pure software companies there, so Joel and I were like, "Let's just start a real software company like they do on the West Coast, but we'll do it in New York because we don't want to move."

So we did that, we started a company called Fog Creek Software.

We didn't even know what we were going to build, we just started building stuff.

In fact, the first thing we made was this CMS, it was like desktop CMS at the time when Blogger and Typepad were coming out.

It was the right space, but we just delivered it in the wrong way.

Because at the time was really hard to configure the web servers you needed, like SSH access and all this stuff.

People didn't know what that was, but they knew how to type in their FTP credentials so we built a tool called City Desk that was a CMS.

But right idea, wrong product. Right time, maybe.

Then we built-- We had this bug tracker thing sitting around, so we were like, "Let's sell that."

And people started buying that, it was called Fog Bugz.

Grant: That's cool. So you were using it mainly internally and you decided to sell it, or how did that product come about?

Michael: Yeah Joel had built it before at Viacom, when he worked at Viacom.

When used it at Juno we called it Juno Bugz, then when we used it at Fog Creek we called it Fog Bugz. Worst name ever.

I actually think the name had a really big impact on the trajectory of that product, because I think that the way people connect with your product, the emotional branding and stuff is very important.

Look at Slack, there was HipChat before that and lasting up to it.

There's lots of things that contribute to one product's success, like timing and all those kinds of things.

But I think actually the brand and that emotional connection of your customer to what the product is, that carries through to the product itself and how you speak to them in the product.

But I do think that the name plays a big important role in that.

Grant: Cool. That's probably not a super common belief, that name really matters?

Michael: People talk about the domain name, like you want a short domain name, you want a .com, although now they're all taken, things like that.

But I do think it can't be hard to spell. I think we're past that era when you can-- Like Tumblr, and you just leave off the "E" or something.

If you have to say your name and then spell it every time you want to give it to somebody, it's probably a sign that you should not call it that.

Grant: Yeah, that's a good point. But what's one of the hardest problems in computer software? Naming.

Michael: Yeah. So we built Fog Bugz and started selling it as bug tracking software, and about two years later--

I'll come back to this in the story, but these two kids in Australia made this program called JIRA and were competing head to head with us, and they were pretty good.

We were way ahead in the beginning because we had a little head start and stuff, but they were doing pretty good.

Grant: That's funny.

Michael: We build lots of things over the years.

We've built a screen sharing tool where you can go to somebody else's computer when they are on the internet, and you just give them a code, and they would type it into a website and you could see their screen.

Grant: Cool.

Michael: Very common, like LogMeIn and GoToMyPC. But this was before that.

Grant: What was it called?

Michael: Co-Pilot.

Grant: Cool.

Michael: So like, "You could be my Co-Pilot right on my screen." That was a good name.

But we didn't really invest in it, it was the right time and the right product, but we needed to invest heavily in it and we had built Fog Creek was we didn't take VC.

We weren't trying to get big, we took a lot of profits and gave them back to the employees.

We didn't hire a bunch of people, and obviously we're in New York so the salaries were super high, and things like that.

We weren't trying to find a place of low cost talent and take VC and double down and invest, so we built features but we basically invested alongside of our revenue growth.

We were always profitable and those sorts of things.

Anyway, we didn't invest heavily in co-pilot and those LogMeIn and GoToMyPC became huge things at the time, so we missed that a little bit.

Grant: So Fog Bugz, you were selling to companies at that point?

Michael: Yeah, we were selling that. That was another revenue source that we had, and it was doing great.

As time went on JIRA just started becoming more and more of a thorn in our side, or a standard.

They were just getting more and more of the market share and they were doubling down on the features, and it just took off really in a big way.

So if you fast forward to 2010, Joel had always had this idea that the Q&A site for programmers online was called Experts Exchange.

It was just so evil. They would put the answers in the page so Google would see it, but when you went to the--

It was really hard to find the answer, you didn't know you had to scroll all the way to the bottom or something.

It was just janky, and then they would make your company pay to get access to the answers.

We thought that was just a jerk move, to be like "Other people have written answers to these questions, but you have to pay for it."

Like they owned this knowledge, essentially. So anyway, that was Joel who was talking to Jeff Atwood at the time.

Grant: They also didn't do a great job with naming that one either, right?

Michael: No, yeah. "Expert Sex Change."

Grant: Just read that one.

Michael: You have to write it down, make sure you write it down and tell someone else to spell it.

Grant: Capitalize the right place. Yeah, exactly.

Michael: So we were talking to Jeff Atwood, at the time he had a blog called Coding Horror and Joel had his blog called Joel on Software.

They had big followings, and that was primarily because they had spent 10 years writing about software at a time when no one else was and blogs didn't really exist.

So they had -- At that time in 2010 if you tried to start writing a blog, or even today, I'd be like "Good luck. There's a lot of people out there talking, so it's much more difficult."

But at the time, Joel and Jeff had this huge audience that they could seed this network with, because when you're going to do a Q&A site you need the questions and you need the answers.

You need the people to be there on day one.

If you just get there and there's like five questions, you're going to be like "This is dumb. People are going to ask dumb questions," and stuff like that.

So they built Stack Overflow, it was a joint venture between Fog Creek and Jeff and it took off.

We almost made a mistake, we had been in the business of building software and then selling it.

We thought we would have other people build Q&A sites on top of the engine that was Stack Overflow for any topic.

The idea was we built this Q&A engine, we ran it for programming questions and Stack Overflow.

But we were like, "We'll charge you $10 dollars a month and you can run your own Q&A site about motorcycles."

So we ran a beta and we had people doing that, but the problem is the only way a Q&A site works is if you have the people. You need the audience.

There's only a small number of people that could get the audience size to the point it needed to be, plus you wouldn't want to have 10 sites on motorcycles.

You want the 1 Q&A site of motorcycles, so that meant that this business model that we had thought up where we would sell the software was actually the wrong business model.

That the valuable thing about Stack Overflow was not the software itself, it was the audience that had gotten there. The software contributed to that--

Grant: The software is really well done, when you think about the comparative solutions at the time, Yahoo! Answers or these other things, Stack Overflow is a really great way to do Q&A.

Michael: Sure, but in and of itself that wouldn't have done it.

Grant: Agreed.

Michael: That wasn't what made Stack Overflow so valuable, it was the fact that all the programmers were coming there every single day to ask questions, to get answers, and those sorts of things.

We almost made a mistake, one of the partners at Union Square Ventures came and talked to us and was like, "I feel like you should think about this."

And we were like, "That's smart," and we decided to take an investment from them, and that was the first time we took VC.

Grant: Cool.

Michael: Because we realized we actually did need to build a giant-- We needed to get there first if we wanted to build these networks.

Grant: So you split Stack Overflow off?

Michael: At Fog Creek, yeah.

Grant: OK. So it became its own company, independent?

Michael: Yeah, and there's different taxation issues and legal issues about how you might do that and how it's set up and all those kinds of things, but we've spun it off.

Joel became the CEO of that company and I did operational stuff, so I guess by process of elimination I was the CFO.

No finance background, but technically if you look back in history I was the CFO.

That meant I ran payroll and filed taxes, we opened an office in London so I did all that stuff. It was all business operations type stuff.

Anyway, we still had Fog Creek, so I was running that and Joel was doing that part time.

Grant: So you were running Fog Bugz, because that was pretty much the primary product.

Michael: That was the bulk of the revenue, yeah. But we were still building things.

Grant: What was the team size? What was it like? Were you like--?

Michael: I feel like we had about 30 or 40 people.

Grant: Did you think about it as enterprise software at that point?

Michael: Yeah. For sure.

Grant: Was it hosted or on prem? I don't remember.

Michael: It was both.

Grant: OK, so you do both.

Michael: We had made the leap to the cloud and had rewritten a bunch of things in Ajax, so it was like a single page typed out.

We had been developing it and there was a lot of technical debt early on.

We made decisions which helped us from a business perspective, but long term were more problematic from the code, like what we chose as our technology and that kind of stuff.

Grant: You guys were always a Microsoft shop, right?

Michael: Yeah, so we had written some code to actually--

So we could still write a quasi language just like ASP, which is a Microsoft language, but it would convert it to PHP and stuff like that.

Over time, as we added more and more to that, that meant that we had more peculiar homegrown solutions.

It was a good business choice because it meant that we could ship to market really fast, but then over time there were better solutions on the market.

The new developers were like, Why would I want--?

Grant: Rails?

Michael: Yeah. You end up in that weird situation where you have to pay down the technical debt, and I think about that a lot when you think about Trello.

We made a lot of decisions when we first built it, we said "We're going to choose modern technology, all modern tools. We're not even going to try to make it work on old browsers, we're going to choose cool new stuff."

Some of those decisions worked out really great. One of the things we chose was Mongo.

But at the time, this is in 2011, Mongo wasn't anything. That company and the product grew over time.

They got VC, they hired more developers, they basically were growing essentially in tandem with us.

That turned out to be a really good choice.

If you replay the clock, Scott and Mike, the Atlassian founders, chose Java to build JIRA. We chose--

The first iteration was in active server pages, but then more .net type of stuff.

I think it's interesting because those technology choices can have this profound effect later on, because you might have to pay a lot of technical debt to rewrite something. Whereas this new startup does not, because they start on this new tech stack.

But even then, Trello, the new thing, if you fast forward 10 years and you're like, "We wrote everything in coffee script and no one wants to use it anymore, so we had to decaffeinate all our code," is what we'd--

Things like that where we didn't -- Like, React is super cool now and we didn't build it in React so we had to start doing that.

We had to run a big project internally where we're writing pieces in React, but pieces in our old code base, and running them both simultaneously so that we didn't have to do a whole complete rewrite.

Grant: I think the joke with JavaScript stuff is you turn your back and it's like there's a new framework that everyone's using.

It's a very hard ecosystem to stay on the latest and greatest with.

Michael: Node was fine, Mongo was fine. We did a couple of things that that ended up being OK choices as time went on.

But I just think about that, how on the one hand you're like, "I have all this technical debt."

It's like, "Yeah. But you also probably have a lot of customers and money, whereas the startup that just started of course they can choose the modern framework. They don't have any of that technical debt, but they have no users."

So it's six one way, half dozen the other.

But anyway, we were at this point where Atlassian really had cornered that dev market and we weren't seeing a lot of growth in Fog Bugz.

And we were like-- It wasn't as exciting anymore either, so we were trying to think, "How do we reach an even bigger audience? We're writing software for developers."

Then we just had done Stack Overflow. We're like, "What if we wrote something that just could have a much bigger impact and reach more people?"

Grant: But Stack Overflow at this point had a pretty good reach, right?

Michael: Yes, but just among developers. So that was cool, you could go to a party and if there was a developer there you'd be like, "We built this thing called Stack Overflow," and they'd be like, "That's awesome."

But we were like, "Wouldn't it be cool to make something where you could go anywhere and talk to people about it?" And they would be like, "That's awesome."

So a couple of things happened at the same time, where we were looking at Fog Bugz, at this mental model of a giant tracking database type thing, and then looking at what people actually did at work.

They'd be sticking Post-It notes up all over the walls and trying to understand that, because we had Fog Bugz internally to track our own working processes.

But yet the developers, if look in their office, they had Post-It notes, and it's because they were going up a level.

They were two things. One is the database was just too detail-level, so it's more like, "What am I working on right now?"

Joel had this idea that he wanted to build a thing where everyone had it to do list, but you can only hold five things in it.

Imagine a web page where your list and my list and they're all next to each other, but they only hold five things.

So you can go to that page and see everyone's shit. That's, if you think about that in your brain, you see Trello.

Which is also like a com onboard and all those kinds of things, that existed at the time obviously, we didn't invent that.

But this idea that we were going to take something that developers knew a lot about, strip away a lot of the developer type stuff like swim lanes and charts and those kinds of things, and just even the idea of tasks.

Like in Trello, we have cards. They're not issues, they're not tasks, and this is intentional.

A lot of people use it to manage projects, but it is not-- I would not call a capital "P" project management system.

That has a lot to do with how you brand it, how you talk about it. But it's also in the product itself, what is the nomenclature?

How do people experience the product? What are the expectations for the way features work, and those kinds of things?

We're building something super horizontal based on all these failures that we had in the past, like Co-Pilot.

Not total failures, but mistakes we made along the way. We made a lot of different choices.

Same with Stack Overflow, we took a lot of learnings and applied them to the new product.

For Trello, let's build on the new tech stack. Don't worry about the old versions of the browser. Just go forward in time. There is also--

Grant: Use some off the shelf stuff rather than trying to build your own little abstractions internally for everything.

Michael: Yeah, and also try to do it in a way that's very bottoms up.

If people love the tool and they use it, it's free, then that's a huge moat because the next startup can't give away their product for cheaper.

Because we have gotten burned by Atlassian because we had a ton of small teams using Fog Bugz because we were pretty cheap at the low end, but they had a site license at the time.

It was like $5,000 bucks for your whole company for JIRA. So they ended up with a lot of very big customers and we ended up with a lot of small customers, and we thought that that was protective because it was diverse.

Like if we lost any given customer it didn't affect us, but what happens is over time they can raise their prices and add new customers.

They ended up doing this thing where they gave away JIRA for 10 users or less. It was $10 dollars and they gave it to charity, so it was a really good--

Like, it was charitable and it was a good marketing thing, but also what it did was it dried up the interest in our product because now we were way more expensive.

If we had lowered our price at that end, the problem is we would have cut off--

Grant: Your revenue.

Michael: Exactly. Yeah, exactly. So it was a very tough place to be in. That's why when we did Trello, we were like "Let's do a freemium product and we'll give away a ton of value."

We always said "We'll get a hundred million people using it, 1% will pay us $100 dollars a year, and then we'll have a $100 million dollar business."

That was just to try to show the magnitude of what we thought we were doing.

So we built a tool that people loved, and they started using it, and we started-- We made a bunch of mistakes along the way in Trello.

Like we almost named it "Planatee," because we couldn't come up with a name.

We had the internal name called "Trellis,"because it was the code name when we went to work on it.

We thought it gives the structure to something you're working on, so we called it "Trellis."

People liked that, but then we couldn't get the domain name and we had to launch. So we were going to be in a conference and launch it.

Grant: Yeah, you launched at a Tech Crunch thing.

Michael: Yeah. We had an actual deadline, and we did everything to try to find a name.

We bought nameless, we went everywhere.

Then finally we just got to this day where Joel calls everyone into the kitchen, and he's like 'We're just going to vote and pick a name."

Crowdsourcing your name is the worst.

We had always had a mascot, so we had a mascot for Trello at the time that was this manatee, and so people were like "You're doing planning and it's a manatee, call it 'Planatee.'"

Grant: You were going to spell it like manatee as well?

Michael: Yeah, "Planatee"for manatee. Or, "Maybe we change the mascot to an aardvark and Trello has cards, so we'll call it "Cardvark." That was the runner up.

Grant: That's a little better.

Michael: So we left the kitchen, and we were like, "We're going to call it 'Planatee--'"

Grant: I feel like animal names were popular at that time too.

Michael: I don't know. Definitely have a mascot, that's always a good thing for your product. For swag.

So we left the kitchen, and I was like, "Oh my God." Remember, we had named our product Fog Bugz.

And I was like, "I cannot. I am not going to name this 'Planatee." Like, it's so bad. So bad."

I went back to my desk and Joel is like, "You have an hour." I don't know what to do, we can't get the domain name.

We've tried for weeks to do something different, and we just can't.

So I went to an instant domain search website and just started typing words.

After 20 minutes an ad came up for Trello.

I went around the office and I was like, "What do you think of Trello?" And they're like, "Hello, Jello." And I was like, "Do you hate it?"

And they're like, "No, I don't know what it means." I'm like, "Perfect. Can you spell it?"

They're like, "Trello?" I'm like, "Perfect." It's very short to type, so that's why we picked the name.

Grant: Do you still own Planatee.com?

Michael: I think we let them slide down.

Grant: Oh no.

Michael: I think we built Trello inside Fog Creek and then we spun it out after two years. We self-funded it for a while with our own funds, and then we spun it off and took money from Spark and Index in 2014.

But I think we still had the domain name. Then when we got acquired, I think we just let it go.

Grant: You let it go. Someone out there is going to put "Planatee--"

Michael: My license plate though, says "Planatee" on it. Because I thought that was funny.

Grant: That's amazing.

Michael: Yeah. The other mistake that we almost made was we were charging people--

This is a common thing that people do when you first start out, you're like "I'll charge people a flat fee, like $50 bucks to use my product."

But then it doesn't matter if you're a tiny company using your product or a big company.

People don't want to charge per user because in a collaboration product that is a vector of growth.

But for all intents and purposes, that's also a measure of value. A bigger company gets more people using it and more value, and at this point in time everyone gets that.

Grant: Yeah, I agree.

Michael: So making up your own weird pricing scheme is always dangerous, and when you get to a point where people are just like, "Yeah, I get it. You pay for storage, you pay per user."

Doing what other people-- What the market has now accepted as normal is often very advantageous.

You do not need to reinvent the wheel in that area.

Grant: Yeah. People always talk about pricing and trying to price for value in these concepts, or just price to--

Partially price what the market expects, so that's not some weird conversation every time the pricing comes up.

Michael: Right, exactly.

Grant: Then part of it's like, "Figure out a way to have a lower entry offering, and eventually something that you can charge people a lot more for. Even if I don't have it right away, having a vision for what that might be."

That's what it's all about, right?

Michael: It's good, but I think they should have at least two pricing axes.

If you charge per user but you have multiple plans, for example, that way even if you have a company paying you for every single person at the company, there's still an option for that company to pay you more.

You can have even more than two axes, if you look at Intercom they have made three products.

Sometimes you can get to a point where you just confuse people too much and then they get annoyed because it feels like you're nickel and diming them.

But Slack, Dropbox, Trello, it's per user and there are different plans and the different plans have features.

The funny thing, back to the enterprise thing, the funny thing is all those plans they put in the enterprise tier they always put SSO.

Grant: Right, of course.

Michael: Because they know that's a trigger to get people to pay the most, and I think about that --

It's funny because we're going through this thing with Trello where we have an enterprise product that has SSO in it.

One of the things that Atlassian did, because they have so many different products, is we realized that we could actually offer the SSO piece outside of the products, so no matter how many products you use, you just pay once in a very low fee.

If you think about Slack or even Trello today, if you want the SSO you have to pay for the highest tier.

Then you need to pay for all the other people, so it's almost like the sticker shock in there is pretty high.

There's not a way to jump into that. One of the things that Atlassian did, because they had all these different products, is we offered this thing called Atlassian Access.

The idea there is you pay once for SSO and it doesn't matter if you're using JIRA or Confluence or Trello or BitBucket or Ops Genie, you are paying just once per user.

You get the SSO, the 2FA, you can enforce the 2FA. There's a lot of-- It's basically security of the account absent the product that you're using.

Grant: OK. It's like a global account that you have?

Michael: Yeah, there's an Atlassian-- Trello is not on it yet, but we're working on making that transition.

Grant: One other thing I think you guys-- I remember from my use of Trello, was I remember using it and hooking it into Google and then it showed all the different users.

I hooked in the Replicated account, and I'm an admin, so it showed all the different users.

I could easily click and invite, which I thought was really well done. I was like, "Yeah. I want these people added."

Michael: Many different products do that now, I think Quip probably does that even better than we do.

Because they do a thing, I think they keep that around so that when you're in the product you can invite the other people, even though they don't have an account yet, and they just pop that in.

It's almost like they're pretending the person is there.

Grant: You can @ them, and assign something to--?

Michael: Yeah, exactly.

Grant: That's great. So it's like they create a shadow account that then someone can come in and activate if you want to have them activate it.

That's actually great. That's a great idea.

Michael: So it's not only at this moment that you sign in, or start your team. It's just--

Grant: As you're using it--

Michael: Yeah. Because you might add more people to your G-Suite database later.

Grant: Of course.

Michael: So that gets into the virality of how you bring people in, and those sorts of things.

Those products out there, if you look at any collaboration product, they're doing cool things.

Trello does a bunch of stuff, but Quip and even our competitors, if you look at Asana.

But also Dropbox is a nice one, Dropbox is interesting because they have this nice-- Like, you might use it for yourself but then you also use it at work.

Which is a thing that happens a lot with Trello, too.

They do a pretty good job of making that really compelling and obvious, and I think they're also very much in the position of a bottoms up thing where people might--

Just from a consumer perspective, they might sign up for a Dropbox account and use it and then Dropbox can look and say "There's like 52 people at Atlassian using this. Are you sure you don't want to buy the company account and everyone can use it?"

Which I think from a Trello perspective, might be interesting to listeners, but that's one of these routes where you have a tool that is much more adopted at the individual team level and it's not a tool that's only going to be used at the company level.

If you think about Workday, for example, a Workday-- You can't adopt a work day with your marketing team, you have to sell to the CIO or the COO or--

Grant: The HR person, or whoever.

Michael: Yes, exactly. So you might be building enterprise product from that perspective, and then the challenges there become the salesforce challenge.

Because you have a really long sales cycle, you have to do all the typical enterprise sales, and it's hard to find those customers.

You have to sell them the product, because they're not currently using it, so you have to find the problem that they need.

You have to demo it and you have to get an introduction, whatever. You have to do all that stuff. With the other tools , like Dropbox or Trello--

Grant: The bottom up--

Michael: The bottoms up, people are getting value, you have plans where people can whip their credit card out and pay for 10 people at their company.

Grant: You might even pay that just because you're like "I want to use a great tool. My team-- I make $200K a year as a VP here, and I want to have my team on a great piece of software where we can all collaborate."

So you don't care about the cost. You're like, "I'll pay a couple bucks a year to let us use this tool."

Michael: The enterprise play there is usually then you find a specific domain is using a lot of your product, whether it's free or paid.

Then you try to find the person to bring that all together. That's a different challenge, right?

Because it could be that the person appropriate for that decision isn't the person using your tool, and you don't have that sales force.

You don't have somebody that's going to do field.

They're going to go out and talk to the CIO and take them out golfing or whatever, you don't have that.

So how do you do that from the perspective of Trello, or other bottoms up tools?

Grant: Yeah. I'm interested in when you think about the go to market from Trello, a lot of times when the open source world happens people will look at who's using the product on the open source side and who's creating new issues and things, and then they'll have a top down salesforce go out and get them.

How did you approach that at Trello? Did you have a sales team?

Michael: I think initially, the initial way that we first did the enterprise product was I hired somebody I had worked with that had done sales before for us.

Then I hired her back as my--

Grant: At Fog Bugz?

Michael: At Fog Creek, yeah. Then she went somewhere else and I hired her back when we got funding.

Grant: Cool.

Michael: I hired her as VP of sales and I said, "I don't have a product, an enterprise product. I have a paid product but I don't have an enterprise product."

I was like, "Just go sell it." She's like, "But what is it?" And I'm like, "You tell me." I was like, "Just go sell a handshake and a hug and see what you get."

Grant: "We can build software, so tell us what else we need to build."

Michael: So she did, she went out there and she was like "I'm selling our enterprise product, which comes with an account manager. Me."

That kind of stuff, where you just start out there and then we learned.

Obviously you have the Enterprise Ready website, which just details these things that you have to build. SSO, account management, that type of stuff is top of the list.

Grant: Yeah, for sure.

Michael: You just build out those things, and then essentially that's the expectation of the buyer, and that's what we did.

Grant: OK, so you initially-- You didn't really have a business offering, per se.

Michael: We had Trello which had some admin controls over your team, but when we were thinking about enterprise these were the different tier.

This isn't 10 to 50 people, this is like 50 to 10,000 people. We didn't have anything in the product per se.

We had to build pages and things to show them that, and I think in Trello's case it's a little bit more difficult.

If you think about Slack, they had this problem too.

Because you would make little Slack instances for your team, like you'd be the marketing team and you could make a Slack instance.

Then you might even say, "The whole company can use it." And that works for like 100, 200, 300 or probably 400 or whatever.

It gets to a certain size where the Slack instance starts breaking down, and now you need multiple instances which is their enterprise grid thing.

Grant: Enterprise grid, yeah.

Michael: They had to invent that, they didn't have that, and the problem with enterprise grid was if you stitch together all these sites, in each of those sites you have an account but you're the same person across all those things.

You might have used a different e-mail or a different password for each one, so the authentication part is a really hard problem to solve because you start from--

If you started from there, if you started like "I'm going to have a grid," and then built down, you'd be fine.

But that's not how these products work, you build a thing and then you realize, "Now I have to layer this on top."

In Trello's case, if you think about Trello, it's just a network of users. There is no site, there's nothing that wraps people into a place.

You don't go to Nike.Trello.com, you just go to Trello.com and you log in.

Finding those other people and the content around that, it's up to you to put those in a specific place.

But there's not really a wall around the people, or the content, implicit in the way that it's designed.

Now that helps us on the collaboration side, but when you get to the enterprise layer that's what they want.

They're like, "I know everyone at my company is using this product."

And they're like, "I really want to know that I have the peace of mind that when I am sharing a board with Joe Smith, it's the Joe Smith that works at my company, not this other random Joe Smith. And when Joe's doing things in Trello, that Joe doesn't just invite somebody else in--"

Grant: His mom on accident, yeah.

Michael: Exactly. They just want that piece of mind that they know that they can put up a fence or a wall around it and just say, "OK. All the content is in here, all the people are in here, and they're doing their thing.

Grant: This is interesting because I think that there's two approaches to user management.

I think GitHub and Trello did it in a similar way, which I call it "User-centric."

Michael: Yes.

Grant: Versus you think about Google, it's like company or account-centric.

Michael: Yes.

Grant: So you have one account on Trello, and you could have your personal stuff attached to that and you can have your work stuff attached to that, so there's a global user.

Whereas other places you might just have multiple accounts to sign in and out.

Michael: The thing though that we did where you just might have one account, I think is a mistake.

Grant: OK.

Michael: When we looked at it actually, people might use the same account but I think the standard now when you look at Google is you have an email address, you have a personal email address and you have a work email address.

You just switch between them to get your stuff, and I think everyone gets that.

That's the way Dropbox works, and I think that's how Trello should work too.

We don't have that today, because we don't have an account switcher, but that's ideally where we should go.

Because it just avoids a lot of confusion around these things, even if you're not talking about enterprise.

Even in the case of just what you're doing, and if you don't care, then fine. If you're using your Replicated account and you've got your travel board on there, who cares?

You don't care, so fine. It doesn't matter.

But it is the expectation that people are like "I have an e-mail address that matches my account, and that's how I set my identity.

Even though I'm the same human, I want to be able to log into this app with that email address and I want to use a different email address to log in for my other shit."

Grant: There's also some amount of user-- It makes them more comfortable, because they're like, "My personal Trello account is not associated with my work, and I can keep my personal stuff there."

Michael: You don't get a notification from your mom about Christmas presents, and then your boss about the thing that you-- That's the problem when you have these accounts.

Of course, you could build stuff into the app so it's separated your notifications by whether you put this board in a different place or whatever, but everyone just gets the account separation at the top being driven by your email address.

It's just a standard now. Go to Google, you change it, you just get it.

And that, because that is the case, that is what we need to do because that is the expectation.

Grant: Yeah. This is generally where Enterprise Ready came from as an idea, was that there are these patterns that start to emerge.

That if you just embrace the patterns, then everybody understands how your stuff is going to work.

And some of these things, it doesn't make much sense to reinvent.

Michael: It doesn't, it's not core to your product.

We were talking about this before, we were talking about one of the features on there is audit logging.

If you know that you need to do audit logging when you build your product, if you put the hooks in there in the beginning, you are going to be way happier in thee long run.

Grant: Instrument your code in the beginning to save-- Yeah.

Michael: And then it's going to be so easy.

But audit logging, it's like when I think about that problem we didn't build them into Trello.

But when I think about it today, I'm like "I wanted to build a whole interface to search all your logs, and it's going to be all this data.

You have to build fancy search because it's just tons of data and you want it to come back fast."

And I'm like, "Everyone uses Splunk for this now."

And it's almost like today if you want to do audit logging you could just say, "Great. We publish all of our events to Splunk, flip this switch and give us your Splunk instance," and that's how you provide that feature.

Today that would probably be fine for 95% of the enterprise companies you're going to talk to, because it just becomes a standard.

Grant: That's what they likely want to do with it anyway.

They want to centralize all of the incidents and activity and actions taken in one place, so they can search over it and it's not like they have to--

They can if they want to just search the Trello ones, you can make that a filter, right?

Michael: Yes, exactly. And then you don't have to worry about building all that filtering and search, which is clearly--

When you think of in the case of Trello, that is not core to the value prop that we do.

So spending time, we have to implement that because that is the expectation of the company.

But you want to do it in a way that puts your resources on things that differentiate you from other people, not rebuilding the wheel that's not actually going to drive the value.

Grant: Yeah, 100%.

Michael: So, like if you had reporting.

You could build all kinds of crazy reports and stuff like that, and you might need to do at least some of that stuff internal but at some point you could just say, "How do I build a really good export to Excel or Google Sheets?"

Because that's what a lot of people just want to crunch numbers, so if you have a really good Google Sheets integration then that goes a long way.

You don't have to rebuild everything-- Like, think about Google Sheets. They built filtering, formulas, and these are like--

As you start going down that path of reporting you're going to spend so much time building interfaces and then you're like, "Now I have to do a filtering mechanism?"

And it's like, "Why write that code when you could just publish your stuff to Google Sheets?"

Grant: Yeah. Reporting is one of these features that I feel like it's very underutilized, because I think about from the perspective--

I was actually at this conference yesterday and this healthcare CIO is just like, "When are we going to have my facilities? I should be able to have data about my facilities," It takes him two weeks to run some SQL query.

I'm like "That guy just wants a report. So if you can sell software to the people that run his facilities that generates a report, like produces a Google sheet output, that guy is going to be super happy about that software."

Michael: But you want to build all the interface yourself, he just wants the job be done, which is "Take this data and get it in a format that I want."

If that's a -- You build a button to do that and then you can build a schedule on top of the button, so it sends you the email of the sheet or the link to the sheet or whatever every week. That's like 80% of the job.

Grant: Yeah. Because realistically, you're probably not going to slice and dice the data the right way for them anyway.

You just want to give them some way to get access to the data to then produce it. Now over time, I think it's important to watch what your users are doing.

Michael: That's right. You can pull that stuff in.

Grant: And you're like, "This one report seems to be the thing that people get really excited about."

Then you build that in and maybe have a little dashboard so the service is easier to your users.

Michael: Absolutely.

Grant: But I still think the value of reporting is really to let the person who is paying for your software to justify it.

Michael: You want to make them the hero.

Grant: Exactly. That's the value of reporting.

Michael: That word, "Reporting" is so loaded. When I try to think about what that means, we've thought about this a lot.

On the product side we get into a lot of the language that we use is not precise enough, so I think it's confusing.

Because you might be talking about audit logging as a type of reporting, right.

It's like, you might say "I want reporting at the access level. I want to know who logged in when. Because somebody just took over an account and there is a breach, and I need to follow them through the application and see what they accessed," and all that type of stuff.

So that's a type of reporting, then there's the data and the content in your product and the reporting around that, then there's the meta layer on top of that.

If you think about in Trello, you could say, "I want to report on how many cars moved from one list to the next list," or something like that.

It's almost meta, or "Who was visiting this board? How often have people seen this board? When's the last time they came here?"

Or like, things that might even be invisible today?

Surfacing them and reporting, but because it means so many different things a lot of times we've put it as a feature and you just say "Reporting."

It can mean 14 different features.

Grant: Yeah. My suggestion is always to put advance reporting in your enterprise plan, and then just work with your early adopter enterprise customer to figure out what they want.

To your point, that's how you guys started to figure out what the pool was on enterprise features.

Michael: Absolutely.

Grant: Work with early design partners who are excited about your product and want to use it, I think you start to see a similar set of requests.

Michael: You do. I also think, though, that sometimes you can get an enterprise customer where there just is a special snowflake, and then the problem is that the things that they want are really unique to their business.

Because you're small and they pay you money, a lot of money, your interests are aligned essentially.

You actually do all this stuff and it turns out nobody else wants that particular thing, so it's hard for you to--

Grant: It's like NRE, Non-recurring engineering.

Michael: Yeah. It's hard to back up and be like, "It's OK. I can't build this for you because it's specific to what you're doing, or I have to build in a more generic way so other people can get into it."

Grant: From my perspective, it's like you take note of what everybody wants and you spend time and you understand it, and you say, "What are you really trying to accomplish with that?"

And you dig in a little bit deeper, you try to ask "Why?" A little bit more.

Then eventually you figure out if this is a very specific--

Hopefully there's part of the other goal for Enterprise Ready, which is a common vernacular of all the different features people might be asking for.

If they're asking for some changes to the overall workflow of how your tool works, maybe that's not how you want to do it.

That's a core product decision, but if they're asking for some single sign on, unless it's some PKI system that they invented in-house.

If it's SAML, if it's Google sign in, these are pretty standard things that you should probably be doing.

But that's what we're doing, as a product owner your job is to intake all the feedback and then build the thing that the market wants.

That's the challenge of what we do. So, let's talk a little bit more about Trello now, because obviously you had a great acquisition by Atlassian.

So now, how long ago was that?

Michael: Two years.

Grant: Oh my Gosh, two years. Time flies.

So, tell us a little bit about how things are going inside Atlassian, what's been the change in terms of product or features or integration?

Michael: Yeah. There's a lot of alignment around values. Fantastic company. We just actually released a document open source, some of the M&A terms.

Grant: I saw that.

Michael: You saw it?

Grant: Really good.

Michael: But I think my one concern was founders aren't going to understand why this is such a big deal until you've been through it.

Because the problem is you go through it and you discover all this stuff and it's super opaque, you don't know what it means, you don't know if it's fair.

It's super emotionally taxing, and being on the other side where I could tell you "If you're lucky enough to go through an acquisition, this document is super helpful because it just it cuts away a lot of the crap that you might have spent time worrying about or arguing about."

It's just not important. It's a hard process because you have to do it alone.

Most of the people on your team or at your company don't know you're going through this, and sometimes-- Because sometimes these things don't work out or whatever.

Then there's a lot of data requests, and this is like six months or a year of pain trying to get through that.

But the fact that Atlassian did this is a demonstration of particularly why we did this acquisition, like the people there are awesome. I love it.

We're doing great things, we're able to do what we need to do for Trello.

If you'll look at things like the Atlassian Access, which is the SSO product I was talking about before, and I'd be like, "This is awesome."

Because it's unfair to force customers to have to pay $20 dollars a user if all they need is this thing.

We can do this across all these products and be in this one position where we could deliver this account level security, and we could still have premium packaging for our product that has product specific value."

But at this account level, it's like you don't care if it's-- It could be Slack, it could be Dropbox.

You're just like, "I just want SSO." So that's where we start to see opportunities for us to deliver value, because we're part of a bigger organization.

Grant: That's cool. I imagine that there is, back to the Fog Bugz days--

Michael: You got the word right. You got the name right. That's good. You're like, "Fog Bugz."

Grant: Yeah, nailed it.

Michael: And it's spelled with a "Z."

Grant: Yeah, I know. With a "Z." But that's a little-- I'm sure that felt a little bit interesting to be--?

Michael: That part of it, yeah.

That was super weird because from our perspective Joel and I didn't really know the founders super well, so our experience was "Wow, this is somebody just always in the same place we are--"

Grant: A thorn in your side.

Michael: Yeah, exactly. And like winning in a big way, who would've thought that bug tracking could be a $30 billion dollar business?

We're like, "Whoa." That was definitely an interesting component to it, and then meeting them and talking to them, and they're just great people.

All the Atlassians, this awesome team. I love the people I work with on the wider leadership teams, and they've done at least, I don't know, 20--

I guess in the article that we said the other day, they did like $1 billion dollars worth of acquisitions. But I feel like they've done maybe like 24 different acquisitions.

Grant: Yeah. They've really built that business from-- I think Confluence was an acquisition, right ?

Michael: I don't know. I don't think Confluence--

Maybe, maybe it was. HipChat was, BitBucket was. Then we got Ops Genie recently, JIRA Line was another thing.

They're still doing it and it's great, because it's like every time we do it we learn, we iterate, we try to make it a better experience the next time. It's cool.

Grant: Yeah. The open sourcing of an M&A term sheet is a pretty big step.

I've never seen anything like that before, I've never seen that kind of transparency.

I went through it, my first company was acquired not for a lot of money, a small acquisition. But it still took five months, and it still was--

Michael: So you know some of this stuff, the indemnity clause and all that stuff.

Grant: Yeah, and you have no idea.

Michael: "Is that a big deal, is not a big deal? Should I worry about this, am I getting screwed?"

Grant: Your lawyers half the time don't know.

Michael: And the lawyers, your lawyer is on your side and their lawyer is on their side.

So their job is to protect you, but it ends up being a lot of head butting for not a lot of business value.

You can't tell which parts are going to matter and which parts are not, so this document was just like, "Let's just tell people we're going to do, and it's fair, and everyone could see it, and then we just avoid all that."

Of course, there's still many other terms that you need to negotiate or understand in that deal, but at least you can take a lot of them off the table.

Grant: In the VC world to raise money, there's all these different terms and little tweaks that can make a big difference.

Knowing what is market, like what is the thing that this is standard in these deals?

Michael: Do you remember when the VC deals used to be--? What was the thing--?

Grant: Like preference and 2X preference?

Michael: Yes, exactly.

Grant: Participate and preferred, all these things.

Michael: No one understood it, and it wasn't until a while until the VCs were just like, "OK. We're just doing 1X, we're not going to double dip."

And everyone's like "Oh shit." If you go back in time, if you were a person that was going through that you wouldn't quite understand it until there was an exit, and then you'd be like, "Damn. They got a double dip."

Grant: "They got away with way more of my company." I think the venture hacks, if you remember-- Naval wrote that with Nivi before they started AngelList.

It was the only source of this information from a founder perspective. Like, "How do I do this?"

So that information is super valuable, because you go through those transactions like a couple times as a founder.

An M&A transaction, maybe you go through once and then you learn a bunch of lessons about--

Michael: And when do you go through it again? There's probably a lot less volume on the M&A side than there was in the investing side, obviously.

That's just a tautology I guess, if you invest in all these companies and not many of them succeed, how many get acquired is going to be a fraction of the total number invested.

So the volume there for the audience for this is probably a lot less than series C form documents.

What Y Combinator did, and stuff like that.

But I think it's cool because we put it out there and then maybe other founders will see it, like "Some other company will buy it. It won't be Atlassian buying it, but you have some other company--"

And you can point to it and say, "Look. They're doing this." I don't know, that might not have made the other companies happy.

Grant: It definitely made some corporate development people really upset.

They were like, "Why are they giving away the secrets?" I always think, I heard that "The price that you first get is half of what they hope you'll take."

That's the bit of knowledge that I was given. I was like, "That's a good way to understand how much that you might actually be potentially acquired for."

But any other things on the enterprise, go to market side, now that you're part of Atlassian? Are you seeing bigger companies that are adopting it as part of this?

Michael: There's a lot of things, like we did--

Because we were part of a bigger organization, it's much easier for us to do soc 2 type 1, soc 2 type 2, that kind of stuff. ISO 27K, just all those letters and initial things that you--

Grant: I always suggest reading the ISO 2701 spec is like 127 pages of very boring.

Michael: Yeah. You suggest for people to read that?

Grant: Yeah. of course. But it's great. It's like you read it and you realize that it's basically the playbook that every security person will ever bring, like every question that they're going to get, you're like "Yeah. I've read that. I know what the answer is."

Michael: Being part of a bigger organization is easier for that kind of stuff, because you can just lean on a whole bunch of legal people--

Grant: They know the answer, and--

Michael: They can help you lead it through. So we did all that stuff, which was awesome, because now you can put it up on the website.

GDPR was much easier. I remember-- I think you told me you read the whole GDPR thing, and I was like "Whoa, dude. That's nuts."

Grant: This is one of my secret things, I just read all the stuff that everyone's afraid of and then you realize "OK. Lay in a hammock."

Michael: It's not that bad.

Grant: It's not that bad, and I think I condensed it in that publisher version of Enterprise Ready. That was like 34 pages of normal PDF stuff.

Michael: I think like a lot of that was made easier, having the support for that stuff, because they're doing it for all the products.

You're like, "We've been through this." You might have to put systems in place for some of the soc stuff, so we had done all that stuff as part of the acquisition.

Things like HIPAA, Fed Ramp-- You start to try to figure out "What do we need to do for the--?"

All that kind of thing. When you think about the enterprise stuff, I think that's a big deal.

On the go to market side, from the sale-- I guess Atlassian, they have sales, but it's not--

Grant: They don't call it sales.

Michael: Yeah, but what do they do--?

Grant: It's not sales. It's enablement.

Michael: Yes. Certainly at the top level, at the bigger companies and the cloud companies, now we're in a position where it's like, "We can go in and we can-- You're probably already using JIRA, There's probably already people using Trello, there's probably already people using Confluence."

So from a sales position, it's a little bit easier versus--

You talk to some other enterprise founders and you could think about the case where if I go back to what I was talking about earlier, where the sales person has to go in and they have to actually sell the product.

That's the good thing about the bottom up thing, you don't have to sell the product per-se, the people are already using it.

You're not going into a company and saying, "You guys should use Trello to do stuff."

You're like, "Did you know 6,000 people at your company are using Trello to get their shit done?"

Of course, it changes the question because then they say, "So what do I need to pay for? If they're using it, great. That sounds great that everyone is using it."

But, "Do you care about the security of the content and that stuff?" Because Trello is built on collaboration, it's very easy to collaborate.

You might not want that, but if you want that then maybe you're right.

But it's probably the case that you want more visibility about this stuff, if somebody leaves the company you want to know that the data and the content stays within, it's shared with only the right people, and so that's what you build into the enterprise product.

To give the people more control over the accounts and over the content related to the accounts that people are using for work.

Grant: That was probably a direction you were already heading in when you were doing some of that before the acquisition.

So, these are things that are happening. I'm guessing that you've started to do more enablement within your side to help the teams that are not doing sales, "Sales" in the Atlassian--

Michael: They're doing sales.

Grant: But just to give them the things they need in order to when they go into some large enterprise, they can sell the whole suite.

Because one thing that I've noticed is when you talk to an enterprise, the Atlassian stack or the Atlassian suite, however you want to think about it they get pretty bought in.

They start using a lot of the different tools you guys offer.

Michael: Right, yeah. And I think the way that it's designed is you don't have to, though.

Like you can start with JIRA, you can start with Trello and you could use these two things, but then you add them on and they can layer with each other and--

Grant: It's like your phone company, where it gets cheaper when you add more services.

Michael: Yeah. It turns out that's the way it is with the access, because you only pay once and then with the SSO you're paying once.

So you add more products to it and you're actually saving money as you go across.

Grant: Yeah, it's somehow cheaper to use more.

Michael: It's interesting though, because nobody else has that concept.

There is some education around that, because then the expectation of the customer can come in and they could say, "Wait. Why do I have to pay extra for SSO?"

And you're like "No, you're not paying extra. I could take that money and tack it onto the price of the Trello package, but I'm not doing it that way. I'm pulling it out."

So it's like, how you pitch it and explain it and market it can make a big difference so that the perception is what you are trying to do.

If the perception is the opposite of what you're trying to do, you can shoot yourself in the foot with some customers.

Do you know what I'm saying? They could be like, "I thought SSO was included."

And then you're saying, "Let me explain why we're actually giving it to you cheaper and you don't have to pay for it. You could use Trello for free, for example, and you could still get the SSO."

It's just a different way of pitching it.

Grant: There's some interesting and complex pieces around having that suite. Most folks are going in selling one product.

Michael: It's a little bit simpler, and a lot of times what they're selling is a site or something, like it's a URL. Atlassian.workday.com, or Atlassian.Slack.com or something.

You go in and you just sell it, it's very simple.

As you add more of those things it's advantageous, but it also creates a little bit of a challenge of how you sell those things.

There's more conduits for the people to show up and come into your customer base, essentially.

Grant: Yeah. Because you guys have so many different products and ways for people to engage.

I'm sure that you just get spread throughout organizations, and you're probably every company with a fortune 5,000.

Michael: That's why I tell-- When the other people are going to talk to a customer, I'm like "Just tell me who it is because I can tell you how many--"

Just so you know, so you're in in the conversation, tell me what the domain is so that you know.

You could be like, "Did you know you had 4,000 people using Trello?" Because a lot of times they don't.

Grant: Yeah, and then they're like, "I wonder what we should do about that." That's great.

Michael, I really appreciate you being here. I wish we had more time.

I could probably talk to you and ask a million more questions about your early days at Fog Creek all the way through to everything you've done.

We barely tapped into any of the stuff you did at Stack Overflow, where I'm sure there's some great lessons there too.

But this has been great, I really appreciate all of your time.

Michael: Thanks for having me, I'll come back for part two later.

Grant: Perfect, I'd love that.