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

It's another episode of Startup 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

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? You know, 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, it's

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're 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 ex-Twitter conversation and I've been 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 Arangio. 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, you want to dip your toe in the water, microconfconnect.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 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 like 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 is

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, a 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, and it just rolls forever. It's so much easier to roll two D10s. 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 a thousand, one 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 bull 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, you know, the harder you work, the 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 sideswiped

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 sold his business for $20 million, literally, and always says, you know, 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 think

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 and

including my consulting days where 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,

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. And 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

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'd never even logged into one.

And there were folks like Brennan Dunn giving me advice because he, I believe, had an Infusionsoft account. Keith Perhak had an Infusionsoft account. He's a founder of Stagmetrics, 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 to Private Equity for less than 1X ARR 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 hard, I mean, it was a hard realization. I'm not saying in retrospect, I was 100% 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 to,

They were charging way more money than you needed to 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, right? There's different levels of outlier idea. But eventually, it's

I did a ton of soul searching and I came to grips with the fact that pivoting drip and ad 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, we can, I think that's a legit thing.

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 there are 40, 50, maybe more. There's probably even more than that. Maybe is it even 100 of founders that

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 to 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. You know, if you think about the first line of code that Derek wrote,

for Drip was December of 2012. We had our 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 million? 25 million ARR? 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 bunch of small projects and throwing them 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 ex-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. So I'm going to ask you a question.

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? Like, would I put one skill set at the top? And specifically, he says when building a business, I mean when building a SaaS company. And so I started thinking, you know, there's engineering skills where you can build software, there's marketing and sales, right? There's

Well, we could name how many skills, right? A lot. Different departments, customer success, 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, right?

based on my criteria and how I see people succeeding, and I put them 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 are selling a high-priced 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 sh**ty 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 5, 10, 15 million, 20 million ARR, 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 sales.

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 a little different back then. Did I put aesthetics fourth? I don't even remember. It doesn't matter. I put 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 first.

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 stuff.

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 as 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, you know, an experienced engineer who's guarding that code base fiercely. And fourth is hiring engineers

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 ARR or a million or five million, whatever your goals are. And I'm going to do it alone or 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 $150K 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 mishiring or they're not managing them well. And so they can 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?

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 skill set, of course, is critical to building the SaaS, but it's much less critical to the success of the SaaS.

the business than you might think. This is why in 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 that,

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, uh-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, right? 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 like 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 chip 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 online.

at least pre-acquisition. And it was to build visual workflows. So we had all these automations, but it was, you know, if you think about Zapier, where there's like a drop-down 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, like 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 ActiveCampaign. 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, right, 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, you know, the internet was a buzz. 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. Like onboarding took weeks to build. Our onboarding in 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, like 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 DEF CON 5 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 like 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, what do we do?

We really want to hit this deadline. We could push the deadline out, obviously. I don't actually know how many people would notice. You know, 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 conversations, 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 can definitely be helpful for everyone working towards a thing, especially if you have multiple teams, you know, 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 over-index 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.