Full Transcript for 272 - Anthony Eden, Founder of DNSimple
People
Get the key moments without reading the whole transcript
- How Did Dnsimple Replace a User-equals-account Login With a Many-to-many Relationship So One User Can Reach Many Accounts?23:23
- How Did Shape Up Framing Retrain Dnsimple Engineers to Describe the Problem Before Designing the Feature?38:07
- Why Does a Move From Zero Customers to Ten Need a Different Strategy Than a Move From a Hundred Customers to a Thousand?47:07
- Why Does Selling Without an Internal Champion Force a Much Bigger Marketing Budget to Reach Buyers and Gatekeepers?58:07
Full transcript
Speaker 1
Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that, keep in touch.
email newsletters are a really nice way to keep on top of what's going on in the programming world, except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen You sit there and stare at the screen, some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter.
That's right. I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed, or in someone else's bed. And when they say, what are you doing in my bed? You can say, I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter.
You can read about all kinds of programming topics, like object-oriented programming, testing, DevOps, AI. Most of it's pretty technology agnostic. You can also read about other non-programming topics, like Philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics, and farming.
The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler from Los Angeles says, Thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary.
I'm sure that's what you were going for, so just wanted to let you know that you succeeded. Looking forward to more.
Drew Bragg from Philadelphia says, Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it, and sitting down to read it on paper that is just so awesome. Feels like a lost luxury.
Chris Sonnier from Dickinson, Texas says, Just finished reading my first Nonsense Monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at nonsensemonthly.com.
That's nonsensemonthly.com. I'll say it one more time, nonsensemonthly.com. And now, without further ado, here is today's episode.
Hey, today I'm here with Anthony Eden. Anthony, welcome.
Speaker 2
Hi, thanks for having me, Jason.
Speaker 1
So you're the founder and CEO of Dien Simple.
Speaker 2
That is correct.
Speaker 1
Yeah, so a lot of people listening to this are probably familiar with Dien Simple, but tell us about Dien Simple.
Speaker 2
For those who don't know us, we are a DNS provider and domain registrar, so we provide authoritative DNS, domain registrations, transfers, and renewals, and we also provide SSL certificates. And we've been in business now for fifteen years.
I started the company with my brother back in 2010, originally just focusing on the DNS side of it, started in, so I wrote the first line of code in April of 2010, launched at RubyConf in July of that same year, and then, proceeded to add domain registration also towards the end of that year based on feedback from people that I knew on Twitter and, and from my networks who said, wow, I really, we really want to be able to register domains too, so we added that, and that's kind of been our Our mode of working since then, right, is just focus on domains, DNS, building tools around that, really for developers and for other engineers, and just be a very specific niche, serve
that niche well, and it's resulted in a pretty successful little business.
Speaker 1
so something I'm definitely curious about is like, a, a domain, I don't know, what, what do you, what, what label do you put on it? Like, it's not a domain registrar, is it like, how would you describe it?
Speaker 2
So we are a domain registrar, and what that means essentially is that you have accreditation to sell domains to the general public, and you get that accreditation through an organization called ICANN. And so, we've done that, and then we also resell domains because for each top-level domain, so .com, .net, .org, plus all the other ones, you need a separate accreditation with the registry, so that's the group that actually manages the database for that TLD.
And so it's kind of cost prohibitive unless you're selling a lot of a particular TLD. So sure, it might make sense for com or net, which are going to be the majority of your sales, but you might have these random country code TLDs, and getting accredited with each one of them is very expensive, so in terms of time and also just, investment.
And so what we do is we resell some of the TLDs, as well. So it's kind of a... You're, you're still doing the same thing, you're selling domain names or allowing customers in the general public To register domain names through your service. and, it's just in one case you're doing it through your own accredited credentials, and in another case you're using some third-party provider that does that.
Speaker 1
Got it. Okay. Yeah, and I, I understood that DNSimple has domain registrar capabilities. I just wasn't sure that it's appropriate to say, like, DNSimple is A, and then fill in that blank with, I'm not sure what would go in that blank.
Speaker 2
Yeah, we are a domain registrar, we are a DNS provider, and we are also a domain reseller.
Speaker 1
Okay, got it. So
Speaker 2
that, that's kind of the, the, the areas that we can say we are definitely those things.
Speaker 1
Okay. and whatever you call that group of those three things, it's obviously not just like a straightforward CRUD app.
Speaker 2
No, definitely not.
Speaker 1
Yeah, and, and from a technical perspective, I think that probably takes a lot of like specialized knowledge and, a lot of, I imagine, crazy programming to get all that stuff to work. And so like in the, in the beginning, when you approach this thing, I think a lot of people would have been daunted by the prospect of doing something that's so, not straightforward.
And so my kind of two-part question is like, maybe it's just a one-part question, like, like why this? Like what led to this specific thing? What made you feel like you could do it? That kind of stuff.
Speaker 2
So I have actually been in this industry for quite a while. in 1999, I worked for one of the first seven domain registrars when the dot com TLD was deregulated. So prior to that point, it was run by a single company. That company was Network Solutions. They had the full rights to manage the entire domain and sell those to the public. In 1999, they accredited seven registrars, and I was the CTO at one of those registrars, and proceeded to get into the industry through that job.
Then throughout my career before DNSimple, I off and on kept coming back to domain names. I ran the dot MP registry, which is the Mariana specific islands, and so I ran that registry and that registrar, both the customer fa- like the consumer facing as well as the other registration facing side of it. And I, during this process, I also learned a lot about the operations of DNS itself.
So that, so DN, DNS and domains has kind of two sides. It has the intellectual property side, which is really domain names and ensuring that those are registered to the right entity and that they are renewed regularly, so on and so forth, and that they're protected. And then the other side is the operational side, which is, which is the authoritative DNS, the DNS resolvers.
That's the thing that we actually use when we use a web browser and we go to a website and it looks up a name to determine what the IP address or addresses are that it should go to. And so throughout this, I learned a little on both sides. and I kept coming back to it, and in 2010, I was wrapping up the sort of Or winding down, I would say, the startup that was built around .mp because it didn't really take off the way we'd hoped to.
And I was using, and I'll say it, I was using GoDaddy at the time, and I was like, oh, the DNS side of this is terrible. Not to mention the registration side at the time. What are you talking about?
Speaker 1
It's great.
Speaker 2
Okay, it's funny. So at the time, it was really, really bad. They were doing a huge amount of business, but the DNS side in particular was pretty horrendous, because that wasn't their focus. Their focus was get people in, registering domains quickly, upsell them on different products, including web hosting, things like that. And I was like, I just want to focus on the DNS side.
So I started just doing that, and I had already written at that point two DNS servers, two authoritative DNS servers.
And so I was like, okay, I know enough about the operations that I think I can do this. as I mentioned, I started the business with my, with my brother, though, and he's actually the one that set up the infrastructure. So initially we were running open source DNS software, because there is authoritative DNS software that's open source. We were running that on single VPS servers.
So these were virtual private servers that were running for twenty bucks a month. We ran four of them. we ran a, a network that was, it's called Unicast, so that means every IP address is mapped to only one single name server, and that was the start. So it was really a very minimal setup. And the Rails app talked to a database, and it pushed into a database that those name servers used directly.
So it was surprisingly simple conceptually. It grew very quickly beyond that because there are scalability issues with Unicast, there are scalability issues with virtual private servers, and, and we knew that we were going to have to do more than that. So we eventually started moving to managed hardware, started moving to what's called an Anycast network, which is where a single IP address can actually, go to many different machines.
and so there was all kinds of changes that occurred over time, but it started off pretty simply, actually.
Speaker 1
Interesting. yeah, okay, so part of why I'm interested in this stuff, one reason is because I've always been interested in going, like, further and further toward, like, the bare metal, like the smaller, more fundamental building blocks of the internet.
and just like when you type in a domain name in your browser and hit enter, like what happens exactly.
another reason why I'm interested is because I'm building a product. It's a, CI platform, which is also very much not just like a straightforward CRUD app. and, and one thing that I like about this idea, I don't know if you had the same feeling about what you did, I'm curious if you did. something I like about my idea is it's kind of a moat in that it's, you have to be kind of insane to go after it.
like, I don't think building a CI service is something that would even occur to most people as like a realistic undertaking for a solo dev. and I wasn't even sure how viable it was, but I, I headed down the path, and turns out it's not that hard. At least, you know, I've been programming for twenty years, and so I have some, somewhat of a boost from that, and then AI has been helping a ton, and, and that shortened the Path a lot, too.
but I'm like, this is great, because, like, I don't think a lot of people are gonna follow me and try to, and try to beat me at this, not that I, not that I was very afraid of that anyway. But for you, was that part of your thought process at all? Like, this is something that, like, not a lot of other people are gonna go after?
Speaker 2
I would definitely say the, that running an authoritative DNS service didn't seem like something that a bunch of, a bunch of people would go, I wanna do that, right? I mean, cause it, you're talking about 24/7, 365 operations, can never go, you can't really go down. You're talking about something that is core and fundamental to the, to the internet, and so you have to have, I think, a good long-term drive to make it work and then keep it working.
You just can't just go, oh, this didn't, you know, at least maybe early on we could have, but even doing that, once people start using it, they're depending on you. And I think that made me feel, okay, maybe not a lot of people are going to do this. At the time, I think also there, we were at a transition phase where there was a lot of old guard, right? So there were a lot of companies that had already been around for 10 years doing authoritative DNS, doing domain registration, and they had, they were kind of set in their ways.
So I think a more, for me, the motivation wasn't, well, I have a moat, it's that I didn't think that they were doing a very good job, and that was broadly. Like, I didn't, I, I think across the entire industry, it felt at the time that things had kind of stagnated, and I was like, let's shake this up a little bit. Let's take away all the crud, the junk that has been associated with domain registration, that's associated with managing DNS, and trim it back to its most basic possible use case and experience.
And so that meant, for example, registering a domain name, I dropped a bunch of the things that you would normally collect, so, so it used to be, and I don't know how many folks remember back then, they, and some still do this, but it used to be that you have to go through and fill out who you wanted the administrative contact to be, who you wanted the billing contact to be, who you wanted the technical contact to be, who you wanted the registrant to be.
Even if they were all the same person, you'd have to do it over and over and over again. I was like, well, that's a waste of time. Let's just collect one and just assume for now, that's the same, the same entity is going to do all these things. And it got us surprisingly far. You know, it's like, it, it just, the, the distinguishment, the distinguishing factors between those contacts wasn't enough for the vast majority of our customers.
They just didn't care. Same thing with setting up name servers. Instead of forcing everybody to pick what name servers they were going to use when the, when we registered, we just said, well, let's just use our name servers and make them work right away. So you just, you use it, and then you're on the interface, and you start setting it up.
or I want to connect to specific services. So at the time, you know, Heroku was, was an up-and-coming service. Lots of people were starting to use that. There were other services that people were using for building web pages. So, well, let's just make it so that you have a one click and you create the DNS records. So I think a lot of it was just driven by an opportunity to innovate a little, not to mention the fact that none of those services had APIs that were worth a darn, right? And so all of these were factors, and they corresponded well with kind of where the web apps were going at the time.
GNSimple's written in Ruby on Rails for the front-end application, and at the time there was a lot of energy behind Rails of have a, have a UI but also have an API and make them both functionally cover everything that you're going to be doing. And so I went in with that mindset when I started working on the API as well. And again, I think this was just looking at the competition and saying, there's a lot of opportunity here, they're not really paying attention, so let's go do it.
And it worked.
Speaker 1
Yeah, yeah, that's great. you might call that something like a, revolutionary application of common sense. Like, everybody else is doing it in a way that's like, I don't know, I call it reaching over your, reaching over your shoulder to scratch your ass. It's like going through all these extra steps for like no good reason whatsoever, and it's like, obviously, clearly, it would be better to do it this way instead of this way, and yet nobody's doing it.
That's how I feel about the existing CI providers.
Just GitHub Actions and CircleCI. what's the, like, main reason a CI service exists so that when a test run fails, you can see what went wrong? It's like a you-had-one-job kind of thing, and when a test run fails in those products, you have to, like, go through several layers of stuff and then scroll manually, and it's like, hey, you're a computer.
Like, you could have done this job for me, but you're making me do it several times a day, and this is just so dumb. So my, revolutionary application of common sense was that when a test run fails, it shows you what failed.
Speaker 2
Imagine that.
Speaker 1
Yeah, exactly. yeah, and my, you know, that, that, that thing about a moat, Definitely ranks low on my reasons for doing what I'm doing. It's more just like a frustration or even contempt for the way that the other products do it. And something I've noticed, and I'm sure you've noticed this too, is that the, the risk of one of the incumbents improving so much that they beat you is negligible.
Speaker 2
Correct. Yes, that is absolutely the case because there's, they don't have a financial incentive to do so. They actually have a financial incentive to remain stable because they have a customer base that has a set of expectations. And if you have a customer base that has a set of expectations, you can't just keep changing your system because you're going to make them frustrated because they have a set of expectations.
And if you don't live up to those, you're in big trouble. I do think that there, the bigger risk is, is that new competitors come along, and in fact, we saw that in our industry when DNCibles launched in 2010.
Amazon wasn't in the DNS business yet, Microsoft wasn't in the DNS business yet, Google wasn't in the DNS business yet. So you're talking about three, like the three, you know, 800-pound gorillas all joining in at a later date. And so that clearly is a factor in, in what we saw in terms of our growth. Those companies come in, and it, it becomes much more difficult to go after a certain class or a certain type of customer.
But what's interesting is that there's still, there was still a lot to go around. Not everybody wants to use one of those services for a variety of reasons, right? And then even more recently, some people want to use All of those services, maybe not for DNS or maybe for DNS, but they want to be able to have some diversity in their, in their cloud infrastructure.
And so we started looking at that and said, well, let's adapt our system so that we can look into those different infrastructures and see them all together. And that actually resulted in what we call the domain control plane, which was this idea that you could connect to Amazon and you connect to Azure, and you can actually see your zones that are there from within DNSimple as well, alongside your other zones.
And you can actually move DNS records back and forth between them. And so I think you're right that the incumbents aren't the real, like the, the, the real incumbents, the ones that have been there for a long time, aren't going to change. And instead you have the new group that's going to come in, and then they become the incumbents and they don't have the incentive to change and the cycle continues, right? At least as long as the technology is still viable.
Speaker 1
Yeah, and the, the cynical asshole in me, which is most of me,
knows that, like, even though they aren't motivated to change, like, they couldn't even do it if they wanted to,
because, like... Very
Speaker 2
difficult.
Speaker 1
Yeah, because from a technical perspective, like, everything you do gets so, like, ossified over time. your early decisions get buried under the weight of your later decisions, and the idea of, like, oh, we, like, fundamentally misnamed this, this, like, really fundamental concept, so let's clean that up, that, like, never happens. or, like, a certain...
Like, once your app grows into, like, all these different pages and stuff like that,
you can't really change the, like... Okay.
There, there's, there's the like superficial appearance of your UI, but then there's your conceptual model of the product, and that's a much deeper thing. And the, the visual appearance of the UI and how the UI works and stuff like that, all that stuff is downstream of the conceptual model of the program. And your conceptual model is very hard to change, and you're never ever going to get it right the first time.
And so unless right from the very beginning, you're willing to continually step back and reassess and do the like painful, expensive work of reconciling your conceptual model with the new reality, then years are going to pass and there's going to be so much weight on top of those early decisions that they're never going to be changeable.
Speaker 2
Absolutely. There's, I can tell you there are still some design decisions inside the heart of the N-Simple that could, could, they warrant an update, but it's the cost of doing so outweighs the benefits so greatly that they don't, we don't usually look to, to tackle those things. We might slowly chip away at them, and then one day we get to the point where the, you know, cost-benefit analysis flips the other way, and the benefit becomes so great over the cost that it's worth investing in.
And I think we've seen that internally in the N-Simple on a couple of concepts that we've changed over time. The, the most obvious one was some of our early implementations of users and accounts. So we bound everything together initially where a user was an account. So you logged in, and those credentials that you used were tied to things like billing and access control, right? And that, at first, that was fine, but over the years, that binding started to get more and more difficult to, it started blocking us from building new things.
And so One point we had to decouple those, and that's not an easy thing to do when you've built this stuff all throughout your application. But we managed to pull it off and got to the point where we now have a, a, a many-to-many relationship between users and accounts, so many users can be part of many different accounts, which I think is interesting because we have a lot of folks that use us for their personal domains, so I have domain names, but I also work on DNSimple's domain names.
And in DNSimple, we segment domains for certain reasons, like we might have production domains in one account where it's highly restricted, but then we have other domains that we're experimenting with for fun, right? We might build a site or run something off of it that we don't even know if it's going to live. And so we can run these different accounts, and I can use my single user to get at those different accounts and different, different access control, but when the two were bound together, that wasn't even possible.
So you're right, there are fundamental design decisions that we put into any application code, and the bigger that code gets or the longer it lives, the harder it becomes to Change. I, I think also there's something more fundamental, though, which is if a business has to continually race towards the next goal, whether that's raising the next round of funding, getting the next round of debt, going public, you know, growing to the next revenue target that they have, the last thing they're going to do is let's update our core systems because it's hard to move.
No, they're not going to do that. They're more likely going to go build around it until you can get rid of it, because we don't care. We just need the business to keep moving forward. Whereas a smaller business like ours, that's profitable, that we don't, we're not, we never raised any funds, we didn't need to, we have the, the, the choice and the leeway to say, no, actually, we're going to fix this.
It's going to take some time. We're going to continue servicing our customers, but we're going to go in and we're going to change this core fundamental model or relationship, and we're okay with that.
Speaker 1
Yeah, yeah, cause I think it's the, I mean, I mean, there's asterisks to this statement, but like, I think it's the smart thing to do. I think it's a, a short-term, long-term question. like, if you just take your, take your early,
the stuff that you built early on, that's maybe like, in need of a change, but you just build on top of it, even though it's no good anymore,
and, and, and, and make that part of it frozen so that it can never be changed, you get that short-term benefit, but you hurt, hurt yourself in the long term and lower the ceiling of your future potential.
whereas if you do the opposite, then you get the opposite result, and, and you can grow more later, and you can go faster later than you could have, instead of continually slowing yourself down more and more. and I think it's one thing to make a conscious decision between those two things.
you know, you can say like, okay, I know this is gonna handcuff us for the rest of eternity, but we're gonna do it this way anyway, because we're gonna sell the business in two years, and I don't care, cause I won't be around for that. That's a valid choice. What really bothers me, and, and what I'm building in reaction to, is when people are,
dishonest with themselves. Or, or they're not intellectually honest about the causes and effects and stuff like that, and they say like, oh, we'll, we'll just build on top of this crap now, but we'll clean it up later. It's like, no, no, you're not. You're not ever gonna clean it up later. Nobody ever cleans it up later. So, just tell the truth and, and admit that you're gonna handcuff yourself forever because of this.
don't pretend that you're gonna come back and clean it up because nobody ever does.
Speaker 2
You're, you're, you're correct in that it very rarely happens. I can tell you, though, that, that, again, if, if you build systems in your business, so if your, if your business gets the point where it is sustainable, so that means it's profitable, you don't have debt, you can, you know, you're growing, even if it's very slow, or you're stable, and it's satisfying your needs as the owner or the owners of the business.
Then you have an opportunity to put processes in place where you can say, and we're going to invest a specific amount of time in maintenance. And where maintenance is not just making sure everything is up to date, but also fixing broken windows. you're never going to hit everything. Like, there's always going to be more things in your software that you're going to hate, that you're going to want to change, than you have the time to change.
That's the, that is a, that is a fact. But it doesn't mean that you still can't invest time to change things that you, that are strategically valuable to change. And that's really the difference between, a company that is You know, rocketing towards something and, and taking all, like they don't, they'll just say, we don't care about the damage we cause along the way, we have a goal and we're getting to that goal, versus a company that says we're on a slow, stable path, and as part of that, we're going to, to build for the long run, and we're going to continuously work on improving software, processes, whatever it might be that you want to improve at the business level.
In a lot of ways, business is like software, right? It has a lot of moving components, it has a lot of people putting their hands into it, it has a lot of processes, it can be just as unmaintained as software. You can have businesses that you go and all it is is dead bodies everywhere. Like if you go start digging, you just, it's terrible.
You find like the accounting is terrible, and the legal structures are terrible, and the, the way they treat people is terrible, and yet it's still a successful business. I've never seen that. Every
Speaker 1
place I've ever worked has been great.
Speaker 2
I'm sensing a bit of sarcasm here. Yeah, exactly. No, I mean, every, it's, there's cracks in every foundation for, whether it's for software, for business, or anything else. There's always going to be cracks. And sometimes those cracks have to be fixed in order to move forward, or they have to be built around, is what it comes down to. And as a business owner, or a software developer, or whatever you might be, it's your choice to decide if you're going to invest in that or not.
And that's a choice. Like you said, there's no right or wrong answer. The right or wrong answer is, at the end of the day, are you getting what you want out of this thing? If it's visa software, does it do what you want to do in a way that you're happy with? If it's a business, does it, does it make your life and the, the lives of people around you better? If it does, then okay, it's pro, maybe doing what you want.
You know, so.
Speaker 1
Yeah. That's
Speaker 2
my approach at least.
Speaker 1
Yeah. yeah, and again, that's a totally valid choice. A lot of products,
I might even say most products, are just trying to build things that, that check the box, and it's like, okay, we need a feature that does X. We don't care how it accomplishes that, we just need that to be physically possible with the product. and like you say, that's a valid choice to operate that way.
I am extremely tired of operating that way, and I want to build something that's actually good. even though it has become, like, kind of a cliche at this point, the more I think about it,
the more I think about it, the more I admire Steve Jobs and Apple and the whole philosophy around that stuff. Because they put out truly excellent products, and I feel like Steve Jobs looked at everything in just a completely different way than most people look at things. and I feel like most people either consciously or unconsciously believe that making something truly excellent is not an option.
and maybe they're right, but I don't want to believe that. And with what I'm building now, I'm like, let, let's see about that. Like, is it really true that I have to slap some garbage together and like, I just have to make it work somehow and it can't be actually an excellent product? is, is that a trade-off that I have to make? Or can I make it excellent and a great business success and maybe even a bigger business success precisely because it's excellent right from day one? that's what I'm interested in.
Speaker 2
Well, let me know. I look forward to seeing how it turns out because I think it's, you've, you've set a very high bar for yourself. That is going to be challenging to meet your needs, your desire sort of for this excellent system, and your customers' needs, if you, whether you have them now or have them in the future, to solve a problem. Because at the end of the day, your customers, the, the only quality they care about is their experience from the outside.
They'll never see the details that you care about. That doesn't mean you can't care about them. As the business owner, you get to make that choice. And by the way, that's the greatest thing about building your own business versus working for somebody else, is it's on you to decide where you're going to invest your time. Right? And what matters
Speaker 1
Matters to you.
Speaker 2
Yeah, and to be clear, the, the parts that I'm trying to make excellent are specifically the parts that they care about.
Speaker 1
Good. Well, then, then that's, if you're going to focus on one thing, focus on the thing that your customers care about, and you have to keep asking them because what they care about today might be different than what they care about a year from now or two years from now, right?
Speaker 2
Yeah, and you know, I'll even put a nuance on that. there's, you know, that book, The Lean Startup and that whole movement and stuff like that. There's, there's a lot to be liked in that. but I feel like there's been this, unfortunate, takeaway from all that, that is, it's, it's not quite exactly correct. people, people quite rightly,
Highly value the idea of talking with customers and responding to feedback and, and acting based on that. but I think it's one layer too shallow. and again, this goes back to the Steve Jobs thing.
like a lot of businesses ask their customers what they want and then build that stuff. I, I, I think that, what is really needed is you have to go a layer deeper and don't ask people, I mean, ask people what they want, but like also don't ask what they want. Go in and understand them and their jobs. Like, who are these people? What are they doing all day, every day? I've suggested to my consulting clients, and more than zero of them have actually taken me up on this, actually go fly physically to them and spend time with them in person and, like, go to their, like, warehouse and let them show you around and show you their work and stuff like that.
Sit next to them while they're on the computer and watch them click around and stuff, because they are going to abuse your software in surprising, horrifying ways that you never could have guessed, and that they will never tell you about, because they don't even realize that they're, like, doing, they don't realize that that's worth mentioning.
They just think they're doing the natural thing that they would do.
and then take that And be the product designer. Like, don't outsource your job to the customer and let the customer design the product, because they probably don't know how to do that. It's your job to instead understand what their job is and then design a product that can help meet,
their needs. And I'm not saying that because I don't think you knew that stuff, but there's a lot of people out there who, again, go one layer too shallow.
Speaker 1
Sure, there, there, there are, it's, it's easy to ask somebody what they want, and they will tell you all kinds of things that they want. It's not necessarily what they need. I think that's the, the, one of the things you're talking about is to truly understand what somebody needs, you have to truly understand the problem that they're facing.
And you can only do that by seeing them, not hearing them tell you, by seeing what they're doing. it's also very costly to do that, right? Like you talk about I'm gonna travel to a client or many clients in that case, that costs time and it costs money, and a lot of small businesses don't have that. So what they do is they, that we look on our own experiences and say, I'm doing this thing as well, so I'm gonna solve this problem because I'm doing this thing, which is a valid way to start a business, right? It's very common that a lot of folks start a business based on something they're already technically savvy in, whether that's writing software, baking bread, or
whatever it might be. because they know the area and they know the problems they face and then they try to solve those problems. At some point, though, your business moves beyond you and now you have people that have problems that you don't even see or understand without getting out there. But it's tough. Like, I do love getting out and getting to events where I can talk to people and actually see some of the things that they're doing.
Like, they might show me, hey, I'm, they'll like pull up D and Simple and they're like, I, this, I went here and this thing happened and it was really weird. And I look at them like, I didn't even know we were doing that. Or I'll go through myself and I'll be trying to manage a domain and I was like, something doesn't work the way I would expect it to work.
And I, and so it's important, I think, to get regular feedback from folks who are actually using the thing, see where they're, they're having trouble with it. And then what we do, so we, I don't know what I don't know if you've heard of the shape-up process that came out of Basecamp. So we use shape-up at DNSimple now for a couple of years.
And one of the things that was added to shape-up after the initial book come, came out was this notion of framing. And framing is describing the problem in a document in words. Not describing a solution, but describing the problem and iterating on understanding the problem in that document until you've really reached what you believe is enough of an understanding.
To then go into the shape part where you talk about the product is like, now I'm designing the product, the piece for that product, the feature, because I understand the problem. And initially we didn't have that piece and it felt like we were missing something and when we added it in, it was like, oh, okay, this makes a lot of sense. And it took some retraining, because we're almost all engineers at DNSimple who are working at the product level, it took some retraining to not jump straight to solutions.
We actually had to stop ourselves from writing solutions and instead focusing on the problem and the people that are impacted by this problem and what they imagine is the world after that problem is fixed. So that, that was very helpful for me is adopting the framing portion of ShapeUp and, and adding into our workflow so that we could better understand the types of problems that we have.
And I think it's been helpful for building better systems. Sometimes it produces weird output, like, like if the frame is off, then the design of the, the solution is going to be off as well. But more than not, it's been super beneficial to be forced to think this way.
Speaker 2
Yeah, I think there's a lot of wisdom in that. understanding the problem before coming up with the solution.
in most work situations, most of the time, my experience is that those two things are very muddied. the solution is mixed up with the problem and it's people talk about what they're going to do,
but it's, it's not clear what parts of that are, are the solution and what's... If, if you ask like, okay, we're doing this thing, but like, what exactly is this all about? What's the problem? And why this solution and not some other solution? And that stuff is not always thought through. And if you separate it and make a clear statement of the problem, then it's like,
you, you, I, I look at some of these things as like writing to disk so that you can free up your RAM. It's like you take the problem and you can write that to disk, and now you can take all of your now free RAM and bring that to bear. Think about the
Speaker 1
solution.
Speaker 2
Yeah, yeah. Yeah, and that goes back to the, you know, doing research with customers and stuff like that, spending time physically with them and, and that kind of thing.
cause all that is like upstream of your understanding of the problems and the kinds of solutions you're going to come up with and stuff like that. And it's just so depressing the way it works most of the time, like people making product decisions based on like telemetry, and they think that that's, that's a way to do it. It's like, well, they're spending fifty-four percent of their time on this page, so that means we need to, and it's like, no, that's like so superficial.
You got to actually understand what's going on, not just look at the most surface level stuff.
Speaker 1
Well, I wouldn't get too depressed about it. I see it as opportunities, right? I see it as opportunity to make the world better, to help people, who are trying to be problem solvers, to understand problems better and give them systems to do so. That's one of the reasons why I appreciate something like ShapeUp is because it's, it's a system, is what it is, right? It's something that's designed, it works in certain cases, it doesn't work in other cases, but it gives us a framework within which we can think and which we can operate and which we can try to do better.
Sometimes we'll fail, sometimes we'll succeed, but all in all, at least we're moving in some direction where we're trying to make improvements. And I think that's a good thing. I, I don't feel a, yes, there are a lot of people out there that are stuck in environments or fostering environments that are not
healthy, I would say, healthy for the business, healthy for their customers, healthy for their team members. but, but The only thing we can do is we can keep pushing that envelope, trying new things, see what works, and then get out there and share that this thing worked for me. And you caveat everything that you do, that this worked for us.
When I go out and talk about this, I always say, it worked for us, and here's where it didn't work for us. Like, I'm totally honest about it. There are certain cases where we've tried ShapeUp, and it has been a flop for us. But it doesn't mean that ShapeUp was the problem. It just, it's, again, it's like trying to, trying to, you have the solution.
But what is the actual problem for us? So take a step back and, and frame that problem. And I think I found it extremely enjoyable to, to, to have continuous improvement in the business or to foster and attempt continuous improvement in the business, even if it doesn't always work out the way I'd hoped.
Speaker 2
Yeah. Yeah. I mean, at least making an effort is, is,
It gets you a lot of the ways there. I have a completely different question, which is, in those early days, how did you get your first users and customers?
Speaker 1
So that came, the first folks were in the community that I was already pretty strongly involved with, which was the Ruby community. So at the time, I had been, speaking at Ruby conferences and Rails conferences, in, in different places. I had been, heavily active in a number of open source projects, some that I created myself, some that I helped others on.
and so, and I was active on social media,
where I could go and say, I'm building this thing, and the people that I knew were like, oh, cool, I'll give it a try. And so those were the earliest customers at DNSimple, was people that we knew. And I think for the first
Twenty or thirty people, they were all people that we knew. And then it very quickly became people that they knew, because they started telling other people that were in the space. And I didn't necessarily know them, but now we were, you know, one person removed, but they were like, oh, I'm trying it out, and then I'm trying it out. And so that, that became a nice early cycle where we didn't, because we didn't have any money to invest in advertising or much marketing anyways.
All the marketing that I did was me going out to events and basically guerrilla marketing, going and talking to whoever I could talk to, whoever would listen and tell them, hey, this is what I'm doing. You know, if you need something like this, it might work for you. If you're unhappy with whoever you're using now, it might work for you. And so that was really the early days for the first customers.
Speaker 2
Yeah, that's interesting because that's very close to my plans for getting customers for my product. So my, my, my first Objective, was to get just anybody using it in any fashion, like even if they weren't paying anything, just get somebody onboarded onto the platform, just to prove that from a technical perspective, it could work for somebody who's not me.
and I got like four or five people who, who did that, so that was nice. and then recently, and, and so then my next objective from there was to get an actual paying customer. and I recently got my first one of those.
Speaker 1
Congratulations.
Speaker 2
Thank you. And now I'm dealing with scaling issues, cause this is like a real project, and apparently my system can't scale from zero users to one. so I'm...
Speaker 1
It's one of the hardest parts to get. You got to get that first one, right? Right. Before you go beyond that. And then it's just N. So, right? Like zero to one and then one to N.
Speaker 2
Right. Yeah, so surely the second customer, unless I get a huge one, which great problem to have, but that'll be easier.
And these, these all were like people, not necessarily people I had known personally, but like people in my orbit.
They like, maybe I didn't know about them, but they knew of me, and so when I like put out a tweet, they're like, oh, okay, I'll check out that thing or whatever.
Speaker 1
Yeah.
Speaker 2
And then this first customer is somebody I've known for a long time,
and I'm, I'm intending and expecting that my first handful of customers will people, will be people I get that way, just like manually going out into the world and grabbing people and being like, hey, Do you want to try out this thing? And then it's interesting what you said that kind of the next wave of users or whatever are people who those people knew.
I think maybe a lot of people, certainly myself in the past, like I was thinking about like scalable ways to get customers. And I realize now, or at least I'm of the opinion now, that like in the beginning, scalability is kind of irrelevant.
Speaker 1
Correct.
Speaker 2
The, the point is to get somebody, and to get that kind of,
I don't know, kernel of a user base. And if you can expand that by ten percent, then good. Cause like at, at every stage, what got you to that stage is going to be different stuff than what gets you to the next stage. It's not going to be one thing that gets you from zero all the way to a hundred million dollars. It's going to be different stuff.
Every couple months or every year or something like that, you're going to have to adopt a completely different strategy, and what's appropriate for getting from a hundred customers to a thousand is not appropriate for getting to, from zero customers to ten or ten customers to a hundred.
Speaker 1
Yeah, every time you add a zero onto something, whether that's the number of customers that you have, the amount of revenue that you're pulling in, the amount of traffic you're pulling in, whatever it might be, the, the requirements are going to be very different. Like getting to that next step, and the things that come after getting there, right? I was joking about the zero to one and then one to N.
I mean, that's the dream, but the reality is, is that, you know, one to a hundred might put you into a different scalability problem that you didn't foresee, and then a hundred to a thousand will be a different one, and a thousand to ten thousand will be a different one, right? So
One of the things that you have to have, and everybody who wants to be an entrepreneur, who wants to run a business has to have, is you have to have a drive to, to be able to stay through the hard things. You have to be willing to keep going when things don't work out the way you expect them to.
otherwise, it's really hard to build a long-term business, unless... You also would have to get lucky, too, right? Like, there's a huge component of being in the right place at the right time, and that can't be understated. So all these things have to come together, your own drive combined with being in the right place at the right time, which is essentially what luck is, really.
and then on top of that, you also do still have to, to get out there and sell, right? Like, it's gonna be this, like you said, your, your, your first customers are people that you're, you might have to go out And get at events or whatever, and you have to convince them that what you're doing is going to bring them enough value to stop doing whatever it is they're doing now, right? To make a change.
And that's not an easy thing to do, especially if your software requires setup, if it requires an investment of time or money, these types of things make it really difficult. And one of the fortunate things about DNSimple is in the early days, you could play with it and get value out of it without having to change everything else that you were doing.
So, cause most people have more than one domain name, and they want to then maybe get another domain name and play with it. So they could do that at a very low cost. the only difference is I never had a free tier. I, I personally was, cause I had run the startup that I talked about earlier, we had done a free model for a long time, and I made the conscious decision that anybody who was going to use DNSimple was going to pay.
And I might discount it heavily for certain people, I might give them credit so they could try it out for an extended period of time, but everybody was going to commit to put their credit card in, in order to pay. And that's still something we do today. We've never dropped that. You know, fifteen years later, you can't start using BN Simple unless you at least commit to putting your card in there.
Speaker 2
That's the, that's my exact plan for my product.
currently there's no, it's, it's physically impossible to give me money through the system, but when that exists, that's my plan for how to do it.
cause like, oh, what is my rationale for that? Well, what's your rationale for that?
Speaker 1
Well, my rationale was that I'm running a business, I'm investing my time, there's infrastructure that needs to be in place to run this. If I'm bringing somebody value, then they, and they see that value, they will commit to putting their card on file. Full stop. And anything else, any free product, you don't know if you're actually bringing value to your customers, because the, the investment that you, that they have is their time, and granted, time is very valuable, especially nowadays.
But there's a difference between it's the weekend, so I have an hour or so I can dork around with it, to I'm willing to put my card in and potentially pay a few dollars. Like that gap, that leap for someone to make is a big leap. And if you're not getting them to, if you don't know early on that they're making that leap, then you don't actually know if you have the potential for a successful business.
Speaker 2
Yeah. Yeah, I think a big part of my rationale is like, I don't want to waste my very limited time and energy Early or later on false positives, like if somebody signs up as a free user and starts using it, and I like get all excited because like maybe I have a customer, that's only like maybe I have a customer. whereas if you gate it with requiring a credit card from upfront, then it's like not a maybe, it's like you have that person's credit card info, they can obviously cancel anytime or whatever.
but they've, they've already gone over that much higher threshold, and so their presence is much more meaningful.
Speaker 1
It's also going to greatly limit the amount of people you get in the front door in the first place. That's why folks argue for the freemium model as being so valuable, is because you can get more people in the front door to learn from them, especially early in the project. So I get that, like I'm not knocking that as one of the ways to do it, but there's, there is a Those people that you get in the front door, the vast majority of them will do nothing with your product.
They will walk in the front door and then they will never come back again, right?
Speaker 2
Yeah, that rings true to me. and, and I think that's another thing that speaks to the value of like getting your first customers manually, as I put it.
like it takes Not only does it take a lot to get somebody to like switch from what they're doing now to doing a new thing, but when an endeavor is brand new, it's an even bigger risk because it's like, okay, I'm going to switch for the, from this thing I've been using for a long time that's working okay to this new unproven thing that might not even be around in three months.
Like that's a lot to ask of a person. And if you have a personal relationship with the person, then that greases the chute a lot so that they're going to be a lot more likely to, it's kind of doing you a favor. So they're going to be a lot more likely to do you that favor.
Speaker 1
Yeah, it's, it's, you're, there, you have a different kind of capital that you're spending, and that's a relationship capital. You know, you're, you are spending a little bit of that to get somebody to come in in those early days who knows you. because They, they're, you're asking them to do something which is trust you, which is a big unknown.
And so they trust you because it's social capital that you have with them already. so, but it, you can only spend so much of it and burn through so many relationships, which also puts a lot of pressure on the, you as the developer or the person starting this, you feel like an extra burden of responsibility, which is like, oh my gosh, like, you know, my friend John, he signed up six months ago and I still haven't done these things I told him I was going to do.
I'm such a bad person, right? So it's like this extra layer of stress, which
May or not, may or may not suit what you want out of your business. It depends on you. Depends on each person, right, what they want.
Speaker 2
Yeah, but another thing I was going to say is there's definitely a direct correlation between, like, how nasty and unpleasant and, like, life-consuming the business idea is and how, how valuable it is. Because, like, you know, DNS hosting can't ever go down, has to always be up, like, that sounds like kind of a nightmare, but, like, that's because it's, like, actually a truly valuable thing, whereas some-something where if it doesn't matter if it goes down for three hours in the middle of a weekday, people can live without that, so it's probably not that valuable.
Speaker 1
Or, or it definitely was one of the factors in, in their, their consideration of the value of that service. So maybe they won't Compensate you as well because they don't see the value there. and that may be okay if you're going to scale. I mean, I, I know a lot of, of products out there that they didn't care about being something that was going to be up all the time, yet they still did very well as a business because they still managed to bring value in some other way, right? And there's a whole bunch of products that you, just think of video games.
Like, people don't need a video game to be up, but then you watch anybody who plays a video game. Yeah, they do actually. They need it to be up right now because right now is when they want to play it. So you, you have this thing that seemingly is not a life Critical thing, or it's not something that they have to have, but in fact, they're so emotionally tied to it and they have that need for it, that it is actually something that they need.
so I, I find it to be fascinating when you look at all these businesses that you wouldn't expect to be something that where it's, it, somebody will consider that highly valuable and something critical to their life that becomes, in fact, it really is a piece of software or a service that they need.
Speaker 2
Yeah. Well, nothing is rational, everything is emotional.
Speaker 1
It's, it's true. There's emotional components to all of this that we can't understate.
Speaker 2
Yeah, yeah, cuz it's like, why do you buy a nice car instead of a crappy car? Like, a crappy car will get you there just, just the same, but you buy a nice car for emotional reasons, and it's like, just like everything. anyway, it's probably about time for us to start wrapping up.
one quick question, before we go, cuz, you know, you and I have known each other for, for a long time, like almost 60 minutes at this point. so I figure we have a strong enough relationship now that, like, after this call, I was thinking you could, like, just abandon whatever CI that you're using for D and Simple and just entirely switch over to my product.
does that sound good?
Speaker 1
while I wish I could say yes, that decision is out of my hands. Got it.
Speaker 2
you're gonna hear that
Speaker 1
response a lot, by the way, but it's actually a really important, it was worth a shot. It's actually a really important thing to remember as you're starting to grow and starting to, to deploy your business. You need to find your champion inside any business or organization that you wanna sell into. And you want your champion to be clearly identified, you want it to be somebody that you build a relationship with, even if they're not gonna write the check.
Even if at the end of the day, in that particular environment, you don't close that deal, you need to connect with champions because they are the ones that are going to get you in with the gatekeepers and the buyers. And if you don't have the champions, then, well, then let's just put it this way, you pretty much have to have a much bigger marketing budget, because you have to reach those buyers and those gatekeepers through a massive amount of marketing and sales.
but if you have your champions and you know who they are and you treat them well, those champions will become the ones that take you into the businesses that they work at. They will be the ones who will be with you for the, for a long time in your business. So look for your champions.
Speaker 2
That's an interesting and I think better perspective than the one I've been familiar with, which is like that sales advice of get in front of the decision maker, which obviously is like good advice, but also it seems a little bit lacking in nuance of how reality is because like you c- it's, it's not always realistic to get in front of the decision maker.
So many times I've had instead a champion who is like, okay, like I'm the one who wants to do this, like I'm the one who cares about this thing. The, the actual purse string holder doesn't really care about the thing. They are the official decision maker, but it's not their thing. the champion has to go and they have to be, be the one to make the case to the, to the purse string holder.
and you're never gonna like directly talk to that person in a lot of cases, so I think that makes a lot of sense.
Speaker 1
Yeah, you, you will eventually have to get in front of the buyer, so that's the one that's writing the check, and you will have to go through gatekeepers. Those are the ones that are gonna block you from getting at the buyer because of their other relationships that already exist with other vendors or what have you. They have all different kinds of reasons.
But the way that you get there, especially in this day and age where there's so much noise, is not trying to like kick down the front door and go straight to that group. You first have to service those champions and make sure that they're getting What they need, even if it's not in the context of the business they work for. I can't tell you how many people use the N symbol who still have never taken it to their Fortune 500 enterprise company.
And I'm okay with that. I'd love it if eventually they do, but my first goal is to make sure that we continue trying to do well for them and still have a successful business. And so we make some decisions just to try to make sure that our champions continue what they need, even though it may not be the thing that gets us into, you know, an enterprise contract or what have you.
Speaker 2
the last thing I want to ask you before we go is, is there anywhere you want to send listeners to learn more about you and D and Simple and anything else?
Speaker 1
Well, I'm in, I'm on LinkedIn, so they can come find me on LinkedIn if they just search for Anthony Eden, I'll be there. they can email me directly if they want. I'm anthony at dsimple.com. Although I just ask, don't try to pitch me or sell me on anything, because I have a very strict policy of how, what I do with unsolicited sales messages, and usually it results in getting clicked to spam.
So if you want to talk to me about something, if you're interested about what we talked about today or some of the other topics that I, I've posted about or talk about, by all means, reach out. Totally cool with that. I want to help more people do well. I want to have them, see them do whatever it is that makes them happy, whether it's a successful business, a long career in engineering, anything else.
But if you come and you open with, hey, I, I have this service, buy it, you're going to go straight to spam. But otherwise, yeah, reach out. To me that way, and of course, dnsimple.com is where you can find out everything about dnsimple and what we do.
Speaker 2
Well, Anthony, thanks so much for coming on the show.
Speaker 1
Thanks, Jason. Thank you for having me.