Episode 58
· 40:44
Justin Jackson here. Welcome back to Product People. I'm here in Edmonton for a week. Did the trip with the family. Supposed to be about a nine hour drive, I think.
Speaker 1:Took us about twelve. So three extra hours with the kids. Listen, we broke our record. There's no throwing up, no bloody noses, and no speeding tickets. So better record than last year.
Speaker 1:Feels nice to be here. Beautiful sunny day here in Edmonton. And this week's episode is with Garrett Diamond. He's the founder of Sifter, sifterapp.com, and he basically created this business by accident and, or at least he didn't intend to create a business when he started out, And he's got a really great story, especially about removing some of the romanticism that surrounds running a software as a service or a SaaS business. So he's going to tell it straight.
Speaker 1:Hope you enjoy the episode. And once again, here is Stryker.
Speaker 2:There we go.
Speaker 3:All right. So Justin Jackson here and I'm here with Garrett Diamond. Garrett runs Sifter at sifterapp.com and he's also the author of Starting and Sustaining, startingandsustaining.com. How's it going Garrett?
Speaker 2:It's going, it's going, how are you?
Speaker 3:I'm doing well, doing well. Glad you could make it today.
Speaker 2:Yeah, sure thing.
Speaker 3:Today we're going to talk with Garrett about basically how to find an idea, validate the idea and market the product. And I just need to turn off, I've got a live stream going somewhere here. I can hear myself in an echo. There we go. All right, so that's what we're going to talk about and hopefully everyone gets some insight out of it.
Speaker 3:We're chatting here live with JFDI members and they can ask questions in the Slack chat. Garrett, the first thing I want to talk about is there's a lot of people out there that would look at you and would say, You're living the dream because you run a SaaS app. And that's for a lot of folks that are consulting or maybe have a soul sucking job, that's where they want to get. That's the So I thought we should start, especially because your book is really about this, what are the biggest misconceptions that people have when it comes to running a SaaS business? Like once you started Sifter, what kind of surprised you in terms of like what it's really like?
Speaker 2:Yeah, mean the biggest there's kind of two things to it. One is you know, just like any other job, you know, there's aspects of it that are soul sucking in and of itself. You know, there's just running a business, there are going to be things that aren't fun. And, you know, if anything, if you just want to create stuff and write code, starting a business is not the best way to free yourself up to do that because you've got to do all the different tax things and in the case of an app, you're dealing with servers. So unless you particularly like dealing with servers or working with the SysAdmin, there's gonna be days where you're gonna be consumed by that stuff.
Speaker 2:And so it's not totally just fun. And then once the app starts to grow, then you've got issues where now you're trying to think, Okay, I've got this great release. I wanna push it out there. But you don't wanna disrupt users and so you don't wanna push out something that's so new it's gonna shake things up and ruin it for them and then people are gonna be lost and confused. You don't want to risk downtime, so you have to invest in making sure your processes are a little more resilient and that you're doing the little extra things to make sure that it doesn't go down and just that they have that seamless experience.
Speaker 2:So before you know it, you're just caught up in doing a lot more logistical things, that aren't necessarily fun but if you don't do them, it's gonna be a mess and people aren't gonna be happy. Yeah. The other thing is just that it never stops, you know, With, like writing, I didn't really realize this until I wrote the book. With writing a book, I shipped the book and it's done. And, you know, the first week I fixed a couple really minor typos and that was it.
Speaker 2:And since then, you know, it just exists. Pretty much it's done. With Sifter that's not the case. There's always something to work on and even if it's not customer facing like just improving our processes on the back end to make it easier to do releases or manage certain pieces of Sifter and that kind of thing. It's just it's a never ending type of thing and, you know, you think that, Oh, I'll be done and it'll be finished and it'll just sit there and rake in the money and then I'm gonna go live on a beach somewhere.
Speaker 2:Yeah. You know, it's not really like that. And so I don't think I ever fully had that expectation, but I certainly expected that I'd be able to do more coding and design and things that I enjoyed. More product stuff and less logistical stuff. So as we've grown, it's been a real big like priority of mine.
Speaker 2:The bookkeeping we pushed off to somebody. So we've got a great bookkeeper handling that. The SysAdmin we brought on somebody so he can do all that stuff. And so we're slowly getting there. I still kind of have to be involved in everything, but as time goes on, becomes more and more autonomous so that I'm able to just pull back and focus on product stuff and not get so bogged down in everything.
Speaker 3:Yeah, yeah, there is a real balance there, isn't there? In terms of like, you have to deal with people a lot. Yeah. Like customers, keeping them happy. And I've even found that as a product manager, there is always this balance between you might figure out something that will improve the product and bring it forward and especially help with maybe making things simple for you guys on the back end but also the onboarding experience for new users.
Speaker 3:But every time you have to then think, How is this going to affect all my current users? And there's this real balance between those two.
Speaker 2:And you you see that on larger scale with a lot of companies and from what I've seen, Apple is one of only companies that does that where they're willing to just throw things away to push the envelope forward and they get a lot of backlash for it. Yeah. And in their case, you know, guess Steve Jobs great. He's more insulated. He could do whatever he wanted and the worst he's gonna get is a couple complaining emails.
Speaker 2:Yeah. But ultimately everybody gets on board. But in my case, like if I were to push something out that's gonna upset people to move things forward, I'm gonna spend the next week answering emails and you know dealing with angered people and trying to work things out and fix things. So it ends up being what you think is moving something forward ends up being a huge distraction and kind of taking your focus off of thinking. And then, you know, it's kind of once bit and twice shy where you quickly become afraid to push anything new because you know you're gonna upset some people and that's just inevitable basically.
Speaker 2:So until you get to the point where you realize that and accept it and basically just work to minimize it as best you can and be ready to help those people when they are upset or frustrated or whatever, you know, it's kind of a daunting experience. You know, as the app grows and you've got that critical mass where everything you do now, somebody's gonna notice. It's not such a small app that you can get away with things.
Speaker 3:Yeah.
Speaker 2:So it kind of changes your behavior.
Speaker 3:Yeah. And actually, we're gonna get to in a moment, we're going to really focus in on Sifter and how you came up with the idea and all that. But right now I'm writing this book called Marketing for Developers. And one of the things that keeps coming back in questions and particularly I think in terms of what developers feel is this idea of critique and having people critique your work, having people complain about your work, having people ask for refunds and all that stuff. What's been your experience with that with Sifter and even I guess starting at Sustaining?
Speaker 3:Like how have you been able to deal with criticism?
Speaker 2:It's ebbed and flowed. There's a whole chapter in the book about it specifically because for me the biggest challenge is that criticism has a tendency to, so it's useful in the big picture, but at a micro level when you get, criticism, it's it's difficult to kind of separate it and think of it as this is only one person Because, you know, say you've got a thousand customers and one of them doesn't like a feature. Then you've got 999 that either don't mind it or don't dislike it enough to say anything. In which case, it's difficult. So you end up with this vocal minority issue where you wanna make them happy but they're also the only person complaining.
Speaker 3:Mhmm.
Speaker 2:And, you know, they definitely have their valid needs and interests but a lot of times to make them happy, you're gonna end up rocking the boat for the other nine ninety nine. But that one person is the one that's vocal enough and wants to have a diet. There's times where I've had people go back and forth with me and I'm like, look, that's gonna really anger people. I know because we used to do it that way. I'm not gonna switch it back because we got a lot more complaints and we switched it to this direction.
Speaker 2:So there's always gonna be somebody that's upset and you kind of have to take it in stride, listen to them, and understand it, but you have to avoid doing knee jerk reactions and being like, yeah, let me go change that to make you happy.
Speaker 3:And
Speaker 2:you know, I would say it's been a long time since I used to do that, but probably at least 50% of the time that I made a quick reaction to say, yeah, that's easy. Let me fix it for you. I would end up fixing it and then getting a complaint from somebody other side, why did you change this?
Speaker 3:Yeah.
Speaker 2:So you kinda have to realize that, you know, you don't wanna let it paralyze you because that's easy and I went through a phase where, you know, the criticism definitely paralyzed me because was like, well, I don't wanna make those people mad, you know, so you end up not doing anything which is that doesn't help. Yeah. But the biggest thing is just to understand it, you know, have the context, factor it in, but don't necessarily just make a quick knee jerk reaction. And a lot of times too, the other thing is, and don't know if this is just a function of Sifter being a developer focused tool, we don't people don't describe their problems to us. They email us and tell us what they want us to build.
Speaker 2:And a lot of times, it's very difficult to see through the request and understand what their real problem is. And so almost as just a, you know, everything that comes across, I'm like, alright, great. That sounds interesting. Can you help me understand why that would help you or how that would help you? And then at least half the time there's an existing feature that solves their problem better than what, you know, they described and the other half the time it kind of just varies but there's, there's usually an easier solution to build than the one they built, or the one they described because that's just what they're used to thinking or they've seen elsewhere.
Speaker 2:So they're thinking in terms of the feature not the problem. And so you have to really kind of dive deeper on criticism a lot of times to say, you know, they're not criticizing the app, they're ultimately trying to describe a problem they want to solve and you have to kind of swim around all that and synthesize an idea that really solves the problem, not that just does what they ask you to do.
Speaker 3:Yeah. The other thing I thought about quite a bit is, and you mentioned this, but like one person who talks to you, these are human beings and they have stuff going on in their life and it's hard because I'd say I maybe have a thicker skin than most but someone emails me. I sent an email newsletter last week and someone wrote back and said just over and over again something like, I hate this, this is spam, spam, spam, spam, spam, over and over again. And I'm like, Man, this guy's really angry. And then I went into his history and he'd opened and read like 10 newsletters and this was like the first one he was complaining and I'm like, What is going on here?
Speaker 3:And then I found his blog and he was just talking about his life and he was going through some stressful stuff, like So really I mean maybe he honestly felt like I'd been sending him spam and it had been upsetting him or maybe he was just having a really rough day and he decided to send me that email. So I think we have to keep that in mind.
Speaker 2:That's almost always the case. There's always something below the surface even though all we see is what's on the surface especially via email. You don't hear tone of voice, you don't see a face, you can't pick up on facial expressions and, you you don't necessarily realize it but that's such a huge part of human communication that gets completely evaporated in that context to that. It's very difficult to communicate effectively via email, you know. And you don't wanna go overboard and be, you know, too nice and kind of almost fake, but if you under do it, then they misinterpret things because you were terse or whatever it is.
Speaker 2:And so it's a tough line to walk especially for me all of my customer communication is via email. Almost never end up talking to somebody over the phone or Skype or whatever. And a lot of times it's just incredibly difficult to kind of toe that line and and really do a good job answering emails or just communicating period.
Speaker 3:Yeah, there's a habit I want to get back into that was recommended to me by an old boss which was, we always like that email, even though I said like I've got a tough skin like that bugged me. It kind of dragged me down. And we always get dragged down by one person can say a rotten thing to us and we're feeling bad. But it's easy for us to forget about the times where people encouraged us or were excited about the app or whatever. And my boss's advice was you keep a folder in Gmail that's just called encouragement and every time you get a nice message, just slap that in there.
Speaker 3:And When I was doing this it was really helpful because if I did have a bad day could go back through these emails and go, Oh, I'm not a complete schmuck. There's some people that are getting value out of what I'm doing.
Speaker 2:Yeah. I could definitely see that being helpful. I've I've got a bunch of tweets favorited. And so every now and then, you know, I'm totally beat down like, Oh my gosh, what am I even doing? So this is the worst product in the world, I should just quit.
Speaker 2:I can go back there and read that and you know, kind of go to those favorites. I'm like, yeah, that's right. People like it. People are getting value out of it.
Speaker 3:Yeah. How you deal with that at the beginning? Because like when you build something at the beginning, it's not always really polished.
Speaker 2:How
Speaker 3:did you deal with that initial thing?
Speaker 2:I don't really know. I think in the beginning most of the complaints were so obvious and like we launched without search, without file uploading. The things were so fundamental and there were things I knew I wanted to build. It just rolled off because somebody's like, you need file uploading. I'm like, you're right.
Speaker 2:I'm working on it. Or you know, you don't have search? That's ridiculous. You're right. I'm working on it.
Speaker 2:And so it was a lot easier because I knew they were right. Like there's no doubt about it. We needed that stuff and because that was the stuff that was so glaringly obvious, nobody was nitpicking anything else because they weren't gonna look past the fact that we didn't have file uploading or search. So the feedback just kind of ended at the really obvious things. Whereas now as it's gotten a little further along, the things are a lot more subtle and the, you know, definitely subtle and very opinionated.
Speaker 2:Meaning, new opening links in new windows. We get this a lot. Everybody's like, we want you to open links in new windows. Like, well, if we do that, then you can't not open links in new windows. You're you're kind of forced to.
Speaker 2:And so we don't wanna force people to do anything. You can just, you know, and then we try to teach people, oh, just hold down the command button or whatever it is on a PC.
Speaker 3:Yeah.
Speaker 2:And then you'll open a new window. They're like, Well, I forget to do that. So now, one of the things we're actually working on, the biggest complaints is people, and this is where, you know, they always and we get that request a lot. And, you know, the more I've talked to people, the more I've realized what it is is they're typing a comment and they click on the link expecting it to open in a new window and then they lose their comment.
Speaker 3:Gotcha.
Speaker 2:So instead of opening links in new windows, we're working on using local storage and that kind thing to just save the comment transparently in the background, hold on to it for twenty four hours or whatever. So that even if your browser crashes or whatever, we're gonna hold on to the content for you so you don't have worry about it. And like doing those little things that you hear them complain about one thing but the problem is really something else. Yeah. And so trying to find something that fixes the problem is less obtrusive, know, that kind of thing has been more where Well we're at these
Speaker 3:and this gets back to in a way what we were just talking about about human beings. Human beings are not very good at communicating, first of all, what their problem actually is and then having any sort of idea in terms of what would solve it. And you see this over and over again. People will call up where I work and say, Here's a problem we're having. Usually you're right, it'll be like, Can you do this?
Speaker 3:You really have to dig down and say, Okay, well why does this person want this? And it takes some research. You actually have to see what they're doing, not what they're saying if that makes any sense. And usually when you kind of dig down deep, if you keep asking questions, you can figure out, Oh I see what's going on here. And I think that's an important distinction.
Speaker 3:Really got to be careful about valuing too much about what people talk about as opposed to what they actually do.
Speaker 2:Yeah, absolutely. Well that's a common thing from usability testing is you don't want to listen to what people say they do, you want to watch what they actually do. Mhmm. And then you'll be able to notice and pick up on a lot more subtle key interactions.
Speaker 3:Yeah, exactly. Well let's get into Sifter. Talk about you came up with the idea, how you validated it, who's your customer, all that kind
Speaker 2:of stuff.
Speaker 3:So let's start off with, I heard originally Sifter was gonna be an open source project. So maybe just tell us how did you decide to build this and make it happen?
Speaker 2:I had wanted to, so I'll just go all the way back. When I first got out of college, I got a job at Sapient doing consulting on really big projects and basically from the first project just by chance ended up seeing really good bug tracking processes, code freezes and you know, testing, fixing cycles and everything and they had it down to a science. They really were doing it well. So basically I immediately learned good good practices for testing. Then that was right around the dot com bust and I ended up getting laid off about eleven months into it.
Speaker 2:And so then, my next job I went to, I went there and there was a company that had hired a consulting company to build an app. And I was gonna be coming in and taking over and working on the app. And I think like within the first week I asked them, I go, Okay, this is great. So I'm testing it. Where do I report bugs?
Speaker 2:They emailed me a PDF. They said, Print this out. Fill it in and fax it to us. So you know, I'm thinking this is a technology company and you want me to fax a bug report?
Speaker 3:Yeah.
Speaker 2:I was like, don't you all have a bug tracker? Like an online bug tracker or something where I can fill things in? They're like, no. You need to fax stuff. I was like, so how do I follow-up with stuff after the fact?
Speaker 2:How do I know if you fixed it or, you know? Yeah. And from that experience, was like, wow. Okay. There's gotta be sure there's something out there.
Speaker 2:And this was back in, I don't know, 02/2001 and there really just wasn't much stuff available. So from that day, I was like, just fascinated by bug tracking in general. I was like, How can every company in the world not have a bug tracker? Like, you just got to, you know, especially if you're working with clients. And so I just, for some reason, became oddly fascinated with bug tracking.
Speaker 2:Fast forward a few years, was still doing consulting at different places and trying a bunch of different bug trackers, issue trackers, all the different things. And none of our clients would use them. Everyone, you know, we'd try one and our clients would log in once, They'd be like, Okay, that's cute. And they would just never log in again because they didn't get it. They didn't understand.
Speaker 2:And there were, you know, there's just stuff that was too intimidating and overwhelming. And so I was like, You know, I wanna build a bug tracker. Who doesn't? Every developer in the world's like, Oh, I'm gonna build a bug tracker. That's what I'm gonna And in hindsight, I kind of regret it.
Speaker 2:But I'm so just fascinated by issue tracking in general that it works. So then eventually, you know, I'm doing consulting. Everything, all my work I ever did was covered by an NDA. And so, like, I like to blog, but I couldn't talk about anything I was working on ever. This drove me nuts.
Speaker 2:Was like Yeah. Because to me, kind of talking about it and sharing it kinda really forces you to dig deeper and understand your own motivations and, you know, then other people can benefit from it. So it's just cool. Finally said, You know what? Screw it.
Speaker 2:I'm just gonna design and build something that's mine and nobody can tell me I can't blog about. So I just started designing an issue tracker. Looking back now, was really rudimentary stuff, but some of the ideas and the things that I was emphasizing were just because I was really obsessed with simplicity. And most issue trackers at the time were developed by developers who are all about features. So it was kind of a different take on issue tracking.
Speaker 2:And I started blogging about it and sharing it just for the hell of it. Like, was like, oh, maybe I'll open create an open source app. Didn't even know if I would ever get to development. I just wanted to design it and share it. And so I was like, yeah, I'll just open source this.
Speaker 2:And the more I started writing and sharing and talking to people, a couple people, the more good positive encouragement I got. And a couple people are like, do not open source this. If you do, you'll build it for a year and then you'll drop it and never maintain it again. Like, you'll go nuts, you'll hate it. You need to create a business out of this.
Speaker 2:I was like, no. No. No. I I wanna create a business someday but I'm not ready to create a business. Over a month or two, they wore me down, and, you know, here we are today, with Zifter.
Speaker 2:And basically, if I hadn't been sharing and blogging and doing all that, nobody would have ever even known about those ideas in my head and I never would have gotten the encouragement to kind of take that jump and do it.
Speaker 3:Yeah, yeah there's a few things I want to dig in here, dig into here. The first was there was something that struck me when you're talking, you said none of the clients you were showing existing bug trackers to would use it. So and you talked a little bit about it but what was it, like what was in their way? Well,
Speaker 2:most bug trackers, you look at especially like the open source ones that were kind of the dominant ones at the time like Mantis and Bugzilla, they're ridiculously powerful. And with that kind of power comes a lot of configuration and understanding and knowledge that developers have, but a normal person running a business that does, you know, they don't use computers beyond Microsoft Word and Excel, for them it's just an overwhelming nightmare. And so for them to log into something like Bugzilla, or any of those things that existed at that time, they would just be like, I do not belong in here and just hightail it out of there and never come back. And so it would take just too much effort to get participation. And on, you know, a small project with like three or four people where bug tracking is really helpful, you know, and there's a couple clients and you want them in their testing and, you know, kind of reviewing the work, it's just great.
Speaker 2:Otherwise, what they're gonna do is email you. And then you're gonna end up with bugs spread out throughout email threads, and you can't keep track of them. You don't know whether they're fixed or anything like that. It just becomes a nightmare to keep up with, to know what's done, what's not done, who's working on what. Yeah.
Speaker 2:And you know, without our clients participating, it really didn't matter that we, you know, that we didn't use the bug tracker because we were in email. Because our clients were in email. And so then it was like, well that's kind of defeats the purpose of having a bug tracker if we're not gonna use it with our clients. And so, know, Sifter for instance, totally it's too simple for any huge large team doing anything significant. But there's so many people out there doing small apps or you know, implementing a, you know, advanced site on top of a CMS like WordPress or something like that, where you're not doing, you know, really extreme development.
Speaker 2:You're you've already got it. You're just customizing WordPress, you know, maybe extensively, but you don't necessarily need like a really advanced highly configurable bug tracker. You need your clients to get in there and participate and use it with you. And so our philosophy was just keep it simple so that, you know, customers and clients and non technical people wouldn't be scared away. And, you know, in some ways we've even got more complicated than I would like and we're working on kind of re simplifying and scaling things back down to be less intimidating and overwhelming than they are.
Speaker 2:And, you know, it's just too it's so easy. It's such a slippery slope to keep adding features and adding complexity to where the tool gets so intimidating. A normal person just doesn't feel welcome in it.
Speaker 3:Yeah. Well this is a good segue now into who is your actual customer? Like who is actually buying the app?
Speaker 2:It really varies. Mean we've had all sorts. I would say probably the most common if I had to pick would be like mid size agencies of 25 ish employees doing three or four projects at a time. Those projects are, you know, if I had to guess, probably like the 10 to $100,000 range. Know, So smallish projects that are teams of total including the client like eight to 10 people and just spread across a medium sized company.
Speaker 2:Now we've got a lot larger companies using it. We've had smaller companies like Sifter's overkill. If you're just one or two people, it's almost overkill. In that case, like just a to do list is better. It's overkill for us to use internally even.
Speaker 2:Yeah. And so, you know, it's just all we even had at one point a karaoke bar used it with their bartenders and management to keep track of things. Like they're not using it anymore, but for at least, I don't know, like three or four years, they were using Sifter to keep track of stuff. It's almost
Speaker 3:I love that.
Speaker 2:Yeah, it was crazy. Once I, you know, talked to them randomly one time via email and found out they were a karaoke bar and was like, how you using Sifter exactly? Like, you know, and I figured maybe they had like a software product that managed something, I don't know. Sure enough, they were just using it with bartenders and managers.
Speaker 3:Yeah, yeah. And do you get a sense of Is there a particular person in those small teams, like a particular type of champion that's saying, We gotta get this and then contact you? Have you noticed any trends there?
Speaker 2:Not really. They kind of vary. So project managers who generally end up not liking Sifter because we don't focus on reports. Because my philosophy is kind of, you know, Sifter is not designed for teams that need project managers. It's not designed for a team of 25 people.
Speaker 2:Can use it, you know, if your team is that large, you're probably doing something complex enough that Sifter is not right for you. Some people like Sifter enough they fight through that, but, project managers in general, unless it's like a project manager that's managing like six projects and, you know, needs to synthesize all the different projects, then it's a good fit for them. But they'll come in and they'll have their own desires. A tech lead might come in, but any of the more technical people, a lot of times, unless they've run into the issue where their business stakeholders aren't using it, aren't using their existing tracker or whatever. Yeah.
Speaker 2:They're saying, Sifter is too simple. I don't like it. But when it's kind of the hybrid designer developers come in, it's like, this is simple. People will actually use this. They definitely will kind of champion it more.
Speaker 2:But ultimately the people who realize and recognize that if your tool is too complicated, your non technical people won't use it, those are the people that show up and they're like, Oh my god, this is a lifesaver. I didn't have to train all of our customers. I didn't have to do this kind of stuff and those are the people that fall in love with Sifter.
Speaker 3:Interesting. I've been noticing a trend because originally I thought it was just me but with product managers often being the champion for bringing in software to their team because they're the ones sitting right in the middle of design development customers and the business side. Have you noticed that too?
Speaker 2:Yeah, I mean we've got a fair amount of product managers. I think probably since we have more agencies because Sifter is kind of set up to be a little more client, more structured around clients, although that's kind of evolving. We certainly have a lot more agencies in which case there's not really a product manager as much. But the product manager I would say is almost in that kind of hybrid location where you're dealing with customers and non technical people, business stakeholders, designers, developers. So you're kind of stuck in the middle as a product manager where something like Sifter is great because it gets everybody on the same page.
Speaker 2:But like, we've had a lot of customers cancel and then come back six months later and say, yeah, nobody would use the new app we switched to. Like the developers, you know, they're like, we cancelled. Our developers wanted to switch to this and they switched to it and then, you know, six months later they come back and they're like, yeah, nobody was using the other app. That's a validation. It will it is.
Speaker 2:You know, it's not like that for everybody. It's really issue tracking is such and I think this is really the case with almost all software, but with issue tracking especially, because developers are so used to being able to build something. It's very much kind of Goldilocks and the three bears. Like this porridge is too hot. This porridge is too warm, you know.
Speaker 2:Yeah. It's kind of like finding the right one that's right for your team, your technology stack, your release process, your workflow. And, so many people, you know, I guess they fail to see that it does have a lot to do with your team, the size of your experience and background of your team and the priorities and people think that, Oh, I should just be able to pick a product. And so can you find a product that's right for your team, not just a product that you kind of like on the surface or that kind of thing.
Speaker 3:Yeah. So have you found Do you market to developers or not really?
Speaker 2:Well nowadays we don't market at all. We did some advertising in the early days and we haven't done any advertising in a long long time. A year and a half maybe two years, I don't know. It's it's been a while. And we might come back to advertising, after we make some big updates, but for the most part, you know, I'll blog on our site and you know, that's probably the closest thing you could say for marketing that we do.
Speaker 2:I mean there may be other stuff that I do and don't realize it, but
Speaker 3:How do people hear about it then?
Speaker 2:I don't know. You know, we get a decent amount of traffic
Speaker 3:and Where's that traffic coming from? Is it targeted keyword?
Speaker 2:It's all over. We don't we don't have any single particular like refer that is just killing it for us or anything like that. It's just, a lot of think, you know, probably think a lot of word-of-mouth, because the people who like like it really like it. And so there's a there's a lot of like mindedness where, you know, you can't just blindly say, hey, check out Sifter because it may not even be right for that that person or that team or that company. So I think a lot of it is people who have similar priorities and kind of gravitate towards each other and there's word-of-mouth.
Speaker 2:A lot of times what we have too is a client will use it with one of the agencies and then when the project's over the client wants to spin off their own account. That happens a lot. So we get a lot of exposure and I mean if I had to guess I would say it's really all that way. The people use Sifter and then want to start their own account and that sort of thing. And there's a handful of other places as well, but for the most part I think it's really it's almost got to be word-of-mouth because we're not actively doing any marketing.
Speaker 3:Yeah, well and I wonder if there's something about this idea of because you said you were originally working with a company that was doing issue tracking right and then you were doing consulting and you're seeing all these different environments. It almost seems like you have to sometimes have had that experience to know because the issues that you brought up are not some things that you might be able to just kind of think about out of your head.
Speaker 2:You don't know until you feel that pain.
Speaker 3:Yeah. And the other thing I'm thinking about is that with word-of-mouth, if you've never worked for a company and have never taken the time to observe that, there's so much about product development that's just observing the way people kind of act. And you'll notice like when people talk about a product, you know, so like you'll be in a big team meeting and you've got this problem and it's like maybe it's a big client meeting and it's like, Okay, well no one's using our bug tracker. And then someone from the other side of the room will say, Well I used this product on my last job. And those moments seem to be pretty key in terms of how a product actually gets spread.
Speaker 2:There's certainly a lot of that and a lot of the emails I get, it's people saying exactly that. Like I used to work here and we used it and now I work here and we use it. You know, I brought it here and you know, showed it to this team and they loved it. And so it totally is that. Feel like maybe we're missing out but at the same time I feel like we can't do marketing and tell people, you know, if people aren't using your existing app, you need to switch.
Speaker 2:Like, people have to realize that for themselves. And so we don't compete on features like we're probably the most under featured app out there. And, you know, some people hate that. They'll they'll use it for a year and they'll be like, alright, you really need this feature. It's like, you know, and and we end up deciding against a certain feature or whatever.
Speaker 2:And it's it's it's challenging because we can't create a feature checklist of the benefits of simplicity. You either appreciate simplicity and the benefits or you don't. And if you don't appreciate it or value it, we're not gonna be able to sell you on It's just it's not right for you. And I think a lot of people, know, when they don't appreciate simplicity or they don't, you know, like our philosophy, then it's it's it seems like it's less about, oh, okay, you know, I I can understand that's not for us. But it's usually like, we get a lot of like, that's stupid.
Speaker 2:Why don't you just do what I ask? You know, and, I don't know. It can be frustrating at times too to kind of try to do less features and do them better. Like right now we're circling back and trying to improve a lot of features that exist, but that we feel like we didn't do well enough the first time around. So we're kind of making enhancements to them and that sort of thing.
Speaker 2:And we really just want those things to work and work well rather than add on a whole bunch of new stuff. I feel like I'm getting off on the tangent here.
Speaker 3:No, no, but I think what you've brought up though is important, this idea of building something that's opinionated and kind of sticking to your guns. And you know, my buddies at Base Camp now, they get into this all the time. People criticize them all the time for this is also why you can't always pay attention to what people are saying at Hacker News and Designer News and all those things. People just like slag them forever about being too simple like I could build this in a day. But what they're missing is those team meetings or those coffee meetings or those whatever or those I'm messages I get from another product manager saying, Hey, what do you use for project management?
Speaker 3:Those are the keys and how people are sharing it word-of-mouth is the key. It's usually because of an experience. I use this and we've had the same thing with bug tracking like we've gone through fog bugs, we've gone through, we tried to use, what was that, just a big string of them.
Speaker 2:There's a lot, yeah.
Speaker 3:And like literally five or six and finally we found we're using sprint.ly now and I will talk to anybody about sprint.ly, you know what I mean? And it's the same thing with Sifter. People, if they've used it and they appreciate it and they see the value and the simplicity, they're gonna share it and that's really kind of the best marketing you can get.
Speaker 2:Yeah. Jason, one of my favorite Jason Fried quotes, I think it was him and not David, he said, Yes is easier to say now. No is easier long term.
Speaker 3:Yeah.
Speaker 2:Right? So if somebody emails and ask for a feature, it's gonna be a lot less painful to go, yes, we'll build that and then build it. Long term, it's gonna be a lot more painful.
Speaker 3:Yeah.
Speaker 2:So really kind of recognizing that and appreciating that is is difficult to do, because you really do. People email, it's like, I wanna make you happy. I want to do what I can. I can't do that because that is going to make other people unhappy. Yeah.
Speaker 2:And it's it's tough to juggle that, and a lot of people, you know, they really are bothered by it almost. And it's tough to, you know, know that you're actively upsetting someone in order to say people who are quiet. You're not gonna hear them go, Hey, thanks for not adding that feature. It's really tough to do, kind of day in and day out and not just almost go crazy in some ways.
Speaker 3:Yeah. It's almost more interesting. We never think about this, but the people that are just quietly using your app are probably a lot more interesting than the people making noise because they're happy. And for all you know, they just had coffee yesterday and they recommended it to a friend.
Speaker 2:Yeah.
Speaker 3:I think that's a good place to leave our conversation. We've been on for an hour now and I respect your time. Thanks Garrett so much for joining us.
Speaker 2:Of course.
Speaker 3:It's really awesome. You guys can check out, first of all check out his book for sure. I've talked to so many people that looked at especially the Numbers spreadsheet and said like people like Amy Hoy and others that said, If I'd had this at the beginning it would have saved me hours and hours and hours. So check out startingandsustaining.com and check out sifterapp.com. Anywhere else people can find you on the net?
Speaker 2:Garrettdiamond.com.
Speaker 3:Garrettdiamond.com for the blog. Perfect, thanks again Garrett.
Speaker 2:Yep, thank you.
Listen to Product People using one of many popular podcasting apps or directories.