Your "super-custom TAM" 🪡 🌊 🔮
A reminder on the fast-long-slow ramps of SaaS growth, what makes founders better hiring managers, and shaping a long-run product (platform!).
Welcome to the 69th edition of The SaaS 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 (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: Gainsight’s CEO, Nick Mehta, reroutes the context of startup growth to a market’s inherent capacities and suggests sizing up “super-custom TAM” among other corrections in order to pull through (mostly inevitable) rough patches.
#2: Chameleon’s co-founder and CEO, Pulkit Agrawal, insists on not sticking to a seemingly standard, linear hiring path and just getting to the smallest first step (and taking the next de-risked step, side by side).
#3: Lucid’s co-founder, Karl Sun, on thinking in platforms; or what it takes to scale — technically and culturally — for serving ever-widening horizontal use cases.
🗞 Recently on Relay:
Heuristics and Hunches — “Design Partners are Just Early Customers” and Other Notes on Structuring Early-Stage Research with Spellbound’s Founder, Akshaya Dinesh
— How design partners are really early customers
— Choosing design partners at various stages of growth
— The hands-on work of onboarding design partners
— What it takes to get these early users to carve out hours
— Continuing customer discovery while focusing on a best-fit segment
#1: Is your market growing fast enough?
(From: Gainsight’s Nick Mehta) (Source: Allison Pickens’ Newsletter)
Let’s say you’ve gone from $1 million to $3 million of ARR in a year. That’s amazing. Will you triple again next year? Will you triple again the year after? I hope you do. But the statistics say that’s not always the case.
…
I’ve thought a lot about this topic and there are two different things—large and growing….Gainsight’s market was not large, but luckily it’s been growing. So we had one, but not the other.
On the large side, there’s this classic assumption in business planning that is not right most of the time: namely, that when you build a spreadsheet, you put this many reps in, this much ramp time, this much quota, and that gets you the bookings.
So, if we did $3 million a day new bookings this year, we’re going to do $6 million next year by doubling the sales team. And so you double the marketing spend. But actually, what often ends up happening is you hire all those reps and they’re not that productive.
What’s happening under the covers? In an existing market, one of the challenges is, for example, let’s say there are 1000 companies in your TAM. Not all 1,000 of those are actually in market at any given point.
And for those that are in market, you’re not going to win all of those. What ends up happening is there’s a certain number of new logos you can do in a market in a given year.
What I find fascinating is that in some markets, all of a sudden, everyone needs the new thing. Data warehousing might be a good example of that with Snowflake. In most markets though, it’s more like a steady march.
Every year, there are only a few more people that need customer success software or whatever else is out there.
…
One of the things that ties to this readiness is building a super-custom TAM database. It needs to be something more than a list that you pulled in from ZoomInfo or LinkedIn. These are both great data sources.
But when you build a list of all these companies, you need to look for readiness attributes.
Using Gainsight as an example, there is probably a certain number of CSMs you need to have in order to be a customer. There’s a certain size of your subscription business you need to have. But also, you probably need to have a certain maturity in how you’re using your CRM or Salesforce.
A lot of our customers use Snowflake, so maybe they have to do Snowflake first. There’s also an IT prioritization, which is like that company you mentioned, where sometimes you implement one software product first, and then something second, something third.
For example, with Gainsight, very often people implement or update Salesforce and then they buy Gainsight. For many years, we tried to get customers to do Gainsight first. They would tell us no, they are not doing Gainsight first.
One of the things I wish we’d done earlier was a very custom TAM where you start with all the companies and you build all these attributes. How many CSMs do they have? Is the CSM team growing?
There’s nothing more valuable than knowing every single potential buyer in your market and where they are in the maturity process. Even if you have to survey them and ask them if they are in the market for software.
That is gold.
Finding these hard-won founder takes valuable? Consider forwarding this edition to an ever-curious teammate or a much-cherished SaaS friend? :)) New readers can sign up here.
#2: “HIRE IN PARALLEL”
(From: Chameleon’s Pulkit Agrawal) (Source: LinkedIn)
🧐 I’m realizing that we’ve had an implicit tenet when building Chameleon that maybe isn’t as obvious as I thought: HIRE IN PARALLEL:
There are many times when you don’t have the right/perfect skillset on your team for a key activity/project, e.g.
📎 You need competitor battlecards but don’t have a PMM
📎 You need to improve your user onboarding but don’t have a growth PM
📎 You need to better track customer health but don’t have a Head / VP of CS
In these and other similar situations, I notice a lot of founders/companies approach the problem “in series” 🛣
They use this gap to create a job rec, get that approved, source candidates, hire, ramp etc. and then have the new hire work on the project as a high-priority. 🥵
Another example of this I see is when teams hire a VP as the first hire in that function (e.g. VP Sales as the first sales hire or VP Marketing as the first marketing hire).
This has quite a few downsides:
☢️ You delay making improvements
☢️ You don’t understand the intricate details of the project
☢️ You add significant risk and pressure on the new hire
☢️ If the new hire fails, you’ve lost a lot of time
My approach is not to wait for the hire, but to get started with the first, small, step on that journey, and work on the hire *in parallel*.
For the examples above:
➡️ Create a simple Notion page and put whatever objections or differentiation knowledge you have there ✍️
➡️ Come up with the first low-hanging fruit experiment to run 🍏
➡️ Add a field in your CRM that your CSMs can manually update with a traffic light input 🚥
You may object that the team is already pretty stretched… but that’s why the founders exist 🙃
📌 The founders must be able to do any job on their team at a basic level.
This not only teaches founders the details of the project, but de-risks it for the company, and for the incoming new hire. (It’s much easier to pick up speed when you join a team if it’s not at a standstill.)
💡 It’s the lean (vs. waterfall) approach to company-building and makes founders better hiring managers and leaders.
So if you’re hiring right now for a role that you think will unlock something for your team or company, consider what the first step of that work is and whether you can do it sooner.
📌 If your VP is pinning some key objective on an incoming key hire, ask them to make a start on it before the new hire joins.
🏃🏽♂️ Get started today and let me know if I can help; happy to share how we do something at Chameleon.
#3: Build for more than one need at a time
(From: Lucid’s Karl Sun) (Source: Traction)
We thought about how we could build for an immediate need but also solve the need in a way that would allow us to solve similar need that we knew would come down the road later.
This was a true shift in the way we thought and, ultimately, it worked.
But let me be really clear. This took a lot of time. And it was hard to do.
The reason why this was hard was because teams had a lot of competing incentives. We knew that we wanted to and were building this platform that would, in the end, help us develop faster and make our offering more powerful.
But it also meant in the short term as you were developing specific features, it was going to be a lot slower because you had rethink about building the platform and building on top of it.
It will take double the amount of time. Even longer for those first few things. And, as you know, product/dev teams are always under pressure to deliver faster.
So there was always this trade-off between when do we have to do it the right way. Build a platform. Build things on top. And when do we need to just get this thing out there; in 3 weeks or 6 weeks or a quarter…
Realizing that when we chose the speed to get a certain feature to market and didn’t focus on the platform that meant that at some point we’d have to go back and rebuild that on top of the platform and reinvest….A lot of competing priorities.
…
We also deliberately thought about always building for at least two use cases. So that we weren’t fooling ourselves into thinking that we were building something generalizable when, in fact, we were really building something that would only work one-off.
The other side of this mentality shift was really educating our teams to really understand why we’re doing this and how this worked.
So we built a data-focused team whose job was to work on the platform but also to evangelize to all the other teams, how this mentality should affect their day-to-day operations and how they should conduct their sprints.
And reinforce the message over and over.
🤝 Founder social:
Until next time,