*True* switching costs 🦖
The (secret) strengths of clunky software, postponing integrations early on, and managing without being “micromanagey."
Welcome to the 85th 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: Cascade’s co-founder and CEO, Jake Fuentes, keenly unpacks a surprising, unsparing realization: that replacing legacy (even desktop!) software isn’t always a straightforward affair.
#2: Summit’s founder and CEO, Matt Wensing, argues for viewing integrations at closer range, putting them off for a studied while, and being alert to their immediate positioning and pricing signals.
#3: CommandBar’s co-founder and CEO, James Evans, offers a novel framing for approaching managerial hurdles that most first-time founders face.
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 (October 27th) — Bootstrapping after 8 Years on the VC-Backed Path, Getting to Multi-Million ARR with a Team of 3, and Notes on PLG with Userflow’s Co-Founder, Esben Friis-Jensen
— Why Esben bootstrapped his second startup
— Notes on scaling thoughtfully as a small team
— Setting the PLG foundation from day one
#1: *True* switching costs 🦖
(From: Cascade’s Jake Fuentes) (Source: Lenny’s Newsletter)
We thought we had landed on a startup gold mine. Alteryx, an early-2000s-era software company, was about to clear a billion dollars in annual revenue. Their only product was a Windows-only, clunky desktop application for which each user paid over $5,000 a year.
They were the only player in their esoteric market and seemed incapable of delivering anything that resembled modern software. Getting the application started took several incantations and a minor miracle, and one look at the interface revealed a stark contrast with the lightweight, browser-native applications we were used to.
We set out to build a competitor, confident that we could out-execute them and steal major market share.
The problem was that Alteryx users actually liked the product. It was clunky and probably needed to be moved to the cloud, but it delivered on its promise, giving its nontechnical users the ability to build logic the way their engineering teams did.
Over the past 15 years, it had also amassed a community that helped each other solve complex data problems. The desktop app was a big part of the offering, but the community had helped solidify its moat.
We chalked all that up to the fact that users had no real alternative. Besides, we knew that Alteryx was horrendously expensive, which left buyers frustrated even if end users were not.
While most of their customers were not actively seeking an alternative, cost alone led to reasonable success getting companies to evaluate their options.
If we could overcome switching costs, we saw a path to real growth.
Generally, teams think about switching costs as the amount of time and money needed to install one solution and remove another. But true switching costs are much more than that: they include the politics, emotions, career ambitions, esoteric business processes, competing priorities, and sheer laziness that all favor the existing solution.
Those forces can be incredibly strong, working to ensure that inferior products can still win (have you ever used Bill.com, Concur, or even Salesforce?).
In our case, we underestimated how deeply Alteryx was integrated into company processes. Only a couple of people inside those companies actually knew how Alteryx worked, and hell would freeze over before we convinced them to abandon a career-defining tool.
While ‘normal’ users were willing to switch, we didn’t go far enough to facilitate replacing old work and to convince power users that we were the future. We thought the product would speak for itself. While it did to some degree, we needed more.
Many old-school companies seem ripe for disruption but are actually much stronger than they appear. Others appear strong but are secretly vulnerable. If only the user is frustrated, you’ll have a hard time winning.
If only the buyer is frustrated, you have a path to victory as long as you can overcome switching costs. Only direct input from customers will reveal the true story.
Related Relay reading:
Userlist’s co-founder, Jane Portman, on how a product category with alluringly high retention also has high switching costs (“Userlist is extremely sticky, but so is our customer’s previous tool.”)
#2: Integrations as positioning anchors 💡
(From: Summit’s Matt Wensing) (Source: Relay)
Until you’re really confident about who you’re building for, postponing integrations can be really beneficial and grant you the extra agility to change during the early days.
I know that integrations are getting easier. There are now platforms where you can write one integration and they, in turn, allow you to integrate with others in a given category.
But it’s still worth waiting.
We put off quite a few integrations for a while and I’m glad we did.
A lot of people write to product teams and ask, ‘does this integrate with X?’ That can be a vague premise to start working on one. So we have to push back and try and answer questions such as:
If this was integrated, what data would you want?
How often would you want that data?
What would you actually do with it?
In Summit’s case, we found that most people requesting integrations didn’t really need them. Sometimes all they wanted was to automate the collection of small bits of data. Or the ability to upload a spreadsheet.
Deliberating over each integration request can help you stay nimble and not overinvest in an area that you’d likely won’t even need, until you know who your most appreciative customers are and how they want to use your product.
Once you do know that, integrations can be fantastic.
They can anchor your product into a specific positioning.
They can tell people what you are and what you aren’t.
When we started, people wanted us to integrate with QuickBooks, because we were seen as a financial platform. Today, we integrate with HubSpot and other CRMs as that’s supportive of the use cases we know we solve best for growth and marketing teams.
An integration can be an opportunity to signal to potential customers that we exist in this space and not that one.
When someone sees that we integrate with HubSpot, they might observe that we work with numbers but they’re likely not going to conclude that we’re a financial tool. They’d probably even assume that we must be a tool for marketers or salespeople.
Pricing is another such signal.
If I’m paying $65/month for QuickBooks that price point will influence how much I’m willing to pay for an add-on that integrates with QuickBooks.
The way we read this is that if someone has invested time and resources into setting up a CRM or a marketing hub, they’re pretty serious about their marketing technology stack.
That’s helpful in two ways:
It gives us a really high pricing anchor,
It also lets us say and commit to, “we’re going to help you get more value out of the 20K/50K they’ve invested in their stack.”
Part of your price tag, then, is equipping them to use a platform better and more often, and as a result, get disproportionately more out of it.
Related Relay reading:
Arrows’ co-founder, Daniel Zarick, on how deleting 1/3rd of their product and betting big on an integration made their offering 10x better (“So while it felt stressful at first to not improve the part of our product we felt was weakest, it became clear that it was more important to spend as much time as possible improving the core product.”)
#3: Founder as Chief of Staff 🫡
(From: CommandBar’s James Evans) (Source: LinkedIn)
A lot of Series A/B startups have a chief of staff.
At CommandBar, I AM the chief of staff.
Something I (and a lot of other first-time founders/managers) struggle with?
Gyrating between two modes:
1. Hands off — they will figure it out and flag to me if they need help.
2. Micromanagement — daily check-ins, review everything together, etc.
A key problem for me as a first-time manager: it's hard (for everyone) to know when people could use help.
Sometimes they will overestimate their capacity. Or not know whether I have capacity to help them. Or have a different prioritization function than me.
And most people IME just generally find it hard to ask for help.
The problem is compounded at a startup where roles and priorities are so fluid.
"How can I figure out where my reports are overextended, without relying on them to tell me or being micromanagey?"
Here's the solution that changed things for me:
I spend 2-week stints serving as a ‘Chief of Staff’ to different people are our company.
They can throw any task my way, no matter how random, minuscule, or massive it may be.
Whatever project needs to make progress (quickly) that they don't have capacity for, I'm there to serve 🫡
Not only does this help them get more work done, it helps me figure out:
1/ How busy they are
2/ What's falling through the cracks that may need a new hire to fix
3/ Whether their prioritization function aligns with mine
🤝 Founder social:
Thanks for reading! 🌻
Team Relay (Chargebee for Startups)