What's up, everyone? This is Cortland from IndieHackers.com and you're listening to
the IndieHackers podcast. On this show, I talked to the founders of profitable internet
businesses and I try to get a sense of what it's like to be in their shoes. How did they
get to where they are today? How did they make decisions both at their companies and
in their personal lives? And what exactly makes their businesses tick?
And the goal here, as always, is so that the rest of us can learn from their examples and
go on to build our own successful internet businesses.
Joining me today is Chad Pytel, CEO of Thoughtbot. In addition to being an entrepreneur, Chad
is a designer and a developer himself, which is appropriate because Thoughtbot is a design
and development consultancy. Chad started Thoughtbot in 2003 with a small team of five
people and today he's grown that into a team of 100 people in six cities and they are on
track to cross $20 million in annual revenue this year, which is insane.
So Chad, I'm super excited to have you here. Got so much to talk about and thank you for
coming on the show.
Oh, thanks for having me. I appreciate it.
So tell us a little bit about how Thoughtbot works. I guess it's somewhat self-explanatory,
you're a consultancy, but what do you guys do, who are your customers and how do you
make money?
So we specialize in creating products that people love to use. And so the majority of
what we do is help people go from that first concept that either a brand new startup has
or a much larger company wanting to do something new and refining that concept and then rapidly
designing and developing it and bringing it to market.
So almost everything we do launches the first version within 12 weeks and we go on to iterate
from there. For startups, that typically involves raising a larger funding round at that point
and building a team of their own. And we work alongside of that team, training them in how
we work and what we've done and then backing away when they're ready. For more established
companies, that typically means bringing it in-house at that point and doing the same
thing.
So that's great. You guys specialize in building products that are actually good.
Yes.
Products that people want to use, which is great because we've got a ton of people listening
in who have ideas or maybe don't and want to learn how to build products that people
actually want to use. You are technically, I think, a first-time founder because Thoughtbot
is your first company, but you've been working on it for 15 years. During that time, I can
imagine that you have taken hundreds of products from Idea to Launch and that's a pretty cool
perspective to have. You've seen a lot more than most people, so you're not really a first-time
founder.
What are some of the bigger lessons that you think you've learned as a result of having
such a broad perspective and seeing so many different products?
The biggest one is it's really surprising how few people actually really talk to customers
before they start building their product and figuring out what it really is. People spend
a lot of time making mockups and wireframes and written documents that describe how it's
going to work and what it's going to do.
The fun part.
But they don't actually talk to people who would be their customers. We talk to a lot
of people when we first talk to them. We say, this is all great, but have you heard this
assumption you're making or that this pain point, where did you get that from? Who told
you that? It's often coming from them and their own mind rather than getting it validated
by talking to real customers.
When I think of a consultancy, I think of a company that's just going to build whatever
I want regardless of whether it's a good idea or not. How did you guys get to the point
where you were actually advising people, hey, you need to talk to your customers and here's
how to build a product that's going to work versus we're just going to be the hired guns
and build whatever you want?
We've never wanted to do that. As a designer and a developer myself, I'm not interested
in working on things that aren't going to be successful. Life is too short to be working
on things that aren't going to be successful.
It's the approach that we've had from the beginning is to really try to make sure that
we aren't just building whatever someone tells us to build. That's why we've been an integrated
design and development company from the start because if we were just doing development
and a lot of companies out there just do outsourced development, you're not involved early enough
in the decision-making process and in figuring out what the product is going to be in order
to have the effect that you want and to be in the conversation early enough.
We believe inherently in integrated design and development teams and that's reflected
also in wanting to have a seat at the table as early as possible so that we don't get
in a position of just building whatever someone tells us to build.
Got to tell you, man, I am a designer and a developer myself and I've built a lot of
stuff that nobody ever used and no one ever cared about.
Let's talk about the early days of Thoughtbot. Why did you start this company?
The reality is I've been freelancing web design and development since 1995. Full disclosure,
I was in high school then. I got really early on with the web. It was a pretty exciting
time and got a lot of opportunity to do some pretty cool things early on. This was when
most companies were building their first website.
I went to school and decided to go for CS and graduated in 2002. I went into school
thinking it's the height of the dot-com bubble. We're going into CS. I'm going to have an
amazing job. I'm going to move to San Francisco and get an amazing job, work at pets.com or
something like that.
What happened while we were in school was September 11th happened. A huge impact on
the economy. Before that, the dot-com bubble burst. I went into school thinking I was going
to have no problem finding a job. Like me, a lot of my peers, we graduated into a very
different scenario.
I fell back on the freelancing that I had done. One of the people that I had worked
with previously said, I know this person. We're working on something new. He's a little
out there, but maybe you should go talk to him.
I met with him. He was an attorney. He explained he had fought insurance companies and won.
He was creating new medical billing software, online software to do medical billing to help
doctors get paid. That personally is an issue that I care a lot about. He convinced me to
join the team. We needed to build a team. I hired a few of the friends that I had graduated
college with who were all looking for work and who I had worked with before. We got started.
What we found pretty quickly was that it wasn't what it seemed. The biggest trigger was ultimately
we found out that he had a personality disorder. The investment that he said that he had, what
we were doing, it wasn't really there in the way that we thought it was. We stopped getting
paid after about six months because the money wasn't actually there. Then things started
to crumble pretty quickly from that. We all loved working together. Having been through
that sort of process, we were regularly working 70 or 80 hours a week. My normal schedule
was to come in in the morning at about 6.30 in the morning and leave at 10 or 11 at night.
I was really burnt out after having worked so hard for something that was a fairly toxic
environment that just evaporated overnight. I didn't feel like going and doing job interviews
and that kind of thing. We all liked working together. I spell back again on that freelance
web design and development that I had done previously and said, we like working together.
Maybe I can make some phone calls and get some clients. We thought up a name and that
was Thoughtbot. That's how we got started. We were five friends who went to school together,
who worked together for the first six months out of school and out of the ashes of that,
we created Thoughtbot.
It would have been easy for you to just go get another job elsewhere. I think that's
a decision that most people would have made. What do you think it is about you that gave
you the idea and your coworkers idea to start something on your own and take that kind of
a risk?
That's a really good question. I do know that the first thing was just that feeling of,
I don't want to go do a job interview and have to talk about what I spent the last eight
months doing. I was just burnt out and didn't want to talk about it. That was definitely
a motivator. Because I had done a lot of freelancing before, that seemed like the easier path.
Then coupled with wanting to continue to work together, I think you put those three things
together and we said, well, we've got nothing to lose. Let's give it a shot. I just picked
up the phone and started to make some phone calls.
I think if we hadn't gotten anything from those original phone calls, we probably would
have said, yeah, okay, it's not working. But we did. We got some first clients and that
kept the momentum up to keep things going, even in that uncertainty or that risk.
These are things that I hear from a lot of entrepreneurs. Number one, a total lack of
desire to go interview somewhere else, albeit for probably different reasons than you had.
The desire to work with particular people or on particular things that you really want
to work on or work with. Also, I guess having a really strong fallback, knowing that even
if things don't work out, you can just go get a job. You'd freelance before and you
can make it work. It just makes it much easier to take that leap. This is 2003. Has the process
in your mind changed what it might look like today for somebody who wants to get started
with a consulting shop? How did you guys actually go about making those phone calls and getting
your first customers?
The process is definitely... In terms of starting a web and mobile design and development company,
it's very different now than it was then. 2003 is before Facebook came out. Web applications
were not something that everyone used or was aware of. It was a long time ago. Mobile didn't
exist in its current form at all, and it wouldn't be another four years until it did.
The ecosystem of technology and what we were doing at the time was very different. The
funny thing is that it's more like it was now. It's more like it was then, and I'll
tell you why. When we started, there was no clear winner up for technology. There was
lots of different options. You could use PHP or Perl or Java. You could choose lots of
different things, and there was no particular reason why you might choose one of them over
the other. We got started in that environment, and we did lots of different things for lots
of different people.
Then what happened several years later in the industry, especially for us, we were the
first consulting company in the world to switch to Ruby on Rails when it hit 1.0. In the context
of Rails hitting 1.0, Web 2.0 happened. Ajax, asynchronous websites using JavaScript became
a thing. That was a thing that was invented at that time.
What happened when that happened is Web 2.0 happened, and there was a strong consolidation
around what technologies we were using, but also the communities in general were using
in terms of prototype and then jQuery on the JavaScript side. On the server side, there
was a real point in time where most startups that were getting started were using Ruby
on Rails, were choosing Ruby and Rails.
We're now back to an environment where there isn't one clear technology choice for a lot
of things. There's lots of different things. Node is very popular, but there are lots of
other options out there for both front-end and back-end development. Even mobile development,
which was consolidated for a little while, is more between React Native and Objective-C
and Swift and Kotlin and Java. There are lots of different technology choices, even on the
main two technology platforms.
We're back to an area where things are less consolidated. As someone getting started today,
you really need to be careful that you don't become everything to everybody, and you don't
use every different thing for every different purpose. The problem, and this applies to
non-consulting businesses as well, and this is why it's an important lesson for Thoughtbot
and for lots of people, is when you're everything to everybody, you're nothing to everybody.
You don't stand for something. Customers don't know why they would work with you or why they
would buy you if your clear job to be done, if your clear purpose is not laid out for
customers to understand and appreciate and decide, I want to buy that and to seek it
out and to say, I need this product. I have this pain point, and therefore, I'm going
to seek out a product or service that's going to solve it.
We're back to being in that ecosystem that's very diverse, and so it's really important
for companies today, whether you're a product company in the general marketplace or you're
a technology consulting company and design and development company, that you understand
what it is you do and why you do it, and you clearly communicate that to customers. That
was the biggest mistake that we made early on is we didn't do that because when I picked
up the phone and started making those first phone calls, I was desperate. I would call
someone I had built their website for previously, and they would say, hey, great to hear from
you again. I would say, I'm back to doing websites and that kind of thing. Do you need
help? They would say, well, we don't really need help with our website, but we need help
with this computer that's giving us trouble. You're a computer guy, right? Would you help
with that? We were desperate. We said, yeah, okay. We can help with that. We put a fancy
name on it. We said, okay, we're going to be a full-service IT consulting company. We're
going to be for small and medium-sized businesses. We'll do their website. We'll build software
and internal systems, but we'll also sell computers and provide technical support. We'll
do everything a small and medium-sized business needs. Well, there was no reason why people
would work with us at that point. There are way too many other full-service IT consulting
companies. There are way too many other companies that they could call that would be a little
bit more specialized than we were, a little bit more established, a little bit cheaper.
All of these things, we were lost in the sea of competition. This really, again, it applies
to every kind of business, not just consulting.
It's funny to hear you talk about your experience as a consulting shop because they're kind
of mirroring my experiences as an individual developer. Probably the 90s was the decade
where all sorts of people asked me if I could fix their computer and I would say no. Then
the early 2000s is when everybody wanted a website and I said no. Then the late 2000s,
everybody wanted a Rails app and I would tell my friends and family no. It sounds like you
guys weren't saying no, but eventually you learned how to.
Another thing that stands out to me in your story is that you started with five co-founders.
There were five of you who started Thoughtbot. That's a ton of people. I've had trouble
finding alignment working on businesses with just two of us. How did you guys make it work
or did you even make it work with five of you at the beginning?
Overall, we made it work because we enjoyed working with each other and we had worked
together before. That momentum carried itself forward in the early days and we fell into
the grooves that we normally had. We had already normalized how we worked together.
But the problems we faced, there were two big problems starting with five people in
that scenario. The first was on day one, we needed to support five people, yet we had
no savings. We had all just worked for free because we weren't getting paid for a few
months while we kept being promised that we were going to get paid. Starting on day one,
needing to make enough money to support five people was a real challenge. If we weren't
young, right out of school with not a lot of obligations, that would have been really
difficult to do. It was difficult to do anyway, but it would have been even harder.
That was the first challenge is just financially supporting all of us, bootstrapping our work.
That was really difficult and it didn't fully resolve itself until three of the original
founders decided to leave. The other challenge that we had early on was starting with five
people is what I alluded to about falling into the norms. The norms were good because
we knew how we worked together and that kind of thing, but we made the mistake of not having
honest conversations about what each of our roles were going to be and what each of our
contributions to the business were going to be.
If I think back, in every instance where we had worked together before, I was in a leadership
role. That's what everyone looked to me for. I went into Thapa saying, yeah, I'm CEO, but
we're a team and we're doing this together and we're all going to be equal partners.
I'm looking for you to be part of the leadership team of the company. I think in retrospect,
that wasn't their expectation and we never talked about it really before we got started.
In retrospect, it was a mistake to go into it, never having that conversation and to
say, we're going to be equal partners. That was naive of us. It would have been a lot
better had we just had an honest conversation.
It's possible that if we had had that, we would have been more successful, but ultimately,
maybe people would have stuck around. The original founders would have stuck around
longer because the expectations were set. When the three founders, we weren't very successful
because we were doing everything for everybody. We weren't very successful when the original
founders, three of the original founders decided that they were just going to go get jobs and
move on. That was the first important turning point for the company. It's when Thapa really
became Thapa.
I know a lot of therapists and being in a co-founder relationship is in a lot of ways
very similar to being in a romantic relationship. Rule of thumb number one is to communicate
things. When you don't do that, things tend to fall apart pretty quickly. Small problems
are sort of the big Harrier problems down the road, so it's pretty crucial.
I'm curious about the emotional impact of having three out of your five initial founders
leave because that's a pretty easy point to just pack it up and call it quits yourself.
What were you feeling when that happened?
It was a weird thing because I totally could have seen that we could have just walked away
at that point. We weren't very successful. Our friends were just showing us we could
walk away. We ended their involvement very amicably, but it wasn't expensive. We weren't
successful, so it didn't need to be complicated or expensive, and everyone was very reasonable.
They showed us we could just go get jobs. I don't truly know, and I can't really chalk
it up to anything other than there has to be some amount of grit and determination going
on to have lasted 15 years so far, especially in this business with all of its ups and downs.
I sort of point to that and say, I think that I'm just stubborn. Instead of reacting to
that situation and saying, I guess we're just going to move on, that led to a doubling down
where we said, John and I, who are the two founders that decided to stick with it, that
act of needing to consciously decide to stick with it, we consciously said, this isn't worth
doing if we're not successful and doing the kinds of things that we want to do in the
way that we believe they should be done.
We literally took out a piece of paper and we wrote a list of the things related to design
and development that we believed. We said that we were going to start saying no to anything
that didn't match that list. Being put in a position where we had nothing to lose because
we weren't successful and being determined to do it really had a dramatic impact on our
success. When we started saying no to people, it's not that we were actively turning down
people that was important, it was that the people who believed what we believed could
then find us. One of the things on that list was test-driven development, just for example.
At the time in 2005, test-driven development was not a respected, established development
practice. It was on the fringes. There were some people who actively went against it and
there were some people who believed in it. By saying that we believed in it, we became
part of the niche of people that wanted to work that way. Clients who understood what
they wanted and that they wanted that could then find us. Team members, it became easier
to hire. We had people leaving their companies to come join us because they wanted to use
Rails and they wanted to do test-driven development. We were one of the only companies that would
allow them to do that. On both sides, customer and team sides, being clear about what we
believed and how we worked and what we wanted to do was essential to that turning point
when Thapat became Thapat.
It's crazy. You're talking about not trying to be everything to everyone. When you're
in the dire straits that every early-stage company is in, when you're trying to pay
your bills next month, it can be hard to turn people down, but it has the effect of actually
increasing your business and making it more clear what you want to do and also bringing
you better customers.
One of those counterintuitive things that it's difficult to pull the trigger on.
It's difficult and to bring it back to the question you asked in the beginning about
the mistake I see a lot of people make when they're building a product. It's not talking
to customers, but then when you start talking to customers, they're going to tell you lots
of different things.
Another common mistake I see when we're working with people is that they will talk to one
customer who tells them one thing and we'll have talked to a lot of customers that tell
us one thing, but then they talk to another customer who's willing to pay them and they
say something slightly different and then that gets added to the list.
It's like, oh, we got to do this. We're really focused on what the smallest possible thing
is that we can build to bring it to market. We will get to that thing eventually if it's
actually important, but it raises in importance because they're continually chasing what they
think they need to do in order to get that first customer.
You end up bouncing around between all the different people that you talk to. It's important
to be judicious about not just hearing one person, but hearing the multitude of voices
and really driving to the core job to be done of what your product or service actually does
for people and staying true to that.
That's sage advice. Your customers are not going to be able to tell you exactly how to
build your business. Talking to them is crucial, but you're the founder and you still have
to be able to piece together all of those pieces of information and figure out what
to do.
You and your remaining co-founder came up with this list of things that you guys were
going to stick to. I'm sure at the time you didn't imagine growing your consultancy to
$20 million in revenue. Did you have to change your list a lot to get to this point that
you're at today? If not, what are some of the bigger things on your list that enabled
you guys to grow so large and be so successful at what you do?
The list has changed a lot, the actual things on the list, but actually it was a very conscious
point at which they changed because the first list that we created was all very tactical,
specific things like Ruby on Rails, like test-driven development, like sustainable pace. Those
are practices or principles, they aren't values. After several years, we actually did a major
revision of that list where we said, what's important to us about test-driven development
that led us to choose that in the first place? That was very valuable to us as a company
and as a team at the time, but it turns out it was also important to levering up the success
of the company because test-driven development is no longer special. It's no longer a differentiator.
In that sense, we sort of won. If we continually just focused on that as a differentiator,
it wouldn't be true and it wouldn't be something that we would miss out as designers and developers
around the next thing that's new that we love to do and that makes us fulfilled in our work
and helps us build better products. It was important to identify the core value that
led us to do test-driven development in the first place. That let us move on from that
and say, what's the next thing? Or more importantly, what do we believe as a company that customers
will then come to or that we can communicate to customers? If we hadn't done that, we would
have been left behind. The longevity and the growth that we've had comes from that major
revision that we did where we converted our practices into values.
I want to hear a little bit about this period in between. You guys becoming two founders
and you guys eventually switching over your values and hitting, I don't know how to refer
to it, maybe a growth spurt in the size of your company because I know that there was
a period of time where you were significantly fewer than 100 employees and you were pretty
happy with that.
From 2005 to 2012, we were no more than 20 people. That was very intentional. We have
very high standards for the kind of company we are, the kind of work we do. We don't really
have people who are... We don't have professional salespeople. We want to have relationships
directly with the founders and the companies that we work with as designers and developers.
We have really strong beliefs about how companies work and wanting to not have a lot of corporate
overhead and BS. We were very afraid around growing larger than that 20 person number
and what it might do to the company.
In 2012, two things happened. We were coming up on our 10 year anniversary and 10 years
is a long time. Psychologically, it was this important milestone in my mind that we were
coming up to. I started to think about the impact that we had had on the world. We had
a global reputation and we had made major contributions to open source and those kinds
of things.
What truly makes Thapa special in my mind and the mind of the people who work here and
work with us is the way that we work. We believe we have a better way of working. We are trying
to share that with as many people as possible. When we were holding the company to 20 people,
it was holding us back from achieving that full potential. I remember the day that someone
stood up in a company meeting and said, if we really believe we have a better place to
work and a better place to work with, why are we not trying to bring that to more people?
I realized I was holding us back from achieving that because I was afraid of what we might
become. That was the first aspect of that.
The second aspect that triggered the growth was that we lost people. We were working all
together in Boston. We went through a brief period of time where some of us were working
remotely, but we weren't set up as a remote company. We went through that period of time
and then we moved back to Boston because it was mediocre because we weren't really set
up to be remote. We said, you know what? We're just going to have a small team of people
based in Boston. We went through a year. We weren't that big. We were, I think, 17 people
at the time and we lost three people. The only reason why they left was because they
wanted to live somewhere else. It had happened the year before too and the year before that.
We reached the breaking point where we said, we're losing people. When someone would ask
to have a meeting with me and they would start the meeting being thoughtbot is the best place
I've ever worked and I don't want to leave, but I knew that bot was coming. They had to
for life reasons, for desire to live somewhere else, that kind of thing.
We wanted to try to find a different way of growth and reconcile the fact that we were
afraid of being bigger. We had done partial remote and we felt like it was mediocre. How
could we reconcile all of those different things? That was when we hit upon the idea
of, you know what? We know exactly what a four person, eight person, 20 person thoughtbot
looks like. It's great. Instead of thinking about how can we possibly be 50 or 100 people
and not compromise, and instead of thinking about this hybrid remote team being mediocre,
maybe we could replicate what we have with thoughtbot to other cities.
The next time someone wants to move, say, you know what? That's going to be great, but
we've been through the partial remote thing. Let's not do that again. Let's build a studio
around you when you move. There's probably people and clients in that new city that want
to work with thoughtbot that haven't been able to do that before. We're going to bring
it to them and we're going to grow geographically that way.
The idea has been to try to have the best of both worlds where every day when you come
to work as a designer and developer, you're working with one customer. You're working
with a small team of people that you know and have worked with before and who you trust.
You're creating a product that people love to use, but that you're part of something
bigger and that is the thoughtbot overall, the movement, the impact, the hundreds of
clients that we work with a year now to have that impact all over.
You feel like you're part of something bigger without having to compromise and actually
in your day-to-day have the downsides of being part of something bigger. I think not everything
is perfect, but I think we've struck that balance really well. Once we started down
that path, we went from 20 people in 2012 to 100 people now in 2019. The growth has
been pretty dramatic pretty quickly for us.
That's so cool. You're basically taking these small teams and just copy-pasting them into
other cities and other locations and that's the way that you're scaling your business.
That sounds really intriguing to me. If I wanted to build a bigger business, I think
that would be the way I would want to do it. What are some of the roadblocks that you've
run into doing it that way? It sounds like in a lot of ways you're blazing a new trail.
I haven't heard of that many other people doing things the way that you guys have.
The biggest roadblock we ran into was that the majority of the studios were started by
someone who already worked at Thoughtbot. We don't have business development people really.
It was a designer or a developer starting that studio. In my background as a designer
or developer, I was comfortable doing business development and I had a knack for it. I took
for granted how easy it would be for someone else. At Thoughtbot, we're great communicators.
We like people. We're not the typical developers who go away in a dark room and don't want
to talk to people. That's not who we are. We had the belief that anybody who was a good
fit for Thoughtbot would be able to do that. We also had this archetype of what Thoughtbot
was, which was led by one person, which was me. That led us to think that anyone at Thoughtbot
could start a studio and that those studios could be successfully led and managed and
all the business development and that kind of thing happened by one person.
That didn't work, but even worse, what happened was we were led astray because when we opened
in a new city, we got a bunch of customers right away. What we thought was, oh, this
is great. This is going to be super successful. What we didn't realize was we were getting
the low hanging fruit. After year one was great, year two was less great, year three
in the new studios was terrible. What we then realized was we hadn't actually been doing
the work of business development to build a sustainable pipeline of local work. We were
only getting the people who were already our fans, who were already waiting to work with
us when we moved into a new city. What we also found was that the actual amount of work
necessary to build a sustainable studio was more work than one person could reasonably
do, particularly if they were just someone who randomly wanted to move to a new city
and didn't necessarily understand or want or have the capacity to do everything that
was required to actually build a successful, sustainable thoughtbot studio.
We had to close a few studios once we realized that because we had lost a lot of money and
we were really in danger of going out of business overall. We restructured the expectations around
the leadership of a studio. We now have three leaders in each studio, a design director,
a development director, and a managing director. That managing director is typically a designer
or developer, but they're the one that's responsible for the business of the studio while the design
director and development director lead the design and development teams respectively.
That structure is working really well for us now, but it was a big change. Like I said,
shut down some studios was super difficult. We lost some people along the way in addition
to shutting down those studios just because of realizing the changes that we needed to
make in order to get things to work more sustainably over the long term.
It sounds really difficult on one hand, but it also sounds really fun to try to figure
out how to make this model work, to do trial and error, to teach people the things that
you knew about opening up a new studio and building a sustainable business there. What
do you enjoy the most about running Thoughtbot as the founder?
Working with the people here. I think if you ask that question of anybody, like what do
you enjoy most about being a designer or what do you enjoy most about being a developer
at Thoughtbot? It's working with the people here. I really like my role because I get
to work with people all over the world doing interesting things and helping them bring
Thoughtbot to more people, but more importantly, working with customers to bring their ideas
to life. For the individual designer or developer, we've achieved what we wanted to achieve when
we started on this path of growth, which was they're part of something bigger, but they're
having an impact for the product that they're working on in a way that doesn't feel like
you're part of some big machine, but I'm sitting in a position where I can see it all.
That's really exciting. The impact that we have and the size that we're at now, we work
with companies that we would have never worked with before. We work with companies that are
really big, Fortune 500, Fortune 50 companies who want to do something new and know that
they want to get outside their walls to do it. To be able to work with those brand new
startup founders creating their first version of an idea at the same time as working with
Intel or Harry's or Etsy or Kickstarter and to be able to help them do new things or to
improve their product and to see all of that going on is really exciting to me.
I talk to a lot of founders, especially developers who want to build a quote unquote scalable
SaaS business. They want to code something once and then have thousands of people pay
for it. You're building something that, while I won't say it's not scalable, it's definitely
not scalable in the same way. Like you said, you have to work with all these different
clients. If you want to take on more projects, you've got to hire more people. Do you think
people who are sort of obsessed with this idea of building something scalable are in
the wrong? Are they missing something? What do you think is the difference between building
something that you're doing and building something that's a little bit more scalable on the product
side of things?
I definitely don't think that there's anything wrong with that. I totally see the flip side.
When I look at our revenue graphs of what the next two, three, four months look like,
it looks scary. It looks terrible, but it always has. For 15 years, that's the way it
is.
You have to be very comfortable living in a world where you have the people and the processes
in place to know that over the next one, two, three months, that is going to fill in, and
then you're going to have to do it again. Whereas when you have a SaaS business with
recurring revenue, your graph looks very different. Your numbers are smaller, but there's consistency
to that. You can calculate lifetime value and all those kinds of things, and you can
see it happening. We can calculate lifetime value too, but when you look at the graph
of ongoing revenue, it really drops off. You have to be comfortable in an environment,
and you have to be comfortable always selling.
When we sell as a team, we're not just selling for growth. We're selling to not go out of
business in four months, because if we don't sell today, we have no revenue then, particularly
the kinds of projects we work on, which are building the first version of a product and
then doing it within 12 weeks. Most of our engagements last four to six months. You start
looking out that long, and we have very little revenue. I should say, I do envy the benefits
of that scalable SaaS recurring revenue business. At Thoughtbot, we have created some of our
own of those out of the work that we've done and what we've learned and tools for ourselves.
It's been really exciting to run that kind of business and to focus on a different kind
of growth and a different kind of sales. Having seen both sides of it, it's exciting and it's
tiring to be on my side of it. That's where grit and determination and being willing to
stick with it is important for no matter what kind of business you have, because you're
going to have different challenges for every kind of business that you have. Being able
to work through them and not give up when they happen is critical to longevity.
You mentioned that you guys have worked on your own scalable SaaS products, which I think
is super fascinating because you have such a broad perspective on what other people are
doing. You've gotten to launch so many things that you've probably learned a lot and transferred
some of those learnings into your own products. Yet, you're still a consultancy. You haven't
decided to go full time on any of those things, which must mean that there are some advantages
to being a consultancy, some things that you really like about it. What's the flip side
of the coin? What do you like more about being a consultancy than running one of these more
scalable product businesses?
I'll be honest with you. I think that if you actually look at it, if we had created a product
when we were smaller that we worked on and then it became huge, we probably would have
given up consulting. We love consulting and we're good at it, but had we gotten lucky
with any of the products that we created, like really lucky, we wouldn't have necessarily
given that up to still do consulting for the love of it.
That's the most honest answer I can give. There comes a point with a consulting company
where you say, we've got a really successful business here. Why are we trying to create
other ones? We love this, we're good at it, and we're successful. Let's instead focus
on making that even better and more successful. We can create products of our own that come
out of our design and development work, but it's a different skill set. It's a different
business to successfully grow a SaaS-based business. When some of our products got to
that point where they would require significant investment or time and attention to continue
to grow past the 10 to 25K and MRR, we decided to sell them or spin them out.
Talk me through one of those stories. What's a product that you guys have successfully
created in-house and grown the 20 to 25K MRR?
The first successful one was a product called HopToad. It's now called Airbreak. The product
still exists. We created HopToad, which is an exception catching service. It was technically
pretty much the first one of these, where you embed your plugin in your app, you embed
the HopToad plugin in your app or the Airbreak plugin in your app, and whenever an exception
happens, it sends it to the service. Nowadays, there's a lot of these different services,
but these didn't exist when we first created HopToad. Everyone was using email notifications,
so you would get 10,000 email notifications if an exception happened 10,000 times. That
was the pain point that caused us to say, hey, you know what? We might be able to create
a service that receives these and aggregates them instead of getting an individual notification
for each error.
We created HopToad, and shortly after another one launched called Exceptional. We created
HopToad for ourselves and made it available to everybody. We did that for free. It was
a free product and it had no paid plans. It solved a real pain point at the time for designers
and developers, and it was the only product of its kind. I'm trying to remember the exact
growth pattern, but very quickly, we got to about 10,000 users. I believe it was about
30 to 45 days after our initial launch, we rolled out paid plans, but we were so scared
about turning all of those users off of the service that we made the mistake of grandfathering
everyone who was on a free plan into their free plan and only adding the paid plans if
you wanted to upgrade.
The only upgrade we had when we rolled out the paid plans was you could enable SSL on
your account, and that was the paid feature that you were getting. We were running a service
that had a very small number of paying users and tens of thousands of free users. The nature
of that service is we were receiving all of that traffic from everyone's exception. It
was particularly bad if someone was being DDoSed or if a major internet outage was happening.
Thousands of websites would start sending their errors all at the same time as a major
error was already happening on the internet. We created a product that would DDoS itself.
You created a business that's not very fun to run.
We spent an enormous amount of time every week just trying to keep the service online.
We had such good intentions, we would meet for our weekly planning meeting and we'd say,
we're going to roll out this new feature and we're going to do this. Then the two people
we had on at full time would spend all week just putting out scaling fires.
That was really frustrating for us and for the team. We spent a lot of time and effort
also trying to roll out new paid features to entice the free people who were grandfathered
in to switch to a paid plan. We weren't having a lot of luck there. We got a significant
number that we got the service to about $25,000 in monthly recurring revenue. This was back
in 2007, 2008. It's pretty good, but it was very clear to us what was going to be required
to continue to scale the service and to both on the technical side and the team side and
the investment side, but also on the product side, it was very clear that we needed a way
to convert more of these paid plan, free plans to paid. We just weren't willing to do the
hard thing that needed to be done, which was to stop grandfathering them in and to send
out a notice and say, we're going to need you to start paying for this.
When we all looked, we were starting to think these things and the other service that had
launched a few months after us was called Exceptional. We knew the people who ran Exceptional.
They were also a Rails web development company based in Dublin. They sent us an email and
said, we just talked to somebody and I'm assuming I can tell this story now, but we've decided
to sell Exceptional and they want to talk to you too. We talked and we were feeling
all these things. We came together and we decided it was the best thing for us and the
product to also sell to them. They did that. They improved both products. They combined
them. They did the hard things that needed to be done that we weren't willing to do in
terms of raising the prices and converting people off of the free plans. They went on
to sell that product, Exceptional and Airbreak and a lot of other things to Rackspace. Very
successful for them, really successful for us. Particularly because we got to see the
product move on and because we weren't willing to do it. It made a lot of sense for us. That's
the story of just one of the products that we've gone on to build and grow to about that
level of revenue and then sell. That works really well for us.
How many products have you guys done something similar with?
We've built in total about 10 products. There wasn't a market to sell. We ended up shutting
it down. Some of those we open sourced because the few customers that were using it, we wanted
to make a commitment to them and we believe in open source. We open sourced the products.
We've sold four products, four of the 10 products over the years.
It's interesting listening to this story about Hop Toad because working on your own products,
you just get all sorts of stuff that you probably don't get when you're building products for
others. I've experienced this doing my own consulting versus being a founder. When you're
working on someone else's product, you get a certain level of objectivity. You lack some
of the emotional attachment. You can make some of the harder decisions. What have you
found as being the most significant differences between building products for other people
versus building your own products? You think it's easier to make better decisions when
you're building products for other people?
It definitely is. I think that if you pointing that out, I think is the thing that is the
biggest difference. I care about the things that we work on when we're working as a client.
The team cares deeply, but we understand that we were hired to make something successful.
If we see you doing something that we truly believe is not in the best interest of the
product or the customers, that's what we're there for. Then you put the same people ourselves
in the shoes of the product owner and we start making the same mistakes our clients do.
There's definite benefit to having that or that's a big difference.
What are some of these mistakes that we as founders tend to make because we can't get
out of our own heads because we're too close to what we're building?
The biggest one is overbuilding. Thinking that we can't launch without this feature.
We just can't. We do the same thing when we're working on our own products too. We think
something's going to launch in a few weeks and then it's a few weeks later and it still
hasn't launched and it's because we don't have this feature in that is really important.
The reality is it's really not important and we have talked to people. We have a prototype
oftentimes where we've validated it and we've shown it's just not important to the success.
It's not going to make or break whether people use the product and pay for it. We can launch
now without that and we can add it really quickly after.
It's so common to want to delay, delay, delay, delay until you have all of that stuff in
perfect. Because you believe that it's essential. We can't launch without this feature. In reality,
that's not the way it is.
Having built so many products for so many different people, building your own products
as well, I'm sure you have some sort of playbook by now and I'm curious what some of the secret
sauce is. Are there any things that you guys believe about creating products that others
typically don't, that you don't see written up online everywhere that goes into your process
for being able to build so many things at such a high quality and get them out the door
so quickly?
I think I touched on the biggest thing before where I just said in passing that we believe
in an integrated design and development team. What that means is designers at Thoughtbot
do great visual design and research and user experience. They're also visual designers,
project designers. They also are front end developers so they implement their work. Developers
at Thoughtbot care about usability and user experience. They're involved in the design
of the product, which means how it works. Then they meet the designer in the front end
and they do everything back from there.
On our teams, we really only have two roles, designer and developer. Designer isn't traditional.
It's that full stack designer implementing their own work. Those two people working together
directly with a founder or a stakeholder is a really, really powerful combination. That's
our secret sauce. If there's one thing that affects the way that we work, the speed at
which we're able to create products, it's those two roles and working directly with
each other. We don't have project managers. I think if a startup company was coming to
me and they said our founding team is a salesperson or a business development person, a developer
and a project manager. A project manager doesn't have a traditional project manager, doesn't
have a place on a startup team.
The three roles that you need are the visionary, the designer and the developer. Those are
the three roles that you need. The visionary, the founder, the CEO should be playing the
role of project manager or product manager in the early days of a company. If a company
that we work with, the founder is not equipped to do that, we see it is our responsibility
to train them to be a product manager for their product. Founder, designer, developer
or stakeholder, designer, developer working together to realize the vision of the first
version of the product as quickly as possible, get it in the hands of users and then iterate
from there. That's really powerful.
A lot of other consulting companies, a lot of other founding teams make the mistake of
introducing people in between all of those different roles. The more people you have,
the slower you go, the less iterative you can be, the less agile you can be. It becomes
harder to make changes and harder to adjust. Communication becomes an issue, overhead becomes
an issue. You need to start doing things like story points and planning velocity and tracking
velocity and all that stuff because things have a tendency to get bogged down. We avoid
that by having a really small team of people who are all actually doing things.
You talked about 10 years of thoughtbot being sort of a midlife crisis for you guys. You
just passed 15 years now and before we know it, it'll be 20. Your company has changed
a lot. Your role has changed a lot. I'm curious if you see any crossroads, midlife crises
coming up for you again in the future and while you're still a founder today, when those
reasons are certainly different than they were in the beginning.
I actually had the second crisis and I think the problem or the worry I have is we had
it at like 15 years. We have a half-life to our crises, which doesn't make me too happy.
But what happened at 15 years was we had grown a lot and I was feeling like a lot of what
we had done, we were in danger if we continued to grow of losing what made Thoughtbot special.
As part of dealing with that and figuring that out, I actually had Seth Godin on our
podcast and Jeffrey Moore, who is the author of Crossing the Chasm. I asked them questions
about what that growth looks like and how you cross that chasm and hit scale at a higher
level.
When I learned from both of them, different sides of the coin, but particularly Seth
Godin was like, he explained to me, you don't need to do that. It is okay to say we're going
to figure out, we're going to stay on the niche. We're going to continue to be the boutique
company. We can still be the size we are, or maybe if we really commit to that strategy,
that means we're going to be 30 people again, but that it is okay. It's an acceptable path
to say we're okay being small.
That conversation was really valuable to me because that was the most extreme version
of that. Having him lay that out and making it clear that that was okay and we could still
define that as success was really valuable. It made me realize that there was a way again
to not let our fears hold us back and that we could instead let those fears guide us
into making the right kinds of decisions and staying true to the kind of company that we
wanted to be. We've moved forward from that phase of that next crisis of growth and it's
been really valuable.
We've already had that next one. Based on the trajectory now, that was last year, so
that means a year and a half, we'll have the next one because we have the half-life.
I love it. We live in a world where everyone's shouting at you what you should do, what kind
of business you should build, how big you need to be. I think hearing from somebody
that you respect and trust that it's okay to be small, that it's okay to do what you
want to do and build a business that you like, that's really what being an indie hacker is
all about. Making your life happy, making the life of the people you work with and work
for, great.
Chad, I've appreciated talking to you. You've run out of time, but I'd love to hear your
stories. Hopefully, I can have you back on again at some point in the future. Can you
tell listeners where they can go to learn more about you and about what your team is
up to at Thoughtbot?
If you want to learn about Thoughtbot, you can go to thoughtbot.com. I just mentioned
that podcast, which I guess you can go to giantrobots.fm. That's a podcast where we
talk to designers, developers, and the business people behind the products that we love. You
can follow me on Twitter at CPitel.
Thanks so much, Chad.
Thank you. It's been a blast.
If you enjoyed listening to this conversation and you want a really easy way to support
the podcast, why don't you head over to iTunes and leave us a quick rating or even a review.
If you're looking for an easy way to get there, just go to ndhackers.com slash review and
that should open up iTunes on your computer. I read pretty much all the reviews that you
guys leave over there and it really helps other people to discover the show, so your
support is very much appreciated. In addition, if you are running your own internet business
or if that's something you hope to do someday, you should join me and a whole bunch of other
founders on the ndhackers.com website. It's a great place to get feedback on pretty much
any problem or question that you might have while running your business. If you listen
to the show, you know that I am a huge proponent of getting help from other founders rather
than trying to build your business all by yourself. So you'll see me on the forum for
sure as well as more than a handful of some of the guests that I've had on the podcast.
If you're looking for inspiration, we've also got a huge directory full of hundreds
of products built by other indie hackers, every one of which includes revenue numbers
and some of the behind the scenes strategies for how they grew their products from nothing.
As always, thanks so much for listening and I'll see you next time.