An interview with Garrett Dimon
In this interview, Garrett discusses the thinking behind his product Sifter, the problem with low-end price plans, the long, slow ramp to just covering his own salary, and lots more about the struggles of building a SaaS business.
As always, an MP3 recording of the conversation is available (40 minutes, 50MB), and there is an edited transcript below, with additional graphics to illustrate some ideas.
Des: Hi there, and welcome to Inside Intercom. Today’s guest is Garrett Dimon, the author of Starting + Sustaining, a practical guide for building and maintaining your own web businesses, and the founder of Sifter, a very popular issue tracker. Hi, Garrett.
Garrett: How’s it going?
Des: Great, thanks. I’d like to start this off by going back a bit. Five years ago you decided to quit your job, cut your salary to near nothing, move into a 500 square foot apartment, and start building Sifter, something you’d been sketching our for eight years previous. I want to know why.
Garrett: I have always had a fascination with issue tracking. When I got out of college, I went to work at Sapient and basically got thrown into very large projects that had to have a formal issue tracking process. So from the moment I was out of college, I was kind of tossed into that world and became very, very knowledgeable about bug and issue tracking.
And then after leaving—well getting laid off as the dot-com bubble burst—that experience stuck with me. And at my next couple of jobs the bug tracking was non-existent. At one point, I was working for a company who had outsourced development. I asked “Where do I report bugs?” And they emailed me a PDF and they said “Here, print this out and fax it to us.”
That was the point where I realised that not every company in the world has a great bug tracking process. I just kind of became curious and fascinated by that. I then spent pretty much my entire career doing consulting work for small to mid-size projects where the teams were never larger than 25 people. Big enough to need a formal process, but not big enough to need tools like FogBugz or JIRA. At the time, there wasn’t much else out there. You either took everything and used one of those apps, or took nothing.
Our clients wouldn’t use those apps. They’re not deeply technical people. They were intimidated by them. So we’d have a formal issue tracking process and it’d be all set up and we planned it out, and the clients would log in, and then within the next day, they would just email developers. And so that whole process basically fell apart simply because they wouldn’t use the tools we were using.
All of that experience over the years added up, and haunted me in the back of my head. I would always sketch and play around and explore. In hindsight it was inevitable that I would launch a bug tracker.
Des: Lots of what makes Sifter a great product is its fantastic design. You have some great screenshots of iterations online from showing hundreds of iterations over the header. Aside from the interface, how much of Sifter is about enforcing or suggesting a process to people?
Garrett: You know, I wouldn’t say it’s suggesting a process because it’s still fairly flexible. It’s very rigid in terms of options, but it’s flexible in terms of how the existing options can be used. There’s a karaoke bar in Portland that uses Sifter to manage tasks between bartenders and management. So the flexibility is there. Our goal is: let’s build something for the people who don’t need the complexity of the larger bug trackers. Build a tool so they don’t have to worry about configuration. By minimizing all that and putting constraints in place, it simplifies the burden on them to figure out how to use it and how to best apply it. It just makes it easy enough for them to hop in and start using it without feeling overwhelmed or turned off by all the options.
Des: One of the pieces of Sifter that is reasonably opinionated is that you don’t allow tickets to be on hold. Is that correct?
Garrett: Yeah, absolutely. That’s kind of the digital equivalent of sweeping it under the rug. You know, it sounds good. But once you start using it it’s just “I’m not going to take this issue seriously, so let’s just toss it over here and maybe that’ll we’ll come back to it later.” My view is fish or cut bait. If you’re not going to do anything about it, close the issue. If you’re going to do something about it later, you can reopen it.
If you get into too granular of a status, you end up with states that aren’t really states. They’re more kind of just various bits of information about the issue. A lot of times, people want specific resolutions. When an issue is resolved, they don’t want to put ‘resolved’, they want to put ‘won’t fix’ or ‘duplicate’ or whatever. And really, that’s not a state so much as a resolution. And resolutions are best captured in text where you explain why you made the decision you made so that for historical purposes you can circle back later and see. Saying ‘won’t fix’ as a state is a cop-out because it lets you not explain why you won’t fix it. And then a month later down the road, you come back and see ‘won’t fix’, but why did we decide we wouldn’t fix this?
Des: When I’ve used issue trackers that allow ambiguous states like ‘on hold’ tickets tend to pile up in whatever the most vague non-committed status is. In the end you can’t see the wood through the trees, because when you log in there’s like 800 issues, 5 of which are actually pressing, relevant issues, 795 of which are aspirational, “We’re going to do this someday”” type things.
Garrett: We do the same thing with milestones. The only way milestones are considered closed is once the due date is passed and all of the issues within it are closed. Often people are like “How do I close a milestone?” and I’m like, “Well, finish all of the work you put in there.”
If people could just close a milestone, they’d sweep all of that unfinished work under the rug. You have to make sure that you don’t just make it easy for things to just kind of accumulate without any kind of outcome.
Des: Have you ever tried any tactics to increase adoption of Sifter with teams? Do you remind people to come back and check it, or send out reports on how it’s been working for a team?
Garrett: I’m in the mind that if we’re not giving people something valuable in an email, that I don’t want to send people emails. I’m starting to get to the point where I can see we need to do more to educate people and help people use Sifter better before we start just making it more complicated.
On Traction, from 50 to 15,000
Des: Do you remember your first customer?
Garrett: I remember lots of first customers. It depends on if you count friends or not.
Des: The first customer you didn’t know.
Garrett: I don’t even know if I could say there was a first customer, because…
Des: You probably had 50 customers on the first day?
Garrett: Yeah. Like, the first day, we had a handful that signed up.
Des: And how did you get them?
Garrett: Really just through blogging, and, I guess the waiting list helped. I had an email list, and it was about 1,000 people and we sent out a, you know, hey, we’re live, email to those people. But most of it I think just came from blogging and from people who were interested in Sifter because by talking about it long before it was ready, it kind of pre-selected a certain audience that was at least vaguely interested in some of, you know, the thought process, and at least were fascinated by some of the same sick and twisted bug tracking stuff that I’m fascinated by. So I think that helped a lot.
Des: And where is it up to today? Do you have any numbers that are public around how many customers you have?
Garrett: Over any 30-day period, we have somewhere between 12,000 to 15,000 active users.
Des: How does that grow?
Garrett: Very, very linearly, and really through word of mouth. We’ve done a fair amount of advertising, but when it comes down to it, the best way we’ve grown really I feel is from things like Twitter and word of mouth. Just people signing up for it that have either used it at previous jobs or know people who have used it and recommended it, and it’s kind of just bit by bit expanded like that.
Des: So there hasn’t been any key growth activities. You didn’t go viral or anything?
Garrett: No, definitely not. In hindsight it was a mistake to make all of the accounts heavily sandboxed instead of trying to add an element of sharing to it. It’s turned out well, but I definitely think if I could go back I’d try to make it so that the accounts could interact more seamlessly and kind of enable that kind of growth.
Des: Today, you have thousands of active monthly customers. Do you get lots of requests, feedback, et cetera?
Garrett: Absolutely. The feature requests have never ended and, last time I checked, they’re still going. Probably something like 60% of our emails are related to feature requests.
Des: Do you think that’s a function of how simple you’ve kept the product?
Garrett: I think it’s a combination of things. It’s driven in part by the fact that I have kept Sifter so simple that there are a lot of features to be desired. The other part I think is the target audience, being that it’s developers and the sort, they’re the type who are definitely wired to think in terms of features and how to execute on ideas or how to improve things. So they naturally just have a lot of ideas bubbling up. And then finally, it’s probably just related to the fact that anytime anybody emails me, I reply to something like 91% of our emails in under an hour.
Des: That’s pretty impressive.
Garrett: That’s not just a yes/no reply. That’s always a pretty in-depth reply, almost starting a discussion about the feature. Every time I get an email, even if it’s something I thought about before, you know, even if it’s later that evening, I still set aside time and think through it and think “Is this still the right decision? Has anything changed?”
Des: Right. What’s the most frequent request that you know you’re probably never going to do?
Garrett: A month ago, I would have said text formatting. But I think there’s a chance we might put in some form of text formatting. I don’t know when or how.
Des: You mean like bold and italics, that sort of thing?
Garrett: Yeah, we’ve dabbled in it and we’ve explored it and it’s certainly probably one of the front-running requests. There are some consequences to it. Even the current Basecamp implementation, I was writing something in there on somebody else’s account and trying to use it, and I just tried to bold something, or unbold it, and all of a sudden everything got all wonky and I had to reload the page.
Des: It does seem like WYSISYG and others, those sort of things, they do seem like a serious iceberg in web applications. What the user see is tiny in comparison to the development effort.
Garrett: Exactly. It’s a very ugly, nasty problem. I don’t want to just toss it in just to make people happy, because ultimately they’ll end up more unhappy with a poor solution than they would with no solution at all.
Picking Price Points
Des: Let’s talk about pricing. In your book, you outlined a lot of different lessons you learned along the way. You’re currently at a situation where your smallest plan is $29. How did you get there? Did you start it cheaper?
Garrett: We originally started with a $14 plan as well. Over time we realized that the $14 plan really wasn’t pulling its weight. Especially as obsessive as I am about really providing good customer support and getting back to people and having in-depth conversations with people. The $14 plan just made it difficult to really hold up and deliver on our end of the bargain if we’re losing money on a certain swath of customers.
Des: Would your definition of losing money be that the support cost of these additional customers wasn’t justified by—
Garrett: Yeah, it was all driven by the support costs. The biggest cost to support isn’t necessarily the cost of answering them so much as the opportunity cost of every time I’m answering a support email, it’s taking me away from doing development work or otherwise improving the product. Our $14 plan produced the highest volume of support requests from the lowest lifetime value, so the corollary was basically we were spending a lot of opportunity cost on customers who probably weren’t going to use Sifter very long, so ultimately we were losing money on them.
Des: When you dropped the $14 plan, did that affect your sign-up and conversion rates?
Garrett: Yeah, definitely. Our original goal was simply thinking well, if we remove the $14 plan, if even half of those customers that would have signed up for the $14 plan still sign up for the $29 plan, then we’ll come out ahead—well, at least break even. So we make the same amount of revenue on half as many customers, at least in that class.
Des: And how did that work out?
Garrett: Our conversion rate from site visitor to trial plummeted. It decreased by 50%. So we had 50% fewer trials signing up. However, our total amount of $29 plans skyrocketed. Fewer people signed up but the ones who did were much more likely to sign up, and they were fine going ahead and signing up on the $29 plan. We were definitely were happy with how it worked out… lots of the customers who would have signed up for $14 went ahead and signed up for the $29 plan without skipping a beat.
Des: Did you ever consider a free plan?
Garrett: No. We have thought about bringing back a very cheap plan. Based on my experience, if you’re charging less than $10 in the business space, that might as well be free. Charging money is just there to make sure that people are at least a little bit engaged in the system. A lot of people use anything if it’s free, so by putting a little bit of a barrier there, you tend to kind of pre-qualify customers.
Des: You don’t charge per seat, which the other issue trackers do. Why not?
Garrett: My philosophy is that the most valuable feature of any kind of collaborative software, but in particular bug and issue tracking, is participation. That’s not really a feature that you can factor in like other features. It doesn’t matter how great the issue tracker is. If nobody uses it, then it’s not going to work.
Des: When you look at Sifter and think about it over the next five years, what big challenges do you see? Are you worried about someone else coming in and gobbling up the sort of simple market space, or do you think you’ll take the product upmarket and add some of these bigger features?
Garrett: We’ll add some features. The market is already so incredibly fragmented and it’s a market I don’t believe is ever going to be unified because there’s just too many different preferences, team sizes, technology stacks, development processes and workflows that it’s more like Goldilocks where, you know, this porridge is too hot, this porridge is too cold, this one’s just right. Every team is going to be so different.
If anything, we need to do a better job of simplifying our existing feature set. Not to say removing features, but making the existing stuff work 10 times better than it does. So we’re going to add some other stuff for sure. In particular, we’ve been spending a lot of time on our API so that Sifter becomes a better neighbour with all of the other tools, whereas right now it’s an iceberg all on its own.
Other than that, a lot of what I want us to do is to invest in resources and just helping people learn how to do an appropriate level of bug tracking given their team size or project size or whatever the factor is for them.
Des: That’s an education challenge for you, right? You need to effectively teach your customers how to best make use of their time bug tracking.
Garrett: Yeah. It’s not even going to be purely about showing you how to use Sifter. It’s going to be about bug tracking, and if Sifter’s right for you, awesome. If it’s not, then hopefully you at least know some more. I’d love to see us grow, but I don’t want to see us grow and get people who don’t like Sifter. I want to see us grow to people who like Sifter, and if Sifter is not right for people, I want to see them happy somewhere else rather than see us trying to make a few extra dollars.
Des: What sort of stuff are you considering for educational resources?
Garrett: We’ve always blogged. That ebbs and flows with how deep I am in development. The first thing we want to do is create content for reading, then potentially a week-long email course, where every day we send a blog post via email. Let people opt into those free courses.
Where to from here?
Des: Have you ever considered a second product?
Garrett: Definitely. We talk about it all the time. But we feel like there’s so much room left with Sifter. I was even afraid of writing a book. But adding a second product just creates a whole other layer of distraction, and I feel like for us to create another product like that is almost like saying, oh, we feel Sifter’s perfect and doesn’t need to improve.
Des: So, what motivated you to take time away from Sifter for the book?
Garrett: I’d been blogging about some ideas and had always gotten good feedback. People say things like “I’m in that exact same spot you were five years ago.” People just—they appreciated that stuff that I was sharing so I figured I could probably write a book and make this a lot easier on other people.
I figured if I could go back in time and tell myself everything that I know now, I would’ve probably shaved months of effort off my life and a lot of misery.
Des: What are the key lessons that you’d love to get into a time machine and tell yourself?
Garrett: At one point we encountered some fraud. Somebody was just validating stolen credit card numbers using the credit card form on Sifter, and out-of-pocket, it cost us maybe $200 in credit card fees. You know, really nothing in the grand scheme of things. But for two whole weeks, it just drove me nuts. In reality, all we needed to do was just stop it and move on. Another time lost about eight hours of customer data. We thought we had enough data redundancy. We had backups. You know, everybody’s always got backups. Our backups just weren’t robust enough. And we had never really thought about, oh, there’s just so many scenarios for losing data and things that can go wrong. And in this case, at the time we just didn’t have thorough enough stuff.
The Numbers Before the Business
Des: Included with the book is a detailed SaaS planning spreadsheet. Did you create that for this book?
Garrett: No. A version of it was used when deciding whether we would try to build Sifter. We just made up a bunch of numbers, threw it in a spreadsheet, and said “That looks good enough. Let’s try it.”
Des: And that’s what you did. It’s been really interesting to hear about the background, because Sifter is a well-known product but is so very far from being an overnight success. Five years of blood and sweat and hard work. I think you said there was an inflection point, possibly three or four years in, where you actually got back up to where your original salary was?
Garrett: I think just this year we finally gave me a raise and brought me back up to where I was. At the same time, I know just through conversations with other people that I’m still underpaid relative to what I could go make right now. That’s one of those things.
Des: Do you ever draw projections to see at what point will you be like well above where you need to be?
Garrett: You mean where I’d be compared to if I had just made a real salary this whole time? I haven’t. I think here and there I’ve thought about it for like 5 or 10 minutes. When things were tough, I’d really be tempted. “Why do I not have a regular job with health insurance and benefits?” You know, wow, that sounds so attractive. Ultimately I always realise that I’d rather do what I’m doing now than make more money, without a doubt.
Des: Yeah. I think it’s good you feel that way for the sake of Sifter’s users, as well.
Garrett: Oh, yeah, absolutely. Well, now it’s definitely getting on track to where hopefully someday in the next five years, the money won’t even be a factor at all. But even if it was a factor, it doesn’t bother me. I’ve never enjoyed working on something this much. You know, I’ve never had so much stress and worked so hard, but at the same time, I’ve never felt more fulfilled or more sure of the fact that what I’m doing is what I should be doing.
Des: That’s great to hear. Thank you so much for your time, Garrett. It’s been great having you, and I’ll be sure to link up your book and your product, as well, in the show notes. Thanks so much for your time.
Garrett: Great. Thanks for having me.
More from Garrett
Garrett is on Twitter, and keeps both a personal blog and a product blog, and even finds time to post great presentations on Speakerdeck.
