In the beginning, Olark wasn’t built to be a business with more than 10,000 customers.
Nor was it built to be a business at all.
In the beginning, Olark wasn’t even Olark.
It was a side project for Ben Congleton, then a PhD student at the University of Michigan, and two of his friends.
That was five and a half years ago.
Today, Olark’s live chat software has facilitated nearly 52 million chats between its users and their customers and website visitors, and the company is growing fast. They recently hit a huge milestone when they signed up their 10,000th paying customer.
We talked to Ben about the history of Olark and the valuable business growth lessons he’s learned along the way.
The Early Days
Long before Olark, while Ben was a PhD student, he ran two businesses with his friends, Roland and Kevin.
The first was a web hosting company “that was pretty much set on autopilot.”
The second, a consulting firm, had the trio building software for other companies. Ben would bring in the clients, while Roland and Kevin would build the products.
That’s when they first realized they wanted to try something different.
We had been doing consulting work for other startups where we were building the software for their crazy ideas and we’re just like, ‘man, these people don’t really have product/market fit, but they somehow are able to get money and pay us to build all this stuff. While we’re happy to take their money and build their products, I think we could do a much better job as a product company and build our own things.’
With that, the team began to experiment with some side projects.
First, Kevin built a granular synthesis plugin for GarageBand. While the product was innovative, it didn’t take off.
It was pretty awesome stuff for a very select audience, but we didn’t really understand the market. We shipped it and made a few thousand dollars, but it wasn’t the homerun success we were hoping for.
Another experiment, called Gig Loader, was built to help bands keep track of their shows. In the end, the team decided that musicians would not be a lucrative market for them.
Years before, the team had looked for a live chat app for their own business but didn’t find anything that they were happy with.
Looking for new side project ideas, a light bulb went off in Ben’s head when, in a seminar at school, he read a paper by Dr. Shoshana Zuboff.
She was talking about how the internet creates this system of dis-intermediation; buyers and sellers can conduct business directly with each other, without middlemen, so you don’t really need distributors as much. So if you imagine a future where creators are selling things directly to consumers, they need tools to communicate.
What’s a better tool than live chat?
Email works somewhat but it’s not really conversational, there’s high transaction cost and people don’t respond immediately. The phone works alright, but you have a whole generation of people who grew up using instant messaging like AIM and ICQ. These people are now moving into businesses and they’d like to talk to their customers the same way that they’re already talking to their friends.
And so, the team took another look at the live chat space and realized that very little had changed. The same tool they had tried — and hated — in 1999 was still the leading product in 2007. And it still wasn’t right for businesses like Ben’s.
These companies were going after bigger enterprise customers, so they had used live chat to get in the door, and now they were building other products — help desks, VoIP, ticketing — that they could upsell. Instead of focusing on their core product, they were focusing on pushing up the lifetime value of each customer by selling them more stuff.
"We saw an opportunity to go in and serve the people who were like us: the smaller companies who didn’t have giant call centers, but who still wanted to talk to our customers." Click To TweetThe team got to work building a prototype, and quickly put together “the crappiest, littlest, janky floating chat box you can imagine.”
They called their product Habla (its URL was hab.la), and began offering it for free, sharing links on forums all over the web.
They quickly found a bit of interest, but decided to continue pursuing Habla as a side project rather than going all-in. The product remained free, with hosting costs being paid for by income generated from the team’s consulting gigs.
And while the team wasn’t yet interested in turning Habla into a full-time gig, their early traction was enough to attract a much bigger fish…
An Offer
In 2008, the team got a call from Meebo, a now-defunct Instant Messaging company that was growing quickly at the time.
Meebo wanted to talk.
They flew us out to California. None of us had ever been to Silicon Valley, so we didn’t really know what was going on.
We got out there and thought, ‘oh man, we’re going to sell things thing for tons of money, we’re going to be rich, this is going to be awesome, we’re all going to move to California and it’s going to be so much fun.’
And we got in there, and we talked to the team, and we all thought: ‘Hmm… this feels a lot like a job interview. Why aren’t we talking about our product? That’s strange.’
A little while later, I got a call from Seth Sternberg, the CEO, and he said that Meebo wanted to acquire Habla. He offered to give us tens of thousands of dollars in exchange for our assets. And they wanted to hire Kevin.
That was when I realized what was happening. I told him that we weren’t interested in selling the company for tens of thousands of dollars, but that if he wanted to hire Kevin, that I wouldn’t stand in his way. Kevin’s a good friend of mine, and Habla was a side project; of course he should take a great job if one comes along.
In the end, after a short courtship, Meebo did hire Kevin, leaving Ben and Roland with a decision to make.
Habla was beginning to get some serious traction.
It was growing, we had a lot of free users and they were reasonably happy, but they kept demanding more features and better functionality. We didn’t really have the time to work on it, so we decided to go out and try to recruit some more co-founders.
That was also when Roland got the idea that Habla should apply for Y Combinator.
A Turning Point
Over the next couple of months, two things happened that would change the course of the company’s future, and tip Habla from side project into full-time startup:
Habla was accepted into Y Combinator, and the pair found their third co-founder in Matt Pizzimenti, who moved with them to Silicon Valley to take part in the accelerator.
(A fourth co-founder, Zach Steindler, would join the team during YC.)
The team moved into a house on Ramona Street in Palo Alto. A house that turned out to have been the previous home of another prominent startup founder: Elon Musk, who ran Zip2, his very first company, from the Habla team’s future home.
The living arrangements forced the team to develop a strong working relationship, or risk making both work and home life miserable.
When you’re living together, you can’t escape each other, so you’re forced to deal with things (or fail). I think that by putting ourselves in this forced situation, it really helped the core team grow a lot, really quickly.
We learned to understand each other’s communication styles, how to make conflict positive, how to disagree in a way that’s productive. For example, I used to have a tendency to be pretty defensive and passive-aggressive in some situations, while Matt is a lot more direct. In the end, I’ve completely come around and now I’m much more direct. You learn a lot about yourself when you have to directly deal with conflict.
Even though we have a much bigger team now (and they’re all over the world), it’s something that we now try and train our team on: understanding the value of conflict and how really good, productive things can come out of it.
While the team worked to gel inside the house, they also had to hustle to get through Y Combinator’s grueling program.
The first order of business? On the advice of YC founder Paul Graham, the team needed to change their name.
Our domain was Hab.la, and Paul’s main advice was that we needed to own the .com. It was such a huge pain for Dropbox to have getdropbox.com at the beginning, and it took them years and tons of money to eventually get dropbox.com, and we didn’t want to be in that position.
Talking to customers, the team also learned that many had trouble pronouncing and spelling Habla correctly (as it turned out, habla is also an insult in Arabic that means “foolish”).
Coming to terms with the fact that Habla was not going to work for them as they moved forward, the team made a long list of names whose .com domains were available.
One of those names was Olark.
Tired of the back-and-forth debate on names, Ben finally put his foot down.
Eventually I said, hey guys, let’s just be Olark for the next week. It’s short, it’s easy to spell, it doesn’t have any connotation and we can really own the brand. Let’s just see what it feels like for a week.
A week later, the name stuck.
Scraping By
Living on YC’s $25,000 investment in one of the most notoriously expensive markets in the world doesn’t seem easy, but the Olark team didn’t have a choice.
Fortunately, Ben and his co-founders were used to living frugally.
As a grad student in Michigan, he made $30,000 per year, and saved $12,000 of it.
I was living on maybe $20,000 a year, and not really feeling poor.
Matt and Zach had graduated and had real engineering jobs, but they were living like college students at the time, and Roland was living in Charlottesville not making much money, so the entire founding team was used to being pretty scrappy by nature.
None of us really wanted to drive BMW’s or anything like that, so we just kept a low-key scrappy maker culture, so that $25,000 went reasonably far. We were young and used to eating like college students and we didn’t have a car. We would bike to the supermarket and make all of our food ourselves. It wasn’t that hard to do, and so at first we just paid ourselves in food and rent, and that was it.
As the company — and the revenue — grew, the team was finally able to hire themselves.
You don’t want founders to be unhappy. It’s hard enough running a company, you don’t also need to feel poor at the same time. So we followed the policy of ‘hiring ourselves first.’ As soon as we could, we began paying ourselves salaries — though nowhere near Silicon Valley salaries — before making our first ‘real’ hire.
Olark kept growing, going, in Ben’s words, “from Ramen profitability to Whole Foods profitability.” Still, the founders maintained their thrifty ways (living together and having the company cover room and board certainly helped), and were soon able to hire their first employee.
There were never really times when our pay was drastically different from other people at Olark, but it’s important for us to reward ourselves like we’re part of the team, and not some special class of employee that has to suffer so that other people can get paid.
Focusing On What Customers Want
Because of the work that the team had put in on Habla, when Olark turned on their paid accounts, they already had an existing base of thousands of users.
In the beginning we thought, let’s solve a problem that people have first, and solve it well, and have them love that thing. Then we’ll figure out what else we can add that they’ll pay for.
This strategy armed the team with many loyal fans and helped them go from cash flow negative to profitable in short order.
How did they figure out what people would pay for?
We started modeling usage on Olark, graphing the chats that our customers were having.
We identified that the people who had more than 20 chats a month tended to have a lot more than 20 chats a month, so we just started gating our free product at 20 chats at month.
So anyone who’s having less than that is probably not really serious about communicating with their customers, and anyone that’s having more than that probably would be happy to pay us.
Ben recommends that every company do this:
"You should have some mechanism within your product where you have an understanding of who’s getting a lot of value out of your product (and would most likely pay for that value)." Click To TweetThose who aren’t getting a lot of value shouldn’t have to pay, but they can basically become advocates for you, especially since the carrying cost of those customers is very low.
As Olark continued improving their product, they began to make customer development a big part of their approach.
Each time they considered building a new feature, they would talk to customers and post on forums to gauge interest before moving forward.
In fact, Ben says that the only features that haven’t worked out are those that the team built without customer input.
Whenever we built something just because we thought it was cool, it was a bad idea.
For example, we built something called Chat Links where people could send someone a link, and have a chat window follow the person around. We thought it was super cool, but it turned out that our customers would have rather had us spend the same time solving some other problem that they actually had versus solving a problem that didn’t really exist.
It’s been really important for us to figure out how to get customer feedback into our organization in a lightweight way. You don’t want customer feedback to become this arduous process that stops new ideas from happening.
How does Olark accomplish that?
We have beta programs and staged roll-outs. Try to identify the customers that you want to work with and that you want to make incredibly happy, and have your product team work directly with them.
For example, we recently launched Reports, and we had all of the people that had ever requested Reports tracked on a JIRA ticket, so when we launched the feature, we had this immediate beta group that we could reach out to for feedback.
Growing The Team
With 31 employees, Ben has learned some valuable lessons on hiring, including one that goes directly counter to the common startup advice of “find rock stars and make space for them”:
One thing I’ve learned is that if you fall in love with a candidate’s talent, but they aren’t a good fit for the position you’re hiring for, it’s probably not a good idea to proceed. That was a mistake we made in the early days, thinking that someone was so awesome that we’ll create a position just for them. It’s never worked out. It’s just led to confusion and unclear expectations.
Another piece of advice Ben has for startups looking to hire: always check references.
When you do reference checks, you’re not just looking for the bad stuff. What you’re really looking for from that person’s previous manager or co-worker is how you can help that person grow. You’re not just trying to found out what’s wrong with this person, or what their strengths or weaknesses are. You’re trying to dig into how they work together, where this person might be in 3 years, why does the reference think they left their last job, how can I help them get to where they want to be?
As a distributed company, Olark needs to make sure that new hires can work with the existing team:
Communication is really important, so we try to interview for conflict style. We’ll try to cause some small conflict during the interview and see how the person responds, we go off-script and get outside of what someone might generally prepare for in an interview. It helps us evaluate whether the person will share things with you that they’re feeling, or if they’ll speak their minds when it’s most important.
One of the things that Sunir, our CMO, likes to ask is ‘what’s the zaniest thing you’ve ever done?
(Ben’s answer to that question? Climbing to the top of the 100-foot redwood in the backyard of Olark’s Palo Alto house. “It’s like having your own personal mountain.”)
As the team grows, Ben and his co-founders also work hard to ensure that Olarkers embrace the same level of comfort with conflict that he learned in those early days during Y Combinator.
We work really hard to make people feel comfortable speaking up about things that they feel uncomfortable about. We’re a remote company we need people to speak up when they have an opinion, because we’re not going to see them grimacing at their desk when we walk by. We can’t read their body language and ask them what’s up.
To help build that culture of openness, all Olarkers have one-on-one time with a founder every other week, and the whole team practices no-fault retrospectives after every project.
When a project wraps up we always look at what went well, what went poorly, what should we continue doing for future projects, what should we make sure never happens again. The key is that we never blame individuals, but really try to capture valuable feedback from everyone so that we can iterate together.
The company also has a weekly “show and tell” where someone from the team talks about a topic that they’re interested in. Olarkers have talked about everything from building their own furniture to new front-end technologies to one talk that Ben called “amazing,” about a coworker’s struggle with depression.
It made me feel really proud that we had built this place that people felt comfortable talking about stuff that in many locations would be a pretty uncomfortable topic.
All-Hands Support
Another Olark staple that has helped the company improve their product and their team is a focus on all-hands support. Every single Olarker spends time doing customer support, from the CEO down.
It helps everyone. Each engineer has some insight into what it’s like to use the product, and what it’s like to be our customer. I think that insight is very valuable, because when someone is sitting in a brainstorming meeting, they understand what the problems are with our product and what would make their life easier everyday when they were using the product. It means that product insight doesn’t always come from one person, like the product manager.
You get more customer insight within your team, more empathy for your customers across the board, more empathy for the support team and a shared experience for our team to bond over. It’s a very real way of emphasizing just how much we care about our customers.
All-hands support also heavily influences the way Olark hires.
When we’re interviewing a developer and we tell them that they’re going to talk to customers directly, that they’re going to talk to people that are using the product that they’re building, we want them to be excited about that. We want engineers that want to build products for people, not just solve really complex abstract problems.
It all comes down to the kind of company you’re trying to build.
For Ben and the rest of the Olark team, “the kind of company” they’ve tried to build is one that does things its own way, without regard for the things that a company is “supposed” to do.
Their team works from anywhere they’d like to.
They share a fierce dedication to customer support and success.
And they’ve built a product, shared primarily through word of mouth, that has helped them grow to 10,000 customers and beyond.
Ben’s Required Reading
As with our other interviewees, we asked Ben for his top three favorite sources of insight for startups online:
- SaaStr by Jason Lemkin, founder of EchoSign
- Hacker News by the Y Combinator community
- Harvard Business Review by the Harvard Business School
Your Turn: Ask Ben Anything
Ben has (very) generously agreed to answer your questions in the comments of this interview.
We’re going to be watching closely and trying to learn as much as we can ourselves, so don’t be shy.
Post your questions for Ben in the comments below.
