Episode 762 | Doing Great Work, Hierarchy of SaaS Skills, and Public Deadlines (A Rob Solo Adventure)

Rob Walling:
It’s another episode of Startups For the Rest Of Us. I am your host, Rob Walling, and in this episode I’m on a solo adventure where I’m going to walk through Paul Graham’s, I was going to say recent essay, but it’s over a year old now. It’s called Doing Great Work. I think it’s a fascinating look at the steps that it takes to ship amazing things and to build incredible things on this planet. And I’m going to focus that a little bit more on being an ambitious Bootstrapper rather than Paul. Graham thinks of things like probably Airbnb and what DoorDash did they invest in or Instacart, these really kind of game changing apps that everyone winds up using. But for the purpose of this podcast, we want to build real businesses for real customers that pay us real money, which look Stripe and DoorDash and those actually are as well, but that’s not the focus of this show, and so I’m going to edge that or focus it more on things that relate to what you are probably building. 

Then I’m going to talk about whether there’s a hierarchy to skills If you’re building a SaaS, this is based on an X Twitter conversation and dive in to a couple other solo topics. But before I do that, applications for MicroConf Connect, which is our online community and forum are open today and they close March 5th. Since we do custom group onboarding for new connect applications, we take folks in batches once every month, and if you get in now, you will have access to our MicroConf Connect live session, which happens next month in March with Asia Gio. She’s going to be talking about, well, all types of amazing stuff that Asia talks about. So if you’re interested in potentially becoming part of MicroConf Connect, do you want to dip your toe in the water MicroConf connect.com? It’s only open for a few more days and closes on March 5th. 

Let’s dive in to my first topic. I’m going to link up this essay, how to Do Great Work by Paul Graham, and when I noted down this essay, I put a couple bullet points. I said, doing great work isn’t easy and you must be ambitious and hardworking to even consider it. Paul Graham has four steps to do great work, and he says, this is how practically everyone who’s ever done great work has done it from painters to physicists, and obviously he includes startup founders in this, I would assume. So step one is to decide what to work on. Step two is to learn enough about it to get you to one of the frontiers of knowledge. The third step is notice the knowledge gaps, and the fourth step is boldly chase outlier ideas. And the reason I wanted to talk about this in this episode is whatever you are building, whether it’s a lifestyle business or an ambitious SaaS startup, I think the first three steps probably apply to that. 

But the fourth step of boldly chasing outlier ideas I think only applies if you want to build really ambitious products or companies that get really big, but deciding what to work on, learning enough about it that you get to one of the frontiers of knowledge and then noticing the knowledge gaps to me is a fundamental part of building something that other people will value and businesses will pay for. It’s extremely rare that someone gets so lucky that they enter a domain or a space or a vertical and they build something right from the start without learning enough about it to get to the frontiers of knowledge and then noticing the knowledge gaps and they’re right. It’s kind of like trying to hit a bullseye on a dartboard or it’s kind of like trying to roll a particular number of 57 on a 100 sided die, maybe even a 500 sided die. 

They don’t make those. I have a 100 sided die and it’s almost like a golf ball, so you roll it, it just rolls forever. It’s so much easier to roll 2D tens, but I digress. The idea of you coming into a domain that you don’t understand and seeing a huge gap without first getting the frontiers of knowledge and noticing those knowledge gaps is a one in 1,001 in 10,000. This is the thing I see people try to shortcut and they don’t try to shortcut it by learning and getting to the knowledge gaps faster. What they instead try to do is build a bunch of bullshit and throw it against the wall to see what sticks, thinking that if they launch a hundred or a thousand products, that one of those is going to magically take off through sheer luck, and I think that’s a terrible game plan. 

I hate relying on luck because as much as we can say the harder you work luckier you get or you make your own luck by trying a lot of things and putting in a lot of time and developing skills and working hard. As much as we can say that, and as much as I believe that you can’t control luck, and I’ve seen more than one, and by that I mean dozens upon dozens of companies just get sides swiped because they were unlucky platform risk competitors. I’ve told stories on this podcast about people getting unlucky and then about folks who got lucky, A friend of mine who’s sold his business for $20 million literally and always says, I just didn’t work that hard. I got really lucky. I hit things at the right time. Don’t rely on that because almost no one succeeds, mostly based on luck. 

So what I want to encourage you to do as you think about building a product is decide what to work on, then learn enough about it that you get to one of the frontiers of knowledge and then notice the knowledge gaps. I’m going to give you an example of this. When we built Drip back in 2012, I knew that email marketing was a cornerstone of every business that I had built up until then, including software businesses I had built, including my consulting days. I maintained an email list of interested people including launching my first book, start Small, stay Small, including launching MicroConf. All of those relied so heavily on an email list, and I knew that email marketing could be better, could be easier to use. It could have a built-in JavaScript widget that allowed you to easily place it on every page of a website, some basic things. 

I decided what to work on, and then I learned enough about it that I was like, oh yeah, there’s no easy JavaScript widget. That’s the gap in this market. And so Paul Graham talks about knowledge gaps. I actually think there’s positioning or kind of market gaps. And then what we learned after we launched is that there was actually a massive gap in marketing automation, which is a term I had never heard, didn’t know what it meant. People started saying, Hey, are you trying to unseat these big marketing automation providers like Infusionsoft, Marketo, Pardot, Silverpop, there’s a bunch of others, but what we now know today as just email marketing was much simpler back then. And so it took me a while to wrestle with this to reorient the company around. We are going to become a lightweight marketing automation tool, but eventually I decided what I wanted to work on and then I had to educate myself on marketing automation. 

I had never used any of those marketing automation tools. I had never even logged into one. And there were folks like Brennan Dunn giving me advice because he, I believe had an Infusionsoft account. Keith Ack had an Infusionsoft account, he’s a founder of semetrics now funded by TinySeed, and I remember literally emailing him saying, we’re thinking about building these automations. How do they work in Infusionsoft? Infusionsoft, by the way, renamed itself keep, and they recently sold the private equity for less than one XARR multiple because they didn’t have, they just stopped growing. They weren’t releasing software fast enough and they didn’t keep up with the market product-market fit drifts. And so what I realized was, and it was, I mean it was a hard realization. I am not saying in retrospect, I was a hundred percent and I knew it was just this amazing thing that I was totally convinced of. 

I was trying to learn enough about it to get to the frontiers of knowledge, and I was noticing the knowledge gaps and the knowledge gaps in this case were, they were positioned upmarket. They were charging way more money than you needed to still make a lot of money as a software company, and their sales process was terrible. They locked you into one year contracts. They had a mandatory upfront $2,000 fee. People hated it, but there was no alternative. And at the time, I didn’t want to build a marketing automation platform. I didn’t really know what it was. It sounded really boring. It sounded like a lot of work, to be honest. I’ve never been afraid of hard work, but I thought that it would be a tough business. There was a lot of competition and there were a lot of things going on in that space. 

And so Paul Graham’s fourth step is boldly Chase outlier ideas. Now, let’s be honest, drip is not nearly as much of an outlier idea as Uber or WeWork or even Stripe or Facebook or Google. There’s different levels of outlier idea, but eventually I did a ton of soul searching and I came to grips with the fact that pivoting Drip and becoming full blown email marketing was already in the works. Derek and I had talked a lot about that, and it just made sense. It’s like, oh, I think that’s a legit need in the market, but the idea of going full-blown into marketing automation and adding all the automations and the triggers and the actions and all that was something we really had to wrestle with. That’s just one example. There are literally dozens and dozens within the TinySeed portfolio, 192 companies, and I would guess they’re 40, 50, maybe more. 

It’s probably even more than that maybe is it even a hundred of founders who learned enough about a domain and whether they learned about that working a day job, whether they learned about that on their own by doing cold calls and interviews, whether they had a brother-in-law or their aunt who had this issue at work, they didn’t just hear about that and go build it and hey, everything worked. They had to decide to work on it. They had to learn enough about it to get to the forefront of the knowledge, and they had the notice, the knowledge or the positioning or the market gaps. All of these things take time and patience and skill, and when I say it takes time, maybe it takes you three months to get there or maybe it takes you a couple of years. If you think about the first line of code that Derek wrote for Drip was December of 2012. 

We had a first paying customer, I believe June of 2013, so it was about seven months later. We launched to the world in November because we did a staged or phased launch across our 3,400 emails that were on our list. And then we did not find what I would consider product-market fit until August or September of 2014, so it was almost two years from the first line of code until I would say week plus plus product-market fit. Product-market fit is not a binary, it’s a continuum, but we found that after a couple years because it took us a ton of time to learn about the space and the market to get to the frontiers of knowledge and to notice the knowledge, the positioning, and the market gaps. So am I saying you have to commit to an idea from day one and it’s going to take you two years to get to product-market fit? 

No, none of that, right? The story is just to illustrate that. Oftentimes if you want to do great work, if you want to build something interesting and ambitious, and again, ambitious for us, what is that 5,000,025 million a RR? It’s different than Paul Graham’s definition, but if you want to do that, you’re not going to do that by building a much small projects and throwing against the wall to see what sticks because you don’t have the knowledge and the understanding of where to take it. And you do have to put in hard work and develop skills and maybe get a little lucky to build great things. My second topic for today comes from an X Twitter conversation. Looks like it happened back in August of 2023, so it’s still relevant. Alexander Schnebel asks, do you believe someone with x plus years of experience as a software engineer has an unfair advantage when bootstrapping a business compared to someone who doesn’t? 

And I responded to Alexander and said, they have an advantage, but it’s fair they put in the time to build that skill. Someone with software engineering plus hiring slash managing experience is better off someone with those plus marketing or sales has even more of an advantage. And that exchange got me thinking about is there a hierarchy? Would I put one skillset at the top? And specifically he says when building a business, I mean when building a SaaS company. And so I started thinking, there’s engineering skills where you can build software. There’s marketing and sales, there’s what we could name, how many skills, a lot different departments, customer success or great skill, customer service. Those are important, but they’re certainly less important to going from zero to one with a SaaS company. And so I gave it some thought and I picked the four most important skills based on my criteria and how I see people succeeding and I put ’em in order. 

The number one is marketing or sales, and I say marketing or sales because if you have a low touch funnel and folks are mostly self-service, then it’s marketing because you need to drive a lot of traffic and you need to build an incredible funnel and retention and all that stuff. And if you’re selling a high price product, obviously you need to know sales and have I seen people with almost no product skill, very little engineering skill build successful SaaS companies purely based on their marketing or sales acumen I have Now, is the product usually pretty and quite buggy and they eventually lock up and have a tough time shipping features? Usually in most cases, yes, unless they find an engineering co-founder who really keeps the quality of that code base up. It usually in the long run is a detriment, but can they get to five, 10, 15 million, 20 million a RR mostly bootstrapped just with marketing and sales? 

Yes, absolutely. I’ve seen it over and over and over. I could give examples. So marketing and sales by far the number one, and look, I was saying this back in 2010 with start small, stay small where I have this line of market comes first, then marketing, then aesthetics, and then functionality. I think I put a distant fourth, which I’m not sure I would actually agree with that. Still things were were a little different back then. Did I put aesthetics forth? I don’t even remember. It doesn’t matter. I put a market first, product class, market first. That was a refrain that I used to have to say a lot when I was speaking at engineering events, trying to educate developers on how to launch products. So marketing and sales, number one, I’m going to be controversial here and I’m not going to put engineering. Number two, I’m going to put product as number two. 

Product is that sense of what should I build? Not just what market should I enter, what vertical should I attack, but specifically what should we put in this product? How should it look? How should it interact? How should it operate? Because product understanding, much like I talked with Brendan Fortune here, what was it four or five episodes ago? Product understanding is not something everyone has and it’s critical to building something people want and are willing to pay for. And just because you can write code does not mean you know how to build product. This is a big mistake I see non-technical founders make where they say, I need a SaaS product, so I’m going to hire an engineer and they’re going to go build the product. And I’m like, okay, do you know what they should build? And oftentimes it’s like, well, no, but they know how to build it. 

And I was like, but do you know what they should build? And then the other thing is do you know how they should build it? Meaning do you know what the screens should look like? Do you know what each individual page should do? Do you know where this checkbox should go and what not to build? Do you know what to leave out? There’s so much product thinking that has to go in this early stage that I think as engineers we just think, oh, I’m just going to write code. I’ve been building apps for this credit card company or for this bank or for this municipal government for years, so I know how to build a product and you don’t. You know how to write code and you know how to write software, but that is not a SaaS product. So I put product is number two. 

Engineering, indeed is number three. And I think you can succeed without engineering skills on your founding team, but in the long run, I do think you need an experienced engineer who’s guarding that code base fiercely. And fourth is hiring and managing people, hiring well and managing well. This is one that’s often overlooked because a lot of us think that we can do it all on our own. I want to be that single founder, solo engineer, and I’m going to build an amazing product and get it to half a million a RR or a million or 5 million, whatever your goals are, and I’m going to do it a loaner. I’m going to do it with a bunch of contractors because the complexity and the expense of hiring team members and managing them, I don’t want to hire or manage, so I’m going to do it on my own. 

I tried to do that. I thought that that was the way that I was going to be successful, and I kind of did it right. I got to about 150 K in annual revenue with a bunch of small software products, and it was fun. It was really boring. By the time I tried to do ambitious stuff, I needed to hire a team. I needed people to be on board and to be committed. And so one thing that I see folks who have successful SaaS companies where they know how to market, they’re good with product, they found product-market fit, and they’re engineers and they’re shipping and they’re doing all this stuff, but they can’t hire or manage people, is they hit a ceiling quite quickly. And oftentimes they burn out because they’re doing everything themselves. They are on a hiring treadmill where they hire people and they either are mising or they’re not managing them well, and so they constantly are churning through people and they just can’t make headway or make progress. 

And so could hiring managing actually be maybe number three above engineering feasibly, I could probably steal man an argument that says hiring and managing, if you are really good at it could feasibly Trump engineering. But those are the four skills, and those are the order I have in marketing and sales, then product, then engineering, then hiring and managing. So think about that. If you’re a software engineer, your skillset of course is critical to building the SaaS, but it’s much less critical to the success of the business than you might think. This is why and start small, stay small. 15 years ago, I wrote product last marketing first because nothing happens until you get someone to pay you for your product. And that’s where marketing and sales are number one in my book. My last topic for today is it’s a story. It’s a story from 2015, boy, it might’ve been January of 2016, and it is the one time in the history as Derek and I were building Drip that we committed to a deadline for a feature that we publicly committed. 

And it was that one time that we forgot a big development task or a big product task. The moment it was like it was absolutely Murphy’s Law that the moment we announced it, we realized, oh, we shouldn’t have done that. So we took the tact as we were building Drip that we obviously wanted high feature velocity. We wanted to ship as fast as possible, but code quality was always extremely important and we didn’t see the need to generate external pressure, meaning go on social media or email the whole list and say, Hey, next month on March 21st, we are going to be launching this huge feature. Because we were intrinsically motivated. We were two founders of this company and we were a small enough team that the DNA was to just get stuff done fast, but at high quality. So what I’m saying here probably doesn’t apply if you have a 50 person engineering team. 

Maybe it does, maybe it doesn’t. I don’t know if I could scale this to an org that big, but we really were a high performing, high functioning team, and we all moved to ship quickly. And so putting deadlines, especially public now, we could put some internal deadlines where I’d say, Hey, do we think we can get this done by next Wednesday? Do we think we can get this done in three weeks? Realizing that the further out you think about the cone of uncertainty gets more and more uncertain, right? It’s like if I say three weeks, do I really mean three to four? Probably two to four. But if I say, can we get this done by tomorrow? It’s probably tomorrow, right? I’m more certain about deadlines that are closer to me. So we would talk internally about when we thought we could ship it, but we never went public with those deadlines. 

And then in mid 2015, we embarked on the biggest and frankly the longest duration wise feature that we ever built with Drip, at least pre-acquisition, and it was to build visual workflows. So we had all these automations, but it was, if you think about Zapier, where there’s a dropdown list that says, Hey, this is the trigger and then this is what it does. And we had automations in there and they were doing great, and we were growing. We had product-market fit. It was great, but the hardest part is you just had all these automations doing things independently instead of them being linked in a visual chain. If you go to HubSpot or I’m trying to think of who else has this now, but back then, of course it was Infusionsoft. Oh, it was active campaign. They had actually a really nice visual builder interface. So we set towards doing that, and I remember Derek and I talking about, I think it’s two to three months and it took five months, and there were reasons. 

It was a complex task. We wanted to do it really, really well, and we wanted it to ship at the level of our taste of our product taste. And so we got to the point where it was about two weeks prior to launching, and we knew it was two weeks prior to launching because the code was checked in and we were testing and it was some final things we were implementing. And so I went on Twitter, did a blog post, emailed everybody, and I put this blurry, we blurred part of the visual builder and said, something incredible is coming on this date two weeks out. And we were like, this is so cool. We get to, people were conjecturing and wondering, and the internet was a buzz and we were so excited about it. And I’m pretty sure I did that in the morning. And by the afternoon, one of us realized this changes our entire onboarding flow. 

Onboarding took weeks to build our onboarding. And Drip was really extensive and it worked really well and we had never revamped it. And we knew that once we had workflows, visual workflows in there, the onboarding didn’t make sense anymore. So suddenly we were like, we don’t really have time to redo this. So we jumped into a conference room and it was just like panic DEFCON five type thing. And it was Derek, myself, and I believe it was Anna who was our customer success person. And we said, what do we need to change? And we spent an hour just hashing out what can we do to make this work? And then we pulled in a different engineer, Ian off of the tasks he was working on and Derek set to get in designing, and we were like, we really want to hit this deadline. We could push the deadline out. 

Obviously, I don’t actually know how many people would notice. There’s always that thing of you’re paying more attention to your deadlines than other people are, but it was stressful and I remember thinking, I’m never doing this again. In the end, we made it, we got onboarding redone and everything was fine. It was a stressful couple of weeks. So the lesson is not, I’ll never do that again, but I think the level of rigor that I had at the time about dotting on the I’S and crossing all the T’s was not enough that I could call my shot like this, because if you’re going to do this, you need, I think to have checklists and sanity checks and double checks and probably a few brainstorming conversation, just thinking through, if I’m going to commit to this, have I thought of everything? Because really we hadn’t, we’d forgotten this thing and it was the one time that we really committed to something. 

So I think there are a couple takeaways here. Number one, public deadlines can be helpful, but I think if you’re going to commit to one that you need to be pretty damn sure that you have thought of everything. And so the big mistake I think we made was not committing to the public deadline, but I think it was not being rigorous enough with thinking through everything that needed to happen there. But the other thing that I would say is I don’t know that public deadlines are that necessary in most cases. I think internal deadlines could definitely be helpful for everyone working towards a thing, especially if you have multiple teams. You have sales and customer success and support who all need to be on board and trained up on a feature. Of course, at that point, you got to have some type of concrete deadline. But I think people also overindex on specifically public deadlines and perhaps overuse them because we certainly function quite well without them for a long time. So that wraps up this episode of Startups For the Rest Of Us. Hope you enjoyed a little walk down memory lane as well as some thoughts on Paul Graham essays and Twitter X conversations. This is Rob Walling signing off from episode 762.