Tell me a little bit about yourself.
My first job was when I was 14. I was a sys administrator at a company that did web products for financial services. This is back in February of '98. I was doing system administration for three and a half years for as many hours as the state would allow a minor to work. I did that and then I ended up going to the University of Florida and the closest major that they had to Management of Information Systems was Decision and Information Sciences. I went into that, which was really good, because it wasn't as much the MIS stuff but it was a lot of data modeling and more code than I had expected.
I did that, but I got bored with it. Strange story, I got hit by a car and they wouldn't pay for my medical bills, so I got a lawyer. He helped me get my bills paid and he offered me a job in his office. I started working in his office during the summers in college. I was like, "Well, I work for a lawyer, why don't I take the LSAT?" I took the LSAT, and then I was like, "Why don't I apply to law school?" I did and I got in it, so I went.
Right after college?
Yeah, directly. I went to law school as the path of least resistance. I was still working at the law firm and doing some tech stuff on the side. I built this ordering system with my cousin Nick Stamas who, ultimately, became my co-founder. We were doing all this stuff on the side. I went through law school, passed the bar, swore in and I only made it as an Associate at the firm about three months and then I was like, "This is not for me." and I left.
What year was this?
That was 2008. I finished up with the law firm in '09 and, at the time, a friend's company that did grocery web sites was having a lot of problems with their systems. I had done system management before so I went ahead and fixed a bunch of stuff and ended up part of the lead team at that company for about a year and a half. Nick and I were still building stuff on the side. A million different things. I can't even remember. I have a list of them at home. I can't even remember what they did anymore.
How did you decide what to build?
Sometimes it's peanut butter and jelly and sometimes it's a steak sundae.
At first, it was naive, what was interesting to us or where we thought that there was some heat. You know how people look at the trend and be like, you take this trend, you take that trend, you add them together and then you see if they go together. Sometimes it's peanut butter and jelly and sometimes it's a steak sundae. We didn't have very good intuition about value proposition or unit economics or any of that. We were just building.
There was a Facebook Fund thing that Dave McClure did before he did 500 Startups. We applied to that. We applied to Y Combinator a couple of times, and we were still in Florida at that point. I was working on the lead team of that company and, because I was on the lead team, it took a lot of time and I didn't feel like I had enough time on my own projects, so, I started transitioning away from that job. I got a couple of steady gigs with clients as a lawyer, one doing security documentation for compliance, and then a couple other contracts and things like that.
It added up that I had lined up about 40% of my salary in side work and I was like, "All right, that's enough to transition away." I went from being on the lead team to a consultant a couple days a week until I finally dropped that job and started working on spinning up as a solo practitioner. The idea being that if I had clients and not a business, I would have more flexibility, which was, in retrospect, the stupidest idea I have ever had. There is no such thing as practicing law part-time. You have deadlines that are prescribed by law. You're in constant communication with the client and with the opposing side.
I had a lot of experience as a clerk, not a lot of experience as an associate or as a practicing attorney. I had to kind of be a full-stack lawyer. When you can spread out the burden amongst clerks and paralegals and other attorneys and outside services, it's a lot easier, but I didn't do any of that. I was just doing it myself. It was super stressful and we were still doing stuff on the side, but I didn't have a lot of time for it.
At the same time, I was having a hard time getting files securely from clients and this is right about the time that the Dropbox API came out. I was like, "It would be nice if I could just send somebody a link, they upload it and it goes into my Dropbox. I entered the form for a Dropbox key and we got it. Nick had gone on his honeymoon and he came back and I was like, "How about we work on this? Do you want to work on this with me?" And so we did.
Dropbox opening up their API gave you the opportunity that you needed to start working on Dispatch?
Well, this was about a year before Dispatch, but yeah, there's a straight line. We were one of the first to use the API. It was for a product called AirDropper. He got back from his honeymoon in June, we released the first version to some friends in July. A bunch of our freelancer friends liked it and shared it, and it was cool and we learned a lot. None of my lawyer friends cared about it, even though we had designed it for a lawyer's workflow.
We did a second iteration of it that we released in August of 2010, and that blew up, at least from our perspective. Brad McCarty, who was at The Next Web at the time wrote about us and Kevin Purdy, who was at LifeHacker at the time, wrote about us and we got like 25,000 users overnight in our beta. It was pretty novel at the time, because this was 2010. There weren't a lot of people playing with APIs and stitching things together. Now, it's like there's a Dropbox button, a Google Drive button in everything.
It was a free product. We had a lot of weird inbound that I didn't know how to parse, but one person who reached out was Chris Paik at Thrive Capital. At the time, they were a tiny ten million dollar fund, and he just wanted to say "Hey, this is cool, let's keep in touch." It was right around that time that Nick moved to New York in August and I moved in October. In the course of moving, I was still practicing law, Nick was still at the company that he worked for as a Rails engineer. We released a paid version of AirDropper in March of the following year.
This was 2011?
We had this weird fremium model, where you can use the beta for free, but the actual product cost $12 a month.
Yeah. AirDropper, we started in 2010, we released the paid version in March of 2011. Dropbox gave us good distribution for AirDropper and still does to this day. We struck a nerve with some people in the design community. We had some teachers, some architects, a bunch of different pools of people using the product and talking about it, so we didn't try to pitch it anywhere. We just changed our homepage to the paid product and we moved the beta to beta.airdropper.com. It's still up. We had this weird fremium model, where you can use the beta for free, but the actual product cost $12 a month. That was designed to be a full FTP replacement for people that were agencies or consultancies.
It's small but because we have that constant inbound via Dropbox, it made $5,000 the first year. It went into low five figures the second year and it's creeping up into the mid five figures now. It's just sitting there. We haven't changed very much since we launched it, because that was launched in March. In May of that same year, we went to the TechCrunch Disrupt Hackathon and we met up with Alex Godin there, who we knew through the New York Tech Meetup. We participated in the Hackathon and it was Dispatchio, this Chrome extension that allowed you to move something from Basecamp to Dropbox and Dropbox to Google Docs and move everything around. We were one of the winners, which got us on Dave Tisch's radar, who, at the time, was the managing director at Techstars. He reached out to us and invited us to apply to the program that was about to start. We got in.
How did you guys come up with the idea for Dispatch? Was it something that you had been thinking about for awhile?
We wanted to build Finder for the cloud.
I came up with the domain earlier in the year. It was just I liked "dispatch." It had a lot of meanings, and the .io was like input/output. I was like, "Oh, this will be a cool domain." We didn't actually buy it until the hackathon because .io domains are like a hundred bucks. People don't just buy them and sit on them, so they tend to be available. We knew that using APIs is cool because of AirDropper. Let's see how many APIs we can throw together in one project, and it worked. It was impressive. Alex gave a great demo and then we took that and thought of it as, "What if you had all of your stuff in one place?" As I know now, there is a version of that product in every vertical in the history of software and they almost never work.
We wanted to build Finder for the cloud. You could have your Dropbox there, your Google Drive there. At one point, we were integrated with Gmail and you get all your stuff. You could drag and drop in-between them and you could send things without having to have it in email attachments. You could talk about them. That was what we pitched and refined during the Techstars program.
Right. David Tisch heard about you guys, invited you to come and interview and you got into Techstars. What was that experience like?
That was a fantastic experience. I was in my late twenties and you get these concentrated peer relationships that don't exist once you get out of college. They kind of exist in the workplace but it's different because it's a little more political, whereas the way Techstars works, you have 10 to 12 companies share a space for three months all the way up to Demo Day. I met a lot of great people. I still talk to a lot of them. You feed off that energy.
It was cool to be around a lot of really smart, really motivated people who were bouncing ideas off of each other. It's a little bit competitive but it's supportive, too. The first month, you have a hundred meetings and you are trying to keep track. You're getting a bootcamp lesson on how VC and seed works. You become a support system.
From a product point of view, I've always wondered how, being in an incubator, you can know what to build over a three month period, because that's just not a lot of time. How did you guys figure out what product features you would build?
For us, we ended up raising about a $1 million, led by Thrive Capital, Chris Paik, who had reached out to us the whole year before.
Techstars is an amplifier for the progress you've already made. For us, the progress we had was hype. It took our hype and made it bigger and we had an idea, but to say we were pre-product was generous. We were smart and we understood what you can do with APIs. The people who were farther along in their product, and particularly in their business, got that much farther.
Contently was in our class. They had revenue, they had a model. They've tweaked the model since then, but they had real customers and real users on both sides of their market. Techstars was what they needed to accelerate to close a round and now, within their market, they're giant. Then, for us, we ended up raising about a $1 million, led by Thrive Capital, Chris Paik, who had reached out to us the whole year before.
For us, it was hard because there's not much time for a feedback loop. I've built a few products now, I feel like I have gotten a little bit better at it. It feels like it takes three to six months from starting just to know what you're building and what the value proposition is, how you're going to get distribution, how you're going to make money. You have to live with something and I don't know how to accelerate that. But if you have that knowledge, you have the core of your product and you're just trying to scale it and scale it faster, something like Techstars is a godsend.
For us, it was a godsend, but it was more like a bet. It was like people bought a future, not knowing where it ended up. We ended up having an okay outcome. We were acquired by Meetup in 2013, but it's a weird experience to go in there learning all this stuff and also having to figure out the product, too, and with all the noise and the meetings you have to do. That's an entirely different problem.
It wasn't really until post-Techstars when you were able to really think about product market fit and how to build your feature set. How did you guys, as a company, think through those problems?
It was really about building stuff, trying to get feedback from the hundred or so people we had using it, trying to figure out where the heat was.
By the time that we had gotten to Demo Day, we had raised money, we had done some hiring, and we built this sort of drag and drop idea. It was useful, but it was only marginally useful and it wasn't something you used everyday. It was like once a month, you might need to move something from here to there. So it wasn't sticky at all. The first thing we built that added an interesting value was comments. At first, it was more of a chat model, almost like Slack, where you're commenting in these work spaces, but we moved to more a blogging model, where you have a post and then you have children comments and they sort to the top, depending on what's most active.
It was really about building stuff, trying to get feedback from the hundred or so people we had using it, trying to figure out where the heat was. We did a lot of things wrong. We had a lot of complicated, novel things, but the whole was less than the sum of the parts. It didn't look like much but it was actually incredibly complex. We were doing live previews from all these different services in all these different file formats. We were doing some interesting stuff with how we processed images, so we could present them in different ways. It was all polling and eventually websockets so it was near instant. We were putting pieces together like Legos and not starting with the user. But we got better at that.
We didn't launch publicly until about a year after the program. We launched something that was more of lightweight project management tool that focused on your work product. You would bring in your different things, you could have your whole conversation around them. We launched that at TechCrunch Disrupt in San Francisco and it was sort of a pop and a flop. We got a bunch of users, we didn't hold onto any of them.
Why do you think that users left? What did they want that was missing?
It wasn't a project management tool, it wasn't a communication tool, it wasn't a work product tool. It was kind of half of all those. What ended up being pretty sticky had shades of all that, but initially it wasn't put together in a way that was helping the user be better than they were. It wasn't whittled down enough and it wasn't tailored to a use case.
We had some users who stuck around through some drastic iterations of the product. We talked to some of them and, for some people, they were oblivious to the changes. They see what they want to see and they change their behavior, but they're not conscious of how they change their behavior. It's was a reminder that you've got to understand the user better than they understand themselves, so you can get them what they need, because they might not even be conscious of it.
It's like people who play Candy Crush mindlessly for days. You get in these loops that, sometimes they're well designed and sometimes they're predatory and sometimes they are useful, but your behavior is being changed by the products you're using.
What we launched in January the following year, January, 2013, was the first not bad product. It was trimmed down and had a more minimal aesthetic. The first or second week in January, we had another spike from a blog mention and we kept those users, a good chunk of them, and they brought more. Our engagement went up and plateaued and for us, it was like, "Finally." That was cool. At that point, we had some vocal users who we had a much better loop with. From the beginning, we were using a product called Intercom to talk to our users, which is a fantastic product.
How did you guys use Intercom?
The great thing about Intercom, it's a little bit of an analytics tool, it's a little bit of a help desk, it's a little bit of a CRM. It makes it really, really easy to segment people and see who is doing what and start a conversation with them based on that. We had a help button that was just like an intercom. It came up and it was something that they could type their question to and we would respond back. More than half of the team was on support and we got to know the product and get perspective in a way that's a lot harder when it's just the team that is using it. We learned the hard way what it really means to listen and refine and try to understand the value through someone else's eyes.
You guys ultimately sold to Meetup in 2013?
Yeah. Over the summer, we repositioned, because we saw our value as taking people who had an email workflow and making it less chatty. We changed dispatch.io to dispatch.cc. We called it, "The end of reply-all chains." We had built a pretty cool, useful communication tool and we launched that in July and our numbers were really good after launch.
Meetup was around 12 years old and their communication tools had sprawled. They had about a dozen ways to communicate on the site. They wanted to figure out how to make that better, so they brought us on to manage their communication tools. We came up with the idea of focusing on one public channel and one private channel. We launched Messages, which is very chat like. We had some ground work for the public channel, which will fit in when it fits in. I'm not at Meetup anymore.
How did your product thinking change from when you were working on Dispatch to working at Meetup?
When we joined Meetup, they were just under 100. They're around 150 now. At that size you get to validate an idea not just with your users and usability testing but also with people who represent these different interests.
The biggest difference was Meetup already answered their core question. They allow you to find the people who are interested in the same things as you, that are close enough that you can meet up in person. They are this mix of communities of interest, communities of place and communities of purpose. Because they answered that core question, we were able to say, "How can we amplify that?"
We started from, "The value of Meetup is a function of the value of the communities, and the value of the communities is a function of the relationships within them. If we build the tools to foster those relationships, the communities will be more connected, the network will be more valuable and the core thing that Meetup sells will be more valuable to everybody," which has proved out pretty well.
Even at our peak, Dispatch was only eight or nine people. When we joined Meetup, they were just under 100. They're around 150 now. At that size you get to validate an idea not just with your users and usability testing but also with people who represent these different interests. We had a lawyer, we had a trust and safety team, we had a community team. You have all these different people who had deep experience with the product directly and from interacting with users.
We used that to our benefit to understand what might work, what might not, where the problems were. There was a lot of collective knowledge about who we were serving and what their needs were. We used the usability lab to see if we were way off base, but we really leveraged the team. The community team at Meetup is fantastic, with a lot of really smart, really dedicated people. We tried our best to talk to them as much as we could understand how our work would fit in for the several million people that Meetup serves.
Would you say that finding your startup's core value is the most important thing that you can do? If you don't understand that, do you not understand anything?
You have to be accounting for the value you're giving to the user from the beginning, whether from the top-down or the bottom-up.
I think that you can come at it from different directions. People who get into startups from the business side seem to build a worldview top-down. Take trends and things and look for heat and then, if they have either a product sense or they have someone who has a product sense, build to that worldview. I think that's kind of the Consumer Packaged Goods model, because CPGs are very expensive to develop and they need to know exactly who they're building for and why before they do a $40 million campaign around this product that takes $100 million to develop. That top-down view works within that frame, because it has to, because it's so expensive to be wrong.
You can also go bottom-up, where you start with the user and you start with a person. That's what I'm doing right now. I left Meetup in October, and I'm starting with just a core use case that I know that I have and I know a lot of other people have. I don't know how many of them have it but, for me, this is also an exercise of building something as one person. I think top-down is valid too. It just depends.
Either way, you have to be accounting for the value you're giving to the user from the beginning, whether from the top-down or the bottom-up.
Now that we're in 2015, do you think that one is a better way than the other, top down vs bottom up? Has that landscape changed at all since five years ago?
I don't know how to answer that question fairly. There's this great Steve Jobs clip from before he came back to Apple. He wasn't CEO yet and he's being heckled by someone. They were like, "What do you know about anything?" and he took it very graciously. Then, he tells this story of how they developed the laser printer and how much tech went into the box. Then he's like, "You didn't have to know about any of that. You just had to hold up the printout from the laser printer and say, 'Do you want this?'" because it was so much better than what came before it. You have to start with what you're putting in front of the user and how is it going to make sense to them. That clip is from the nineties and I think that is as true today as it was then. I have seen people come at it from different ways and build value. It's hard for me to say there's one true way of doing it. I know the farther along I go, I have been focused on getting closer and closer to starting with the user and not leaving them behind along the way.
Now that you are building Loose Leaves as a side project, is there anything you're doing specifically differently than when you started working on AirDropper or Dispatch?
It's much more important to see it from your user's perspective than to just put it out there.
Yeah. I'm starting with a use case, which with AirDropper we did as well, but I didn't know that's what we were doing. We kind of ignored that with Dispatch at the beginning. With Loose Leaves, it's an instant markdown publishing tool. You can have some Markdown. You can select it or hit a keyboard sequence. It uploads. You get a secure link back that you can pass around that's beautifully formatted. It's designed for passing around drafts of blog posts or product specs or emails, anything that you want to get feedback on.
That's something that I've wanted for a long time. I've used approximations of that in other products, where it's a secondary feature and it just doesn't work as well as I'd like it to. It was on my list of ideas to build and I feel like, as one person, given several months, I can actually put it together. There's some breadth to it because, ultimately, there'll be a Mac client, an iOS client, and a web component, but it's pretty shallow as far as what the implementation burden is on each of those things.
For me, it's an excuse to dabble in Mac and iOS development and brush up on Ruby and revisit how I do systems stuff. It's as much tailored to what I'm interested in working on right now as it is to what I believe is a strong value proposition to people who use Markdown. That's not a ton of people, but there are people who their default in how they write things is in Markdown. iA Writer, which is among the more popular Markdown-centric editors, has sold a million copies across all of it's platforms. People are paying for things of value in that vein. For me, where I'm at, that's enough to get started.
The way I've have gone about building it is, I've focused on how quickly I could get something that demonstrated how it worked. I have a proof of concept that I've shared with around forty people. Some people have used it more than others, but at this point it's more about hearing people, how they react to it, what's interesting, what they ask for. I'm starting to get the four corners of what the product is and what it isn't. That idea of getting something in people's hands as fast as possible and then really listening. It's much more important to see it from your user's perspective than to just put it out there like, "This is what I want and what I see." If you don't get what they see, you're not going to be able to give something of value.
Lastly, if you have one piece of advice for new entrepreneurs, what would that be?
I feel like this is a rehash but focus on delivering value. It feels really, really good when you can give somebody a superpower. It's another layer of joy on top of just doing good work and being financially sustainable. You're taking people and you're helping them do things that they couldn't do before. There's magic to that.
Awesome man! Thanks very much.