Taking on Google and Microsoft šš
On the structural disadvantages of incumbent enterprise software, a product cadence for tackling complacencies, and considering both bootstrapping and fundraising as mere means to specific ends.
Welcome to the forty-third 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Ā Airtableās Howie Liu, folkās Simo Lemhandez, and MagicBellās Hana Mohan.
Recently on Relay:
AMAs (upcoming) ā Tomorrow, weāre really looking forward to hosting Boomerangās co-founder and CEO, Aye Moah, for a Relay AMA. From their principled stance on building software that respects the whole ecosystem, to their understated, shake-your-head-in-wonder influence on emails over the past decade, and a founding commitment to give back to the world, Aye Moah and team have built a unique business that serves millions of active users and competes with tech giants, profitably and sustainably. If youāre keen on joining, please request an invite, here.
#1: How Airtable took on Microsoft and Google ā Airtableās co-founder and CEO, Howie Liu, explains why they resisted the route of building an āoverall better/enhanced spreadsheetā and instead found abundant traction in only solving for a focussed subset of use cases.Ā (Source: Station F)
We got this conviction, little by littleā¦by doing research on the space. We talked to a lot of people who had worked on similar products or companies over the past few decades.
We went out and talked to the person who conceived Microsoft Access, we got to chat with Steven Sinofsky early on, who had overseen a lot of the work of Office and Microsoft throughout its history. And we got to this conviction that thereās no structural reason why this product doesnāt existā¦
We also realized that the product offering would be fundamentally different from what any other company was particularly good at or had in their arsenal right now.
ā¦they [Google and Microsoft] had the structural disadvantage because they were already focussed on building an office suite in the same old traditional mould instead of reimagining what this product could be.
ā¦
To be honest, that [making people switch] is an area where thereās definitely a little bit of luck. Because you never really know if youāre going to have enough of a compelling reason to get people to switch until you bring it out to the world and get people to use it.
I do think few of the specific tactics that we used [were helpful.]
The very premise of Airtable was not just to be an enhancement of or a better Excel or a Google Sheets, but really we were focussed on a subset of use cases for spreadsheets. Mainly, if youāre using a spreadsheet for number crunching, Excel or Google Sheets are going to be the right products.
Thatās what spreadsheets were made for. Going back all the way to the eighties; VisiCalc and Lotus 1-2-3, and then later evolutions of Excel, the spreadsheet was really a number-crunching tool.
It turns out, though, the majority of times a spreadsheet is used is not number crunching, itās actually organizing lists of content, itās creating inventory, contact lists, customer lists, and weāre basically building a database or even an app inside the spreadsheet.
So we were really focussed on just making Airtable awesome for the latter use cases. Weāre not even trying to compete against Excel or Google Sheets for any number-crunching use cases.
We didnāt try to build any advanced number crunching features or graphics features for instance on day one. That would have been an uphill proposition. As those products are so good at it.
[Instead] we really focussed on things like file attachments, having things like rich field types, so that you could do more than just put in text and numbers. And starting to do things that then were really visibly better than those products for organizational use casesā¦.
So the fact that you could expand a row and actually see it in this form view, see the long comments, and access it on mobile in a more app-like way.
We really focussed on the job-to-be-done and made sure that we were hopefullyā¦5 times better for those use cases.
So picking a smaller sub-problem rather than trying to go heads-up against these products and say, āweāre categorically better Excel or Google sheets,ā was part of the key.
#2: Finding focus, priority, and rhythm on the road to PMF ā folkās co-founder and COO, Simo Lemhandez, on shipping incremental product changes and breakthrough bets with a similar level of preparedness and consistency. (Source: Relay)Ā
When building a product, there are a million things you could be doing. Improving the details, solving painful bugs, working on the infrastructure, etc. The choices can bring in immense overwhelm for lean, early-stage teams.
Are improvements the best way to spend scarce engineering time? Or should we build on new bets that can be game-changing for the business? Because we canāt get to hone our product-market fit by the way of bug fixes and small improvements, alone.
So weāve tried addressing this challenge based on the three key things that, we believe, should matter most to any startup:
1. Rhythm. We think that iterating faster will help us stay ahead and potentially win the market.
2. Focus. We want to be focussed on a few things at a time. Of the million things we could be doing, we want to aim at a few. And do them really well. Inculcating rapid execution as a habit.
3. Priority. Being focussed helps, but how do we make sure weāre focussed on the right things? Thatās why user research and discovery (more in these, below) are so critical in order to prioritize the highest value projects.
These beliefs have informed folkās approach to project management, what weāve humbly named, The Cadence š„. A framework that allows us to regularly deliver sizable changes to the product.
For a project to fall into the cadence, it needs to be a high-impact bet. Something absolutely new and ambitious. Not a refinement to existing functionalities.
And when framing such projects, we tend to make arbitrage based on the triangle of constraints: time, resources, and scope. In order to maintain a high celerity and rhythm of testing new ideas, we allocate projects where weāre fixing 2 of these constraints.
Weāre choosing to fix time (always, very intense, 3 weeks) and resources (often 2 teammates on the project) and letting the project team choose the scope based on what is pitched initially.
This translates to the following practical implications:
* We deliver at least one major increment for the user every 3 weeks
* No projects shall be longer than 3 weeks, leaving the tech team to make hard decisions on the MVP
* Product and design teams will be in charge of centralizing all assets so a project can start in a Notion note
* Each dev alternates one cadence project with one bugfix session
* Each project must start by a tech scoping phase: deciding on what weāll commit to and what weāll say no to across the 1st, 2nd, and 3rd weeks. This helps align expectations, take ownership, and clarify steps.
* Devs should be able to start from a clean product context (analytics, clear wireframes, prototypes, user stories, etc.)
* And in the overall scheme of engineering schedules:
* 1/3rd of our time is spent on cadence projects that could change the face of the product
* 1/3rd of our time is spent on improvements projects
* 1/3rd of our time is spent on bugs, minor improvements, quality, and tooling
At the end of each cadence, we implement tracking using Segment. We identify some hypotheses that we want to validate for a given cadence project. For instance, how much should it be used, at what frequency, and so on.
And we let our users try it out for a set no. of weeks. And then for the next iteration of a project, we do a quick summary of our findings.
The chief constraints are around switching from one project to another. Cadence projects are deliberately structured without a cooling-off period. So the transition is sometimes pretty challenging.
#3: āThink of bootstrapping [or any other form of capital] as a tool, not as a way of lifeā ā MagicBellās co-founder and CEO, Hana Mohan, surfaces (and sees through) common beliefs and assumptions surrounding bootstrapping and fundraising.Ā (Source: Relay)
So the reason I switched from building SupportBee to MagicBell, from being a self-funded business to the VC track, was because I wanted to start afresh and because I understood the workings of the SaaS flywheel much better.
I had realized that typical, high-growth SaaS businesses required front-loaded investments into the product, customer support, and other foundational functions. A solid base for future, compounding revenue growth.
Thatās something fundamental to SaaS. Much of the value exists ā in getting retention right and gradually expanding your reach ā in the future.
So it only makes sense to invest upfront.
I had begun to see the other side of a mainstay (assumed) constraint, most bootstrapped businesses apply to themselves: āYou shouldnāt raise money. You should be profitable all the time.ā
If you can bootstrap, then more power to you, but itās actually getting harder and harder to do that, given the landscape weāre in today.
I was very aware that I wanted to raise money, build a sizable company, solve a daunting industry problem thatāll keep me engaged for at least a decade if not more.
The funny thing is when I was bootstrapping, some people would say, āyou can raise a 250K round or something. And we would say, āwe can make that ourselves in a year, we donāt need an investment.ā
Then, on the other hand, I also believed if you do raise a few million, youāre pretty much all set. And, of course, when you raise those few millions and you start building a company, you realize that you actually need even more money.
With more cash, I used to think, you could start paying people 100K/150K salaries or whatever. And then people will just flood the doors. You will have an infinite supply of amazing people. Itās not at all true.
Youāre very much constrained by how fast you can grow a good team. And keep things coherent. Money makes certain things easier for sure, but also brings its own constraints.
A key one being: You need to grow at a certain pace year-over-year. You need to be growth-focussed. You need a long-term mindset and you can no longer delude yourself with, āitās fine, we have a lot of money in the bank.ā
As a self-funded operation, you control your own pace. If, in a given month, you feel a little burnt out, you can take it easy the next month. So you definitely lose that flexibility. Thatās the game youāve gotten into.
When you raise, you also lay out a big vision, which attracts people whoāre keen on growing fast and not settling for anything less.
All that said, I still retain the bootstrapperās mindset. I still value being profitable a lot. But itās not the thing that I value the most.
Capital, Iād tell my past self, is just another tool.
Back in 2010, many founders like me, got their sense of self-worth in being ābootstrappedā founders. Not deploying bootstrapping as a tool when necessary, but bootstrapping as a way of life.
If you root your identity in being a bootstrapper, then itās very hard to change. If you root your identity into being an entrepreneur, into being a problem solver, then itās markedly smoother if not easier.
You should define your core values as a founder. But then also be honest with yourself about where they come from. Your own first-principles understanding of the world or as a result of following someone else.
The other thing people donāt realize is that core values do shift over time. They are not truisms that are forever true. For example, the whole āJeff Bezos and doors being used as desksā story. If you donāt have doors as desks, it doesnāt mean your company is wasteful.
People think that if āI have a core value of frugality now, then I will always have it.ā Maybe you will. But you donāt need to. Itās your choice. Itās a good tool, now. But you should be able to throw it away when it isnāt.
So fundraising was a very conscious decision. It came from my personal experience of having been an entrepreneur on a given path, and then, deeply personal also, in that I went through a gender transition and came to the other side wanting to carve a new identity for myself.
Until next time,