Loom’s GTM stumbles 🚪
Revisiting a SaaS cornerstone, how post-PMF growth isn’t necessarily linear, and shipping fast without shipping dates.
Welcome to the 87th 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: Regrow Ag’s co-founder and CEO, Anastasia Volkova, sketches the particular (vertical-driven) reality of not having an “ultimate” ICP and lays out how they’ve instead served several customer types across an expansive supply chain, at once.
#2: Loom’s co-founder and CTO, Vinay Hiremath, breaks down how two standard sales and marketing assumptions fell wholly short in their context and how they’ve only really identified more suitable models eight years in.
#3: Nira’s co-founder and CEO, Hiten Shah, describes how they’ve redrawn product/engineering lines and roles in a way that “prevents almost 100% of the [software development] problems I’ve seen over 20 years.”
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 (November 30th) — “As We Scale, We Operate More Like a Typical (Horizontal) B2B SaaS Business Rather Than a Vertical One” and Other Lessons on Building an Ag-Tech SaaS with Regrow Ag’s Co-Founder, Anastasia Volkova
— Solving for a complex web of ICPs
— Aligning GTM teams with customer sophistication
— Establishing multiple product-market fits
— Hiring passionate domain experts across functions
#1: Solving for a complex web of ICPs 🏭
(From: Regrow Ag’s Anastasia Volkova) (Source: Relay)
Like any successful company defining product-market fit, there was a lot of trying to understand what works, testing hypotheses, and thinking about what pricing models could be applied for the right value distribution.
All of it, though, came down to addressing some fundamental questions:
Whose problems are we solving?
How are they measuring the benefits?
How are they evaluating the risks?
How can we align our models with what they already understand (such as how they charge their customers and how their services get rendered)?
Then, additionally, we sought to get a sense of how much of the standard “best-in-class” SaaS playbooks and systems could be brought to agriculture. There are things that clearly don’t fit in. And then, there are some surprising things that do indeed align with this space.
For example, it’s interesting to consider the concept of an Ideal Customer Profile (ICP) that tends to be this almost formulaic cornerstone of the SaaS go-to-market philosophy. And it holds across industries. Including ours.
Although things do get a little bit more complicated for us.
Primarily, because it’s hard for Regrow. Given the pervasiveness and complexity of the problems we’re solving, isolating an ICP to only one part of the agricultural supply chain and saying this group represents the ultimate customer isn’t realistic.
Instead, we’ve landed on several ICPs that we’ve systematically unlocked and prioritized based on what’s currently most needed in the market.
As in, where does the current state of climate action stand when it comes to agriculture? Where does it get stuck, and what are the critical challenges to help it scale and unlock itself?
Let me expand on what I mean here.
To unlock the agrifood industry transformation, we need to serve customers across a set of complex supply chains. We need to serve companies upstream. Those that sell to farmers and provide them astronomic advice.
Plus, those that are downstream, and closer to consumers, such as food manufacturers. Then also the folks in the middle (traders and aggregators) to connect the respective supply and demand parts of the supply chain.
What is encouraging, though, based on the patterns we’ve observed is that Regrow is serving a supply chain based on universal demand and supply principles.
More importantly, the roots of our core promised outcomes — enabling GHG emission reduction and ag-resilience strategies — are focused mostly on the farm.
So we are able to look longitudinally at wide groups of customers including agricultural input providers, processors and consumer packaged goods companies. With the ICPs being somewhat different in every part of the supply chain (depending on the parts of the vertical they’re sitting in) but largely having the same goals.
A persona to illustrate this would be a Head of Sustainability, someone who would have similar objectives at each of these companies. They would surely have slightly different purviews stemming from what their company does and what sustainability implies.
But as long as a company is touching agriculture, a significant part of the footprint they’re concerned with, often majority, would be on the farms and that’s where Regrow concerns itself.
To sum up, what comes to the fore is being really clear on THE problem that ties all ICPs together, not necessarily the shape of the solution.
Which is still incredibly complex.
If we look beyond the supply chain component and consider the private sector and the public sector divide, we’re looking at places where similar decisions get made entirely differently. The complications only deepen further.
Related Relay reading:
Basis’ founder, Bebe Kim, on how the founder persona is almost never the end-goal ICP (“If you are starting with founders, will your tool survive the transition to the actual personas?”)
#2: Loom’s GTM stumbles 🚪
(From: Loom’s Vinay Hiremath) (Source: Sajith Pai)
I just think we’re product focused founders, and this was our first time trying to figure out, okay, what does marketing look like at Loom? What does sales look like at Loom? I know this is going to sound insane.
I feel like we finally landed on a really solid growth marketing motion and we’re starting to see the beginnings of a really solid sales motion, which is going to sound crazy — eight years in the game — and we just entered into an agreement to get acquired.
But yeah, I don’t know if this is going to be one of your entries in your book where someone’s going to get great insights in a go-to-market. I can tell people what not to do. I can tell them a lot of what not to do.
For us, we scaled up our sales team, at one point, our enterprise sales team, way too quickly.
We had a bunch of inbounds because Loom was a word-of-mouth, viral-growth product. So, we had a bunch of warm inbounds, and when people were signing up with multiple 1,000s, sometimes multi-10,000s seat deals, we incorrectly assumed that that meant we had an enterprise sales motion.
Which for anybody who’s been doing enterprise sales, they’ll be like: of course, you don’t. There are a lot of complexities in an enterprise sales motion. You have to think about the information architecture. We’re a communication product. Where does it fit in your org? Who’s the buyer?
We really didn’t have a repeatable enterprise sales motion. We scaled up our enterprise team thinking that we did. When we exhausted our warm inbound leads, we found out we didn’t.
And now we feel like we actually kind of do and we’re getting there, but it’s after making this pretty perilous mistake of thinking that we did when we didn’t, just because we have leads.
The thing is, if you have a viral product, just because you have warm leads doesn’t mean you have repeatable leads that you can go out and farm. We’ve learned a lot since then…
It feels like we have the beginnings of a pretty repeatable motion in mid-market, and there are some inklings of enterprise (motion) as well. But that’s one huge learning.
Another is that for a product like Loom, we are lucky to have a brand that people care about. We’re so lucky because today’s world’s so noisy… we have a brand where people associate their face with being on top of their work.
So, there’s a lot of people who love Loom, and I really think Loommates broadly are grateful for that, but they sometimes need to be reminded. And with our marketing motion, it’s like we really leaned into a lot of brand marketing early on.
If you have a brand that’s working, I don’t know how much you really need to lean into brand marketing. I don’t know if I would do that (if I were to go back). I think a lot of people look at Apple. I know we did. They look at Apple and they’re like, ‘oh, amazing brand.’ ‘You need to nurture it by building out the brand and corporate marketing team.’
You don’t need to do anything. Your job is to not f***k it up. That’s your only job… your job is to understand why people come to your platform and continue to deliver on that. And we lost sight of that.
So now we’re finding out that actually, the best type of marketing for Loom is just regular paid ads. It’s growth marketing. It’s like the really unsexy stuff that just like: What’s this channel? What’s the LTV to CAC? And for anybody who has a great brand, don’t scale up a brand marketing team.
Just start figuring out what your channels are, start doing paid, see if that works. Start looking into content. It’s not the sexiest thing, but you don’t need to do a sexy thing. You already have the brand. That’s another mistake we made.
Man, we made so many mistakes, honestly.
Related Relay reading:
Pulley’s founder, Yin Wu, on constantly reinventing the GTM wheel (“Most startups miss that a GTM strategy needs to be a plan and not just a list of ideas. A plan includes a goal and a schedule.”)
#3: When engineers own (end-to-end) solutions 🏁
(From: Nira’s Hiten Shah) (Source: The June Podcast)
The way we do things is that we embed the solution (the sort of building and specking) in the engineering team. And we want them to take ownership over building the right solution. The only way we found of doing that is by pushing a lot of functions that are typically product, over to engineering.
That doesn’t mean that myself and my co-founder who’re essentially the product people in the company, don’t give input. It’s just the way we give input, how we give input, and when we give input is very different then most companies.
…
…it isn’t about hiring engineers and turning them into product people. It’s about giving engineers so much power to create the right solution and so much information to help them do that and then giving them an ability to prove that they did that or not.
The way we do that is, we basically just do a founder review. And that’s the final shot before it gets shipped to customers. Which means, myself and my co-founder, Marie, are looking at the thing deeply like [in a] feature flag state in our account. We can also understand the implications of whatever the engineer has built.
But their willingness to not let it go and iterate it until it’s right is really the thing. Because a lot of engineering teams throw stuff across the wall and then they don’t expect it back for months. We expect them to have it back in minutes. Maybe hours.
So that they get the feedback, so that we have the momentum to ship it fast.
…
Someone has to be responsible for ‘did it meet the customer need?’ And we don’t expect engineers to be responsible for ‘did it meet the customer need?.’ I know that sounds weird. Because I just said that they own the solution.
Absolutely.
But is it their job to determine whether it passes to the customer or not? No, that’s someone else’s job. Because that’s the person’s job, people’s job who understand the problem deeply. That’s how we think about it.
People who understand the problem aren’t the ones building the solution, but when the solution comes to them, they’re the ones determining whether it moves on to the customer or not.
…
If anything’s wrong or anything’s off, they (engineering) are told and they fix it. For example
It’s not like I need to give you all the customer interviews or anything like that. I just need to show you what the problem is that the customer has, you folks decide how you want to solve it.
We don’t dictate how they solve it. We just tell them in as nuanced an approach as we can, that this is the problem. Then they come back with…sometimes they’ll make a requirements doc or something like that and say, ‘does it hit the mark?’
Or they come back and say, here’s the copy doc for all the copy that we need to add because of this feature, can you just look at it and give us feedback on the copy? They’re owning all of that. We’re not owning it on the problem side. They own it.
That creates a different culture in engineering too. That’s really the aim.
…
When you have critical processes that are different at your company, every company has these that are different. If you find the thing that’s most important for the environment you’ve created for that team and pull that out into the interviews, those are the most effective interviews to assess.
…
When you think of it that way, we actually pulled out our planning process and that’s part of our interviews for engineers. We’ve had engineers come back to me with, ‘even though you didn’t accept me, I learned something during your recruiting process, you didn’t give me this coding challenges crap.’
…
Instead what we do is we make you plan either a link shortner or a to-do list app and we give you a document with even things like, ‘there’s two holidays during the time when you’re going to be working on this’ and things like that. And they have to come back with a plan.
Then, someone on our engineering team hops on a call with them. They’ve already scored their plan before they hop on a call. It’s a pretty long call. Like a 90-minute call. And we’re giving them feedback the way we would if they worked here.
Then we’re rescoring their plan based on what they say, and only then, if they meet a certain criteria on the score, do they move forward to the culture interviews and other folks on the team.
Because we want to make sure someone’s going to be potentially successful in the environment that we’ve created before we even care if they can be successful from a culture standpoint…Obviously the culture is important. If they don’t pass that, they still don’t come on.
But. We really care about assessing their ability to operate in the environment. That also makes a big difference. Because, again, they own the planning. They own the delivery date….
And we have this thing where we ask them, ‘are you 90% confident in this plan?’ If they’re not 90% confident in the plan, they need to go back to the drawing board and work on the plan.
I hate not shipping on time but at the same time we stopped having any dates, because we’re just super fast on this stuff and don’t care any more about when something ships, we only care that we’re working on the right things. And that the engineering side is owning the solution.
This prevents almost a 100% of the problems I’ve seen over the last 20 years in software development. That’s why we do it like this.
Related Relay reading:
Tara AI’s co-founder, Iba Masood, on weaving product growth goals into their weekly dev sprint (“…we’ve had pods with 3-5 engineers structurally mapped to build around activation, retention, and some of the other parts of the growth funnel. We don’t just target an ‘upgrade to Node 16,’ we say, ‘upgrade to Node 16, so we can iterate faster and ship weekly.’)
🤝 Founder social:
Thanks for reading! 🌻
Team Relay (Chargebee for Startups)