Five stages of AI grief 💫
Accepting the enterprise AI reality, why Linear goes slow to go fast, and how open source products don’t succeed on their own.
Welcome to the 82nd 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! And thanks for reading!
In this edition, you’ll find the following instructive and inspiring pickings:
#1: Forethought’s co-founder and CEO, Deon Nicholas, considers (with a 10-year head start on LLMs) how they have come to process the substance of the ongoing AI frenzy and outlines what they’re doing to differentiate in a noisy, everybody-has-access-but-nobody-has-a-moat enterprise world.
#2: Linear’s co-founder and CEO, Karri Saarinen, pins down how isolating thinking (usually with PMs) and execution (usually with engineers and designers) across product roles in the name of speed and specialization often produces fractured, forgettable software.
#3: Sysdig’s founder and CTO, Loris Degioanni, describes how the complex, delicate workings of open source projects ("like a mini company inside a company") must be treated as such from day one.
Finding these discerning founder takes valuable? Please consider sharing this edition with an ever-curious teammate or a much-cherished SaaS friend. 🙂 New readers can sign up here.
🗞 Recently on Relay:
➡️ Heuristics and Hunches (September 22nd) — How Early Adopters Don’t Have to be Ideal Customers, Founder-Done Customer Support as a Growth Strategy, and Other Notes on Building with Reasonable Ambition with Missive’s Co-Founder, Philippe-Antoine Lehoux
— How their first (not quite best-fit) users helped
— Why Missive wasn’t their first product
— Why there’s no shortcut to user love
— Twitter as an early acquisition channel
— Why they don’t have an end goal for Missive
— Winning at pricing without a pricing strategy
➡️ Heuristics and Hunches (September 15th) — “It’s Tempting to Start Selling Something We’d Build Six Months Down the Line” and Other Notes on Early Validation with Alphadoc’s Co-Founder, Job Rietbergen
— Growth lessons, founder-market fit, and Alphadoc’s origins
— How to learn — ask, pitch, and research — better
— Manually onboarding users for a tool that enables PLG
#1: Five stages of AI grief 💫
(From: Forethought’s Deon Nicholas) (Source: Upper Bound 2023)
We had like five stages of grief… At first, it was denial.
‘We’ve built great LLMs, we’ve built all this…let’s ignore this Open AI stuff.’ We had some variant of GPT2 that we spun out and built our own on, ‘this is going to be much better.’ Okay, denial.
Step two was I don’t know what, fear? ‘Okay, people are really loving this, what’s that going to mean for us?’ Then you go through it all. Anger! ‘Oh, this person is launching a GPT integration, they don’t even know how to use this stuff.’
Eventually you get through to acceptance.
The acceptance was realizing that the landscape is changing. Some of it’s hyped, overblown, marketing, whatever. But some of it is that there are new technologies that are rapidly accessible and available now.
Even if GPT 3.5 was available a year and a half before ChatGPT was, so technically, all the stuff even with ChatGPT was possible about a year before.
But it forced a very different conversation. For us, for example, in 2022, we had to go to a customer. We had to bang down the door to explain to them why they need generative AI in their customer support.
Then we’d have to show them. And only after we show them would they be like, ‘oh, this works.’ Like this is why you don’t need those classic chatbots or whatever. And then everything flipped, because in 2023 now customers are banging down our door and saying, ‘hey, my CEO wants this, can we talk?? Yesterday??’
I’m like, ‘okay, that’s a shift.’ That’s a positive shift….We had to throw out about 10-20% of our stack. We integrated with GPT 3.5 and then launched the world’s first GPT integration for customer support in March. And that’s the acceptance.
‘Okay, your customers, your market has spoken.’ Ironically, we can be the fastest to adapt this. Because of everything else we’ve built. Everyone else is building models that hallucinate. We’ve already solved the correctness problem. ‘Okay, cool!’
At the same time, there’s a lot more competition. A lot more startups. There’s a lot more noise. So we have to focus on ‘okay, which parts of our stack are differentiated and which parts are now commoditised because of LLMs.
We had to just go through this exercise and look at it soberly. Some is good. Some is bad. Net, by being able to move faster than everyone else, it’s led to a ton of positive momentum.
…
The weird analogy I have is (it’s probably not even a good analogy). It’s similar to cryptography in cybersecurity. When you create a cryptography algorithm, you never rely on the adversary not knowing the algorithm. If that’s what you’re basing it on, you have a poor password or whatever.
You have to assume everybody has the same information. Everybody has this algorithm. Does your secret still work in that case?
…
In the same way, we now have to assume that everyone in the world is going to have an LLM. We have to assume that that LLM is going to be great. And probably Open AI will innovate faster on this general LLM than anything we do.
So, you have to ask yourself the question: ‘in that world, how do you still survive?’
It’s not a doom-and-gloom, ‘oh, we’re dead.’ And it’s not a rosy picture that that world will never come. Assume the world comes. And assume there’s a way to adapt and survive. What does that look like? So we start focusing on the part of the stack that is uniquely suited to us.
Anything that an LLM will eventually figure out, even if it’s not today, but in a year, we’re not going to heavily invest there.
But, ‘hey, it’s not going to be able to figure out customer’s policies.’ If you had Albert Einstein sitting in front of you, if we all had our personal Albert Einstein, who knew everything, there’s no way that Albert Einstein can know the refund policy of Instacart without having that data.
So there are certain things that even if everyone in the world has the best, most genius model, they would not be able to do. Those are the things we realize that we have that are differentiators.
We are the only platform in customer support that fine tunes and builds on the data. Everyone else starts with a blank canvas, a decision tree, those sorts of things.
So we started to basically focus on, ‘okay, this is where the world is going, this is where the puck is going, let’s double down on that and everything else it’ll get commoditized eventually, and treat it as such.
…
Again, necessity is the mother of invention. Kind of forcing ourselves to acknowledge what is not commoditized, what is going to be a differentiator in five years, that’s the game we play now.
Here are a couple of things.
The first being that language models are very specific models, it’s kind of a coincidence that these are the models that ended up becoming these big foundational things.
In many ways, it was the Transformer that was the breakthrough years ago. But what other models are there and what other classical NLP problems are there that when taken to the nth degree could be foundational?…it’s like a thought experiment, but that’s a train of thought you’d follow.
The second is reinforcement learning. Just, in general. The weird, hidden secret behind ChatGPT is not that they made an LLM really cool. It was that they had reinforcement learning through human feedback to train, to instruct GPT and to figure out how to actually answer the question that the human is trying to ask.
There’s a whole bunch of research and papers on that. And obviously, we’ve seen a tone of things around AlphaGo. Games. Those sorts of things. I think the entire industry, outside of academia, still doesn’t know what reinforcement learning is.
I would be curious to ask the question: how do you start applying these technologies to real businesses and those sorts of things? And I don’t know the answer. But these are the questions I would ask.
…
Salesforce became big because there was a shift from desktop to cloud….They became powerful because there was this entire business model shift. They took, basically a database (Salesforce.com is just a big database) and they took it from desktop to the cloud and now they’re a $200b business for sales cloud, service cloud, marketing cloud etc.
Well, I think we’re in a similar shift right now. So what are the business models that change when you go from cloud systems of record to cloud systems of intelligence?
Everyone freaked out when people said Google has no moat. I think most business models, today, have no moat.
Related Relay read:
Question Base’s co-founder, Yana Vlatchkova, on how “AI hype can accelerate your growth, but not create it” (“With the hype surrounding ChatGPT and their aggressive commercialization, people suddenly became eager for anything AI.”)
#2: Avoiding “Henry-Ford-style feature factories” 🏭
(From: Linear’s Karri Saarinen) (Source: Twitter/Lenny’s newsletter)
One of the unique aspects to Linear is that we expect the project team to be the PM.
In other companies, I’d often see that the PM is or becomes the de-facto decision-maker for the team. When that’s the case, it’s almost like you outsource all the thinking to the PM, and the rest of the team — engineers and designers — just execute based on that thinking. I think it’s a waste of opportunity and talent.
I think it can work for some teams, but what I think works better is to build a team where the project team both thinks and executes. I like to compare how Apple combines CPU, GPU, RAM, and other functions on the same M1 chip to make it more efficient.
I don’t think it would be possible to maintain the quality we have, or build some of the things we have, without this setup. Anyone who has built things knows that a lot of ideas and opportunities emerge when you actually start building something.
A good example of this is when an engineer on our team, Andreas, built the context menus. We didn’t ask or spec it for him to figure out how we can make sure the context menu doesn’t close if the user hovers their mouse a few pixels off.
He just felt it was needed. These kinds of details are almost impossible to spec or plan for if you’re not there building it or if the people building it don’t have ownership.
My take is that this is one of the reasons why so much of the software we have today seems fine on paper but doesn’t actually work well in practice.
We as an industry optimized the process too much and created a Henry-Ford-style feature factory where each role is very specific and production and speed is more important than craft. (The other reason is A/B testing)
It’s worth noting that there are downsides to this approach. It means the engineers and designers do have to play the role of the PM, which includes communicating, talking to users and stakeholders. This means that engineers and designers are not purely coding or designing, which can sometimes feel like it can slow things down.
Personally, I believe often it’s better to go slow to go fast, meaning we generally get projects right the first time, with minimal fixes later. The second downside is that it’s harder to hire for these roles, as many people don’t have experience working this way.
Related Relay read:
Tara AI’s co-founder, Iba Masood, on setting up engineering for growth (“How do we make sure that growth as a discipline isn’t removed from product, engineering, and design teams, and instead becomes a core driver for their work?”)
#3: The open source product lifecycle 🔓
(From: Sysdig’s Loris Degioanni) (Source: Unusual Ventures)
I've at this point been behind at least two or three substantially popular open source projects. And I've always approached the community and generating popularity in the open source tool as a product.
You need a product strategy. You need a value proposition. You need product-market fit. Even if it's free. You need marketing. And you need sales. I mean, sales in open source is slightly different, but you still need adoption.
Every time somebody downloads and installs your product, that's a sale for $0. But somebody is actually taking the time… And then you need to do like product lifecycle management. You need customer success. You need to make sure that your product is sticky. That there's no churn.
[There’s competition, for example…They are part of the same community. You play nice with them, you go to the same conferences. But there's always other tools that do the same thing that your open source tools do. You need to treat that competitively and you need to create an edge and make sure that your solution is the winner.]
So you need to be able to: 1) provide substantial, continuous long term value. And 2) you need to be able to proactively help your customers in adoption, removing frictions and being able to support them.
…
It's like a mini company inside a company that is to have the right sensibility for the open source ecosystem, but approach this as if it's a product that has to be sold and has metrics and sells for $0.
…
We are a for-profit company that is, let's say, bootstrapped around open source. So there are two different… sets of metrics. The first one is the success of your open source family of tools and ecosystem of users.
And there I think there's two (I mean, adoption is king). So, of course, what you measure is adoption and there's a lot of derivative metrics that we use for [measuring] adoption.
But I would say in terms of adoption, there's two different demographics that we pay attention to. One is the contributors and the other one is the end users. They're both important. The end users, of course, are what eventually you want.
But the contributors are what makes your community thriving into a real community. These are people that show up. They contribute. They provide technical enhancements. They fix bugs. They talk to the users. They are champions.
…they are [really] the leading indicator in the success of the product, right?
If you get the contributors that are excited to be a part of your community and you need to create a community that is welcoming to them. Which is not trivial, when you also need to build a business. Then that is a good indication. Then you will also be healthy in terms of end users and adopters.
The other thing that is important for us to measure and to make sure it's healthy is the connection between the open source project and community and the commercial entity (the company behind it).
An open source project brings many benefits to a commercial entity that range from just brand, making you more visible and more liked by a broader set of people, to marketing and the ability to market and to create a positive connection to your commercial product that allows you to essentially market your commercial product in a better way up to lead generation and sales.
This is delicate because it's very hard to balance the true respect for the open source project and the community and the need maybe to have a business and to generate leads. So it's clearly not a matter of asking [for] emails [of] the members of a community. It's not that simple.
And lead generation comes more from maybe people using and loving the open source solutions. Which is, by the way, in our case, completely free and so supportable by anybody in the world, including our competitors.
So establishing yourself as a strong, positive brand connected to that open source project and offering a technical solution that enhances and complements the open source project in a delicate, constructive, and positive way is really the key strategically.
…
For us, the two sides, so the community side and the commercial side have always been… we've worked on them together, in parallel, essentially from the beginning.
I'm not saying that's the only approach. In many cases, maybe for many years, you don't want to even worry about the commercial side and just focus on making the open source side as successful as possible. That's totally legitimate.
Related Relay read:
Flagsmith’s founder, Ben Rometsch, on scaling an open source tool while running an agency and their open source philosophy (“…although we’ve been open source all along, we’ve never positioned ourselves as an open source alternative to X)
🤝 Founder social:
Thanks for reading! 🌻
Team Relay (Chargebee for Startups)