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.
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.
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
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,
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
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
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.
Michael: Very common, like LogMeIn and GoToMyPC.
But this was before that.
Grant: What was it called?
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
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
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
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
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
Michael: You have to write it down, make sure you write it down and tell someone else to
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
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
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
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.
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.
Michael: Because we realized we actually did need to build a giant--
We needed to get there first if we wanted to build these
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--?
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.
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.
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
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
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
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.
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
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.
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.
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
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
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
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 can have even more than two axes, if
you look at Intercom they have made three
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
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
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.
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
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
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
You have to sell them the product,
because they're not currently using it, so you have to find the problem that
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
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
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.
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.
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
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
Grant: OK, so you initially-- You didn't really
have a business offering, per
Michael: We had Trello which had some admin controls over your team,
but when we were thinking about enterprise these were the
This isn't 10 to 50 people, this is like 50 to
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
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
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."
Grant: Versus you think about Google, it's like
company or account-centric.
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.
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
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
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
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.
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
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
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,
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
what's been the change in terms of product or features or
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
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
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
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?
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.
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?"
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
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.
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
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.
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--
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
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.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."
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.