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,