Unscalable *and* effective ⛰
Why a late-stage founder manually emails every new customer, not outsourcing the finance function for too long, and core open source models.
Welcome to the 70th edition of The SaaS Baton. A fortnightly newsletter that brings you hand-curated pieces of advice drawn from the thoughtful founder-to-founder exchanges and interviews taking place on Relay (curated with 💛 at Chargebee for Startups) and the interwebz. So, stay tuned!
In this edition, you’ll find the following instructive and inspiring pickings:
#1: Pilot’s co-founder and CEO, Waseem Daher, alerts founders against the common (often headlong) dash towards making everything scalable and demonstrates how, even at later stages, doing things that don’t scale can be singularly effective.
#2: Daily’s co-founder and CEO, Kwindla Hultman Kramer, describes the standard and strategic logic (and leverage) that only an early finance hire can attend to and also what makes this role strikingly different from all other early-stage execs.
#3: Typesense’ co-founder and CEO, Jason Bosco, discusses how they arrived at some intertwined, non-obvious product lessons embedded in monetizing open source software.
🗞 Recently on Relay:
Heuristics and Hunches (March 31st) — Why “Move Fast and Break Things” is Outdated Advice, Prioritizing Quality and Speed, and Crossing 15K Users with Jam’s Co-Founder, Dani Grant
— On why “move fast and break things” is bad advice
— The practices that allow Jam to prioritize quality and speed
— Notes on Jam’s GTM path towards 15,000+ users
— Unifying the problem statement to serve multiple personas
Heuristics and Hunches (April 6th) — “It Takes a Lot of Listening Up-Front” and Other Must-Dos of Placing Community at the Core of Building and Selling with Harlow’s Co-Founder, Samantha Anderl
— The essence of building a community-led business
— A lesson (from the Campaign Monitor playbook) on efficiently scaling a low ASP product
— Doing things that don’t scale and measuring community efforts
— How the Harlow community drives their product roadmap
#1: Unscalable *and* effective
(From: Pilot’s Waseem Daher) (Source: Startup Real Talk)
I still personally email every new Pilot customer and offer to get on a call with them.
I mentioned this to some startup founders, and the general reaction was ‘Wow, really?’—and further surprise that, worse, I do it entirely manually.
…
This reaction is an example of a prevalent founder behavior: a tendency to think that everything needs to be made scalable—and therefore you either need to (a) simply not do unscalable things, or (b) build processes that let you do them more scalably.
…
The problem is twofold: first, building the scalable or automated process can be very time-consuming, and it’s easy to spend more time building the process than you’ll actually ever save by using it.
But more importantly, it locks in an experience before you’re sure it’s right.
…
Pilot has thousands of customers—making us the largest startup-focused accounting firm in the US. At some point, I will not be able to get on a call with every customer. But we’re not there yet, and the ROI of doing the unscalable thing is very clear.
The cost of my doing this is well-understood and easily bounded:
* I schedule each call for 15 minutes.
* I spend no more than an hour a day on “welcome to Pilot” calls.
* If I’m especially busy, I remove call slots for that particular day or week.
And the benefit of doing these calls is very clear:
* It helps me understand who our customers are in a really visceral way—in a way that I wouldn’t get by just reading the CRM notes.
* It’s a nice “surprise and delight” moment which helps to 10x the customer experience. This increases both brand perception and customer retention.
* In the unlikely event that one of these customers runs into problems down the line, they have an open invitation to reach out to me directly, rather than angrily tweet about it.
* Only 20% of the people I reach out to actually take up the offer, but 100% of them know I’m personally committed to making sure their experience is good.
Scalability is not the be-all and end-all of running a startup.
One of the biggest advantages that a startup has over a larger company is that it can do unscalable things and still be effective. It’s a mistake not to take advantage of that.
Related Relay read: Why You Don’t Need to be “Enterprise-Ready” or “Scalable” as Yet and Other Notes on Crafting B2B Software with Contenda’s Founder, Lilly Chen
#2: Not delaying the first finance hire
(From: Daily’s Kwindla Hultman Kramer) (Source: Medium)
The conventional wisdom in startup-land is that you should use outsourced accountants until about the time you raise a Series A, then you hire a controller. You don’t need a VP of Finance — much less a CFO — until you’re a metrics-driven company thinking seriously about raising a growth round.
Having waited too long to hire a finance executive once before in my startup career, I look at this a little differently.
…
An experienced finance executive will:
* Take the job of working with an outsourced accountant or part-time bookkeeper off of your plate.
* Build an operational model for you that is cash-flow based, up to date, detailed, and connected back to the GAAP accounting that you need to do to file taxes and give to your board every quarter.
* Improve your processes around, and take off of your plate, negotiating with vendors and paying invoices.
* Build a strategic model (connected back to your operational model) that will make Series A conversations a lot easier.
All those things are really, really valuable. They’ll help you know where your money is really going and where you can both save money and manage your cash-flow better.
Note that “model,” above, just means “Excel spreadsheet.” But in the same way that “algorithm,” to an engineer just means “a page of code.”
…
Here’s the list of things of requirements to focus on. You need:
* an experienced accountant,
* with big company experience,
* who is super-excited to work at a startup.
This is not the same as my normal early-stage startup executive hiring advice.
For every other executive position at a startup, you need to be careful hiring people out of a big companies. Previous startup experience is incredibly valuable. Startups are just so much more improvisational than big companies (for better and worse).
But the finance executive role is unique.
First of all, the most important thing — the non-negotiable requirement — is having great accounting chops. That’s a skill-set best acquired in a medium-sized or large company or firm.
Second, this is not an ops hire. You’re not optimizing for flexibility and a “figure it out as you go” mind-set. At a growing startup, there’s plenty of standard accounting and modeling work to fill up a 50-hour work week. So hire somebody who really loves accounting and let her do that critical work for you really well!
Of course, it is important that you like this person, feel that she has good (financial) judgement, and that you will work well together.
And it’s also critical that this person is super excited about making the transition to working at a startup — about building the first “real” financial model your company will have, and working on a small team in a company that evolves and changes rapidly.
Finally, you’re not trying to hire the CFO who will take your company public. In fact, most people would call this position “VP of Finance,” rather than “CFO.” I’ve used the title CFO here just to emphasize that this person reports to and works very closely with the CEO, and that it’s an important hire for an early-stage, growing startup!
Related Relay read: Setting up Finance as an Impact Multiplier, Defining Your Own Metrics for Success, and Other Strategic Lessons from Knak’s Head of Finance, Christopher Chan
#3: Open source vs. Open core
(From: Typesense’ Jason Bosco) (Source: Through the Corporate Glass)
We tried a couple of different monetization models before we landed on one that we have now which is where we offer a hosted version of Typesense where we manage a hosted version for users. And they pay us for that.
Initially everything was free (open source), there was no monetization at all. And some users started asking us for a hosted version but before that something that we tried to monetise and this probably goes under “don’t build something that users don’t ask for.”
We did try monetizing it by saying these are features you have to pay us for. Premium features. We called it Typesense Premium at one point. Where there were particular features which we thought would only be useful at high volume, large use cases.
We put those behind a feature flag, we said ‘if you buy a paid license than you get to use those features, rest of the features are still free, you can use them in the open source product.’
It’s typically called the open core model.
And one interesting thing that we found out with the open core model was that the features that were behind the paywall, ended up being used less, and so, ironically, those were the features that also didn’t have much stability.
Because not many people were using them, we weren’t getting as much feedback. Where as all the other features that were open and free, there people were using it, giving us feedback etc.
It’s kind of odd because people are paying for it, so they probably expect this to be even stable. But, in reality, just by the nature of how people were using it, we of course had more free users than paying users.
We realized that this might actually end up hurting the product. And what we also realized this later is that some of these features that we think are only useful for large use cases, turns out people use them even for side projects.
While all of this was happening, we were also being asked for a hosted product. And we were like, now users are asking us for a paid version and they’re willing to pay for this.
And they’re telling us that they’ll pay for this. And we were like ‘why are we trying to shoehorn this other monetization model that we think might work, when there’s this other model where people are ready and willing to pay for it?’
That’s when we decided ‘let’s just open source everything.’ And then monetise based on the hosted version.
Interestingly, after we open sourced everything the features that were previously under a paywall, people started identifying bugs in them (not surprisingly) and more people started using it.
…
Overall, going 100% open source has helped us mature the product for different use cases.
Of course, monetizing an open source product via SaaS comes with its own challenges. Since we’re hosting it, we have to be worried about uptime and that we’re looking at scalability and making sure that we’re looking at things in correct ways.
🤝 Founder social:
Until next time,
Team Relay (Chargebee for Startups)