"How our free plan stays free" š¤«š²š
The many tells of shipping fast (and faster), an inquiry into the architectural feasibility of freemium, and a system for collective ownership and alignment.
Welcome to the forty-eighth edition of The Baton. A fortnightly newsletter that brings you three, hand-curated pieces of advice drawn from the thoughtful founder-to-founder exchanges and interviews taking place onĀ RelayĀ and the interwebz. So, stay tuned!Ā
In this edition, youāll find instructive and inspiring pickings from the brains ofĀ Arcadeās Caroline Clark, Tailscaleās Avery Pennarun, and Plumās Caitlin MacGregor.
Recently on Relay:
AMA ā Referral Rockās founder and CEO, Josh Ho, on why he thinks they wouldnāt have made it as a VC-backed business (āa lot more was learned about our customers, market, and behaviors because of the slower pace we moved that had less pressureā), figuring early-stage sales, learning from a diverse set of sources (āI try to always see all sides and am open to all roadsā), asking fun (āhow do you visualize seasons and time?ā) all-hands questions, and more!
Heuristics and Hunches ā Collaborative Operating System: Confronting a Common Leadership Error and Fixing the āUntrained Muscleā of Alignment with Plumās Co-Founder, Caitlin MacGregor
#1: āIām paranoid about slowing shipping speed as we growā ā Arcadeās co-founder and CEO, Caroline Clark, outlines how their particular fusing of culture, people, and processes (āor lack thereofā) enables them to ship faster. (Source: Caroline Clark)
Shipping fast is the universal mantra of startups. It is how we win against incumbents. Yet, if we scan the startup universe around us, we can see degrees of variance in shipping fast.
A quick tell is the changelog cadence. Are they updating frequently? Another tell is how fast the startup fixes bugs. If a customer reports a bug is it fixed within the hour? The day? The week? The month? Orā¦.never?
Finally, the most obvious tell is using the product frequently and noticing if it feels lighter (faster load times, fewer steps to get some actions done) or heavier over time. There are a few tools that Iāve grown to enjoy using more and more as time goes on, and a few that I can tell have barely changed.
In this post, I share a little bit more about why shipping fast is so important to us, and a few things that we do startup-wise that I hope we retain as we grow.
ā¦
Culture of ownership
ā¦
Here are tangible ways about how we promote this culture of ownership:
- When someone joins Arcade, they join all customer calls for the first few weeks.
- Our Intercom channel is open inside Slack in a global setting. Anyone can join and hop in for a conversation when a customer reports a bug ā the only rule is that we have to close what we started.
- If a customer emails someone about an issue or have feedback, we route it to the engineer who built it and forward it to Productboard which is accessible to everyone.
- When someone is about to ship something, they must watch a few customers use their tool.
Ownership translates to speed because it means: āif you see something wrong, you can fix it.ā We donāt require any review or process other than a pull request (PR) for code quality.
Ownership also translates to speed because generally speaking, urgency increases when builders see the pain directly in front of them. Once there are degrees of pain between the customer and the builder, thereās not as much incentive to make it great.
The right people
Iāve quickly discovered that this culture is not something that everyone enjoys being part of. The reality of this culture means that thereās a lot of ambiguity and some people only like coding, and not talking to customers. Thatās okay! But probably not a fit for Arcade at this stage.
Minimal process and meetings
Overall, process and meetings = slower speed. Some process is necessary to ensure that we donāt break things all the time. Our process at Arcade right now is:
- Monday morning Rich and I have a chat about our priorities for the week. This is connected to the overall goals that we want to hit product and growth-wise. We then map this out how the teamās work is structured.
- After that meeting, we have a team sprint planning session to discuss what we want to get done for the week. People are encouraged to propose their own ācardsā which are task specific pieces of work connected to larger projects.
- We have a daily standup T, W, Th, and Fri. We experimented with async but we found that things got lost in translation. We may continue to experiment with it.
- Friday retro to discuss the past week.
- Dev-wise, we do PRs which are reviewed by the team. Sometimes we pair program if thereās a particularly complex piece, but that is ad hoc.
- We do a hackathon (aptly called Turbo) once a quarter. A surprisingly high amount of things that we do in the hackathon make it into the product. For example, after our last Turbo we shipped new settings and a new capture experience a few days later.
As time goes on and we grow, I want us to move towards/fewer/meetings. Because we talk to customers so frequently and the market changes a lot, we kept sync meetings to chat about what weāre learning.
ā¦
Iām paranoid about slowing shipping speed as we grow. In the long run, I hope we end up like Stripe, which clearly has done a great job despite their size.
#2: āHow our free plan stays freeā ā Tailscaleās co-founder and CEO, Avery Pennarun, heads under the hood to share the almost-never-revealed workings of costs that inform their freemium flourish. (Source: Tailscale blog)Ā
TL;DR: Tailscaleās free plan is free because we keep our scaling costs low relative to typical SaaS companies. We care about privacy, so unlike some other freemium models, you and your data are not the product. Rather, increased word-of-mouth from free plans sells the more valuable corporate plans. I know, it sounds too good to be true. Letās see some details.
ā¦
Perhaps weāre not supposed to say the quiet part out loud, but itās important for the discussion. Our architectural decisions were made carefully, and are paying off.
In How Tailscale Works, we discuss the separation between Tailscaleās ācontrol planeā (the centralized service we run to help your nodes find each other) and the ādata planeā (the peer-to-peer network that sends end-to-end encrypted data directly between your nodes, not through us).
This āhybridā centralized/decentralized architecture lets corporate users centrally manage, audit, and lock down their distributed network, while still eliminating packet bottlenecks and optimizing latency.
But it serves another purpose too: it makes the operational costs for us extremely reasonable.
SaaS companies typically track three major kinds of costs, spanning both infrastructure and salaries: product development (āfixedā costs, since they donāt vary with number of users); customer acquisition cost (or ācost of salesā); and cost of goods sold.
- Product development is where most of our money goes. We use venture capital money to accelerate growth, not to survive. Almost all SaaS companies are initially ācash-flow negativeā - on purpose, but always with a path to become cash-flow positive on demand. We never āsell each unit at a loss and make it up in volume.ā Thatās not how you become successful.
- Customer acquisition cost (CAC) is marketing, sales, and pre-sales support activities. Our cost of sales is currently low, because Tailscale spreads primarily through word of mouth. Continuously improving product quality, implementing self-serve payments, writing good documentation, and helping people find community support, all help keep sales costs low.
- Cost of goods sold (COGS) is where the majority of our scaling costs lie. Tailscaleās COGS can be divided into three main categories:
* Scaling and operating the coordination service. This is the control plane, including the āpublic key drop boxā that your nodes use to find each other, log in, set ACLs, etc.
* Scaling and operating the DERP network. These are relays for your (still always end-to-end encrypted so we canāt read it) traffic when a point-to-point link canāt be established.
* Providing technical services and support.
Although itās hosted on an expensive service (AWS), the coordination service footprint is carefully minimized to keep its costs manageable. (We could currently scale to, say, 100x our existing volume before I start to be alarmed about the cost of running the coordination service. But if that happens, one expects our revenues will scale up too (perhaps after some lag), and then I will go back to sleeping well at night.)
ā¦
Finally, of those three parts of COGS, tech support is our biggest expense, because it requires non-scalable human time. Right now, Tailscale provides free human support to all of our users. Itās an area weāve explicitly chosen to invest in.
ā¦
Luckily, weāve observed that on average, support questions arrive mainly during the early days after a user signs up. This is common for many kinds of products. It means costs mainly scale with the rate of signups, not with the accumulated total number of users.
Plus, people with more advanced support questions seem to turn into paying customers more often. That means, on average, itās worth our time to continue providing great support to everyone who asks.
ā¦
All this is to say: our costs are carefully managed. Like other SaaS companies, we donāt build physical infrastructure. We avoid touching your packets - for privacy, but also to reduce our costs.
We fix bugs and docs instead of answering the same questions over and over. Our control plane is lightweight, and our DERP network is cost-controlled. This allows us to maintain healthy operating margins, so that a free tier isnāt competing for resources with our paying customers.
#3: Fixing the āuntrained muscleā of alignment ā Plumās co-founder and CEO, Caitlin MacGregor, on finding a system of collective alignment that equipped a VP of Engineering to contribute, as critically as a CRO, to a breakthrough RFP win. (Source: Relay)
First, we settled on a cadence of quarterly goals cascading from a larger annual goal.
And I knew that if I was going to do this every three months, I needed a process that I could build once and run over and over again.Next, I started looking for frameworks we could study and adopt. What immediately stood out to me as I was doing research, was that most of these operations frameworks relied on an underlying theme of keeping people accountable.
They all seemed to start from a place of: āI donāt necessarily trust that youāre going to do what you said you were going to do, therefore Iām going to make you write it down and make you report back. Because without this level of accountability youāre just going to collect a paycheck and not deliver.ā
All seemed bent on isolating who owned a given function and how exactly were they missing the mark. And, to me, that was simply backwards.
Because if youāve hired right, people will be driven to get their job done; you wouldnāt have to chase anyone on their execution. What they might not do is take the time to align with the rest of the team on what the right collective goals are.
So I wanted something that went beyond āwhat am I going to deliver as a department?ā and got to āwhat are we owning as an exec team holistically?ā
I wanted that collective ownership to ensure that with the amount of people we had and the amount of resources we had, what we were biting off for the quarter was achievable.
If the product team was being pulled in one direction by engineering and being pulled in another direction by marketing and then in another by sales, I wanted their goals to have enough room to accommodate the different priorities.
I wanted a system that could communicate, āhey, these meetings, with these other departments, on these joint concerns, need to take priority over other things.ā
After reviewing various approaches, I finally settled on taking a professional development course (which lasted a year) called the Collaborative Operating System (COS); it helped me learn the mindset and principles needed to build true collaboration.
The COS training showed me how I could create a culture that wasnāt top-down, had joint ownership and collective buy-ins, where everyone was organically trying to accomplish something together.
Then I reached out to consultants who had run several alignment efforts with executive teams at companies similar to ours, to understand what the common challenges were.
And one of them told me, āwhat happens is when a VP of Engineering is giving their update, the sales leadersā eyes start to glaze over as it doesnāt relate to them.ā
āThis update isnāt getting you anywhere. Itās not benefiting the company. Itās not holding anybody more accountable than others. Because people always have a way of making themselves look good.ā
When I asked her how she had countered this in the past, she said, āwhat Iāve found to be especially helpful is to create goals together as a leadership team.ā
Figure out what at the company level are you collectively creating together. Donāt have department goals first. Have company goals first. So that everyone is owning them.
So if you set a sales target, that is a sales target that engineering realizes they may have an impact on, because they may have a customer request they can help prioritize to unblock a deal.
Or they may have due diligence on the security and the infrastructure side that they should be part of and have joint goals where everyone can see themselves reflected, and that theyāre jointly owning that goal.
If someone has to drop what theyāre working on to jump in and help they know that thatās the right use of their time. Thus we had to come up with quarterly goals that each of our leaders saw as their departments being able to support and drive.
And not every single goal necessarily involves every single department, but the more weāve done this, the more we actually see how every single leader is tied to delivering on every goal that weāve laid out.
When we began saying, we wanted to hit this revenue target together, for the first couple of quarters, product and engineering felt they couldnāt possibly directly influence revenue goals.
Well, we just won a huge RFP.
And our VP of Engineering played an integral role in us winning the RFP. He dedicated a lot of time to being a part of the presentation, doing prep, and creating visual mock-ups so that the customer could better understand what was going to happen from an implementation standpoint.
He had to put down other things in order to do this. Because we were all aligned on how important this was, it made sense that the VP of Engineering was playing just as much of a part as our CRO in the RFP process and we won it because of that alignment.
Until next time,