How Wildbit Builds Multi-Million Dollar Products Working 40 Hours/Week
Wildbit’s Co‑Founder Shares The Lessons They’ve Learned Building Products Like Beanstalk, Postmark and DeployBot
Often, the success stories that we see start with a team leaving everything behind to go all-in on a single, focused product that they hope will disrupt the world.
The middle of this cliché story typically involves 6-day weeks of 12-hour days, shedding blood, sweat and tears in hopes of “making it.”
The peaks in the journey are punctuated by deep valleys that have the team regularly coming face to face with failure, and having to claw their way back.
And in the end, the business gets enough traction to be acquired by a whale or go public, making the employees lucky enough to get serious equity rich in the process.
The thing that stood out most about Wildbit’s success story—of serving more than 100,000 companies—is that it doesn’t sound much like that at all.
The company started was built out of a cash-flow positive consulting firm by a husband-and-wife founder team who started building products to solve their own problems, and insist on 40-hour weeks for themselves and their employees.
And instead of cashing out, Wildbit is focused on ensuring that their company is the one that stays intact and independently successful for many years to come.
Their story is a powerful reality check for many of us suffering from “TechCrunch tunnel vision” and given unrealistic expectations for what you actually need to do to build a successful business.
How Wildbit Builds Multi-Million Dollar Products Working 40 Hours/Week
How Wildbit Got Started
In the early 2000’s, Wildbit was the name for Chris’ web development firm, which started as Chris and a PHP developer he met online based in Romania.
Chris wasn’t a great PHP developer, so he met a young guy on a user group from Romania, and he had nothing to lose, so he decided to give it a try.
Chris really liked the UI design and front end stuff, so Chris would find clients and then he and his developer implemented the projects, and that’s how this all got started.
Eventually it grew into a bigger consulting business where we did a lot of different types of work, especially in social networks, and eventually we built Newsberry.
Clients had been asking for a tool to manage their email marketing, and Newsberry became the very first product that Wildbit built and sold in the marketplace.
We had built this email marketing tool for a customer, and then we realized that there was a big need for it in the market. MailChimp was around in its early days, but the market looked very different then, there weren’t a lot of these companies.
Newsberry was Wildbit’s first product, and while they turned it into a profitable venture, it also turned into the company’s biggest lesson on failure (more on that later).
Along Came Beanstalk
Wildbit took an old-fashioned, organic approach to growth: simply getting out into the Philadelphia market, going to meetups and telling as many people as they could about their business.
People talked, word spread, and Newsberry’s user base began to grow.
That’s when the Wildbit team started struggling with another big technical challenge: hosting their code and managing deployments.
Chris was managing our back end at the time and it was a giant pain in the ass.
Chris wanted to not be updating files to manage our user permissions, that sort of thing.
Another thing that Wildbit has done differently?
Much of the advice around the earliest stages of your product is to talk to your potential customers and validate the idea before building.
As it turned out, the market didn’t think it was ready, but Wildbit forged on anyway.
We did a little bit of validation, went out to our friends and said ‘hey, would you let someone store your source code for you?
And they were like “no, you’re crazy.”
Thankfully, he didn’t listen and we launched it to our existing customers, and sure enough, people stored their source code. Today it seems like such an obvious thing, but back then it was like, “give you my code? No way.”
The world was a very different place back then.
Beanstalk was the app that eventually let Wildbit wean off of consulting, though they didn’t rush in doing so.
Because we were doing consulting and generating revenue from that, the risk of launching Beanstalk was pretty low.
But as it grew over time, we were able to support more of the company from the revenue that Beanstalk brought in.
We only dropped consulting when Beanstalk could support the entire team. We were never going to let go of the people who were doing consulting for us, so the plan was to get Beanstalk to a point where it was making enough money to pay everybody’s salary before we quit consulting.
Eventually we got there, and we started to focus 100% on the products.
And Then There Was Postmark
A trend that you should notice by now is that Wildbit’s products don’t come out of years of planning meetings or brainstorming wild ideas; they’re born out of real needs that the team sees, either customer needs (in Newsberry’s case), or their own needs.
And that’s Postmark came about.
We were sending a lot of emails for Beanstalk: transactional emails, welcome emails, invoices, those types of things.
And we would get support tickets every once in awhile, saying “hey, I didn’t get my email.”
We were sending these emails internally through the app, and we didn’t really have any visibility or understanding of what was bouncing, what was getting marked as spam, or whether our emails were ever getting through.
So a customer emails us about it, and we’re going through logs, trying to see if we triggered the email, and Chris was like, “we really need to have visibility as an application.”
With newsletters, it’s easy; you send a newsletter and you can track open rates and all that stuff. But Beanstalk was sending all of these emails and we didn’t know how many we were sending or where they were going, so we decided that we needed something that let the application send emails, but that gave us a UI that let us know what was going on.
And so, Postmark was born.
But as Beanstalk and Postmark were taking off, Wildbit’s first app, Newsberry, was faltering…
Why Newsberry Failed
It feels a bit odd to say that Newsberry “failed,” considering that it was profitable—generating $75,000 per year in profit—when Wildbit decided to shut it down.
But the team was focused on other things, and Newsberry failed to keep up with the quickly-growing email marketing industry.
Honestly, we just weren’t using it.
We were so focused on Beanstalk and Postmark, that we sort of ignored Newsberry.
They say that you should build things that you believe are going to improve people’s experience, not just because you hear them asking about it, but because you truly understand their problem.
We’re not email marketers, and we didn’t truly understand our customers’ problems.
So when companies were coming to us saying, “please build us templates, we want Halloween templates and Christmas templates” and so on, we’re like “no you can’t do that, that’s stupid that won’t render well.”
So we spent a lot of time building beautiful editors, but we didn’t understand that most people didn’t really care about things like that.
Eventually, the app was overtaken in functionality by its competition, and the Wildbit team, wanting to focus on solving the problems they did understand, made the difficult decision to shut it down.
As Natalie wrote in her refreshingly transparent and heartfelt post about shutting down Newsberry:
Newsberry was not a product we were proud of, and that’s a huge problem for our team. Wildbit prides itself in design, detail and quality. Newsberry just wasn’t fitting the bill. I once logged into Campaign Monitor after not seeing it for a long time. I was blown away by how beautiful and smart it is. It was so much of what we always dreamed Newsberry would be. How could we keep going along if we knew that it wasn’t our best work? The team ignored it. Nobody used it or even knew how to use it. And yet we were charging people money. Sure, it did exactly what it was meant to do, and really well. We still had phenomenal email delivery, and the list-based method really resonated with a lot of people. But it just felt wrong.
But while Newsberry became history, Wildbit’s other products continued to grow faster than the email marketing app ever had.
Despite one very important missing piece.
“We are not very good at marketing”
What makes Wildbit’s growth even more impressive, in a world where marketing is trumpeted as the non-negotiable critical piece for growth, is that they haven’t really done much marketing.
We are not very good at marketing, at least not yet.
I don’t mean that as a good thing. It’s not good. It’s a weak point for us.
For a very long time up, until a year ago, we didn’t have anybody in marketing at all.
It was just Chris and I, so we were very product-focused.
We finally just hired somebody to head up growth.
When we launched Beanstalk 8 years ago, we just got friends to talk about it, some blogged about it and then it appeared on the 37signals blog.
Our friends talked about it, their friends talked about it and we grew a beta list of thousands of people.
Later, we got our first customers on Postmark because we let our Beanstalk customers know about it.
Still, it’s kind of amazing how many people we get who are like, “holy shit I didn’t know you guys run both Beanstalk and Postmark, I use both and I had no idea.”
So we’re trying to connect those dots for people because there is a lot of trust in there; we got our very first Postmark customers because people trusted us from Beanstalk, so we’re trying to get better at making that clear.
But even without traditional marketing, Wildbit has found great success with a strategy that, in a world of “growth hacking”, has become hugely undervalued.
Partnerships and integrations are huge for us.
We’ve partnered with companies like Shopify, we’ve gotten on a lot of websites because we build integrations for popular products. That has really worked well.
We pick products that we think are really useful and that compliment our products, especially when those products do things that we don’t want to tough.
Ticketing is a great example; it’s a complex beast of a machine.
Adding ticketing in Beanstalk was going to be crazy so we built integrations for companies like Groove.
We won’t integrate with everything because it’s a ton of work, even after you launch the integration with maintenance and support, but but if dozens of people start asking for the same thing we start checking out API’s to see if it’s something we can build.
And when we build an integration, we always reach out to the company to help us promote it so that their customers can learn about it too, whether they’re already using Beanstalk or they’ve never heard about it before.
Up until now, instead of spreading the word, Wildbit has focused on getting developers to buy into the vision of the company, which surprisingly, has very little to do with the individual products themselves.
Wildbit Is More Than Its’ Products
It’s rare to see a single-product company last for many years.
The market changes, customer needs change and the passion of the team to keep solving a single problem changes.
Wildbit is taking a different approach.
Our intention is to allow Wildbit to live on its own.
Our number one goal is to make sure that Wildbit is around in 20 years, so we’re building for longevity, and that means we’re product-agnostic.
I don’t know what our products will look like in 3, 5, or 10 years, but the team hopefully will stay the same.
Everything that we do is about removing the day-to-day annoying stuff that developers have to deal with, and making them more productive.
You get paid as a developer to release code, you don’t get paid to mess around with things like transactional email, so we’ll take that on for ourselves and handle it for you so you can go back to work on making your clients happy.
And the more we do it, the more people believe us every time we release a product that removes a pain like that and we say “just trust us, we’ve got this.”
That’s what Wildbit is about.
How Natalie And Chris Divide Their Co‑Founder Roles
One of the biggest challenges in many co‑founder relationships is drawing the line: who’s responsible for what?
It’s easier when both founders have very distinct skill sets, but there will always be some grey areas in between.
To handle that, Natalie and Chris devised a clever exercise…
At one point we both wrote down, for a week, every little thing we did each day. So we’d have a little notepad and we’d write things like “for ten minutes I did this, then for 40 minutes I did this.”
That helped us understand what we were spending our time on. Then we looked at that list and we said, I want to do that or I don’t want to do that. And we also thought about what we love to do and what we hate to do.
That very clearly created lines for us. because for the most part, the things that Chris really dislikes or isn’t really excited or passionate about, I really enjoy or don’t mind doing, so it really helped create a divide.
I would say that’s helped us be the most productive we’ve ever been.
Now, Chris handles pretty much all of the product stuff, (he’s much more technical than I am), along with the systems and back-end stuff, and I handle what I call the “front of the house”: customer success, marketing and the business side of things. I have all of the one-on-ones with our team, I handle compensation, that kind of stuff.
We definitely come in the middle on some things (product obviously has a lot to do with marketing) but that’s how we separate ourselves.
Remote vs. Non-Remote Workers
With 22 people, the Wildbit team has grown quite a bit since the days when it was just Chris and another developer.
In those days, the company was 100% remote with no central office.
But since then, it’s an issue that the team has struggled with a bit…
We used to be 100% remote, and wherever we could find people, we’d hire them.
But then we got an office and relocated some folks from Russia to the US, but the biggest feedback from the team that relocated was “I’m way less productive and I’m freaking out, because there are people everywhere talking and walking past you all the time.”
So we ended up moving into a larger space where everyone has private offices to help with productivity.
While I’d love to have everybody in Philadelphia, we’re still open to finding the best people available no matter where they are.
But it’s funny, because I end up hiring a lot of people who want to work remotely only because they’ve worked in open offices and they think that the only way to be productive is to work from home.
It’s disheartening to me, because I’m thinking, “no, you can work at an office if the office has the right environment for you to actually get shit done.” And a lot of people simply haven’t had that.
Still, Wildbit does hire remote workers. But Natalie is careful to ensure that candidates will be good remote workers, and not just good workers who end up failing at remote.
I look at little things like how they respond to emails, things like that.
I also ask questions like “why do you want to work remotely?”
I don’t want to hear that it’s because you weren’t productive in the office.
People think that it’s easy to work remote, but it’s really not, especially if you’ve never done it before.
You have to be ready to not see people all day, you have to have a lot of motivation to get up and shower and get dressed and into work mode. We don’t hire people who work at their kitchen table, and we don’t hire people who have no dedicated work space and sit at a coffee shop. You have to have a dedicated space where you work.
A lot of people want to work remotely to be closer to their kids, which I think is really important [Natalie and Chris have two young kids of their own], but if you don’t have a way to shut the door, you’re going to feel unproductive.
I think it’s awesome if you work from home so that you can go have lunch with your kids, or hug them or so you can walk away for 20 minutes and play, but when you’re working you need to work, so I ask a lot of environment-related questions for remote candidates.
Wildbit’s 40-Hour Workweek
Many companies pay lip service to the “reasonable work week.”
They tell candidates that they don’t have to work overtime, and that long hours aren’t expected of them.
It usually sounds something like this:
We only work 40 hour a week. That’s a Wildbit rule so I spend a lot of time making sure the team doesn’t work longer than that. We believe in going home and spending time with your family and your kids and doing other things.
But in many cases, the new employee arrives and sees that the founder actually spends 12 hours a day in the office, and they realize that the true expectations are actually very different than what was promised.
Wildbit doesn’t do that. The 40-hour workweek is a rule that the founders impose on themselves, too.
We have two kids. We go home.
And I think that’s really important because even though we’re a close team, seeing Chris and me go home helps people feel like, “yeah, we can go home too.”
If a boss is in the office until 10 o’clock at night, people will feel guilted into staying until 10 o’clock at night.
We’ll leave in the middle of the day to go hang out with our kid if she has a recital or something going on, and that’s totally acceptable on our team.
While we don’t have an unlimited vacation policy—my expectation is that people would never take a vacation if it was unlimited—I do keep track, and when people don’t go away, I ping them and say “hey, you can go, get out of here.”
We’re not perfect. Right now I can think of somebody I’m working with that’s just working too much, and feels a lot of pressure, but we’re talking about it and working through it.
It’s important to work through those things and say, “ok let’s figure out a way to get you to stop working so much. Do you want me to ping you at 6 o’clock to make sure that you’re gone? I can set a daily reminder.”
We work through figuring that out, but I think that making it an enforceable rule—it’s written on our jobs page and it’s in our values—is important.
It’s a funny thing to go yell at somebody to go home, but having it as a rule pushes me to actually make people abide by it and it makes it less of a fake thing, like a lot of companies have.
Natalie’s Required Reading
Groove’s blog subscribers tend to be voracious readers who work tirelessly to better themselves and their businesses. That’s why we’re asking each of our My First $100K interviewees to share their favorite books and blogs.
David Allen’s Getting Things Done.
That book changed my life.
It’s not actually about getting things done, but it’s about removing things out of your brain.
At any given moment, I have 7 different projects going at once, and some of them are work-related, some of them are personal, some have to do with my kids; I so much in my head at any given moment, and I was getting overwhelmed by the middle of the night wakeups of “crap, I have to remember to do this,” and “oh my god, did I do that?”
I read Getting Things Done years ago in college, but I didn’t really realize the value until I was actually busy and I read it again.
What it allowed me to do was take everything out of my head and open up so much space in my mind for thinking about the business, and for getting creative.
It removed all of the unnecessary thought that was built up by fearing the next task, and this constant anxiety that I’m forgetting something.
So now I use OmniFocus, which allows me to brain dump, organize and make things disappear that aren’t being worked on.
It’s amazing; I feel like I know that my work will get accomplished and my mind is free to think about other stuff.
I also really like Turn The Ship Around, which is a great book for learning how to manage a team without being a micro-manager, and how to how to motivate a team without just hiring 30 managers in the process.
Your Turn: Ask Natalie Anything
Natalie 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 Natalie in the comments below.