SaaS Founders at Work '22 Edition: 42 Inspiring Heuristics and Hunches from 194 Years of Building

Relay · January 18, 2023, 4:30pm

Lately, there’s been a reasonable, industry-wide tendency to wind back the clock to previous downturns, in hopes of mining parallel lessons for today’s challenges.

And while one has to make their way through the clamour of ill-fated prophecies (’08: “SaaS market will ‘collapse’ in two years”), there’s still merit in heeding the quieter truths of perennial fundamentals (’16: “Operating a startup…[now] requires a financial and operating discipline that we haven’t seen in startupland for quite a while”).

Whereas what we found as we gathered all that SaaS founders shared on Relay across 2022, was neither stark nor subtle. We found lived decisions, not pronouncements. We found difficult, enabling realizations. “Capital, I’d tell my past self, is just another tool”

Tales of targeting won-and-done software categories. Of deleting a 1/3rd of one’s product to make it 10x better. Of hiring for hard-to-define roles, “burnt pizza,” and “no sacred cows.” Of what rose up when the standard, even fabled frameworks fell short.

In our (unabashedly biased) opinion, the following 42 open, diverse, day-to-day accounts of what shaping SaaS startups really entailed last year, can surface more relatable and thoughtful companions for what lies ahead than any reasoned dive into the past. :))

INDEX:

Founder's-Self-Relay-SaaS-

(Founder’s self: Notes on managing one’s psyche, making sense of the inevitable startup overwhelm, and finding meaning as a founder.)

Facing the ‘great resignation’ and learning a whole new discipline

Lately’s Kate Bradley Chernis on “a great reckoning.”

God is good. Shit happens for a reason. We’ve had an unlimited number of things happen to us that were definitely out of our control. And some that were. All at once. And I’m grateful for every single bit of it.

One thing out of our control was the great resignation, that happened just as we were beginning to think through the self-serve transition. We lost some salespeople, which turned out to be a gift. I was going to have to let them go anyways, now that the self-service product would be taking over their jobs.

This then made it easy to flip resources from sales to engineering. (Our engineering team is made up of my two co-founders, a VP, and our AI lead, and I haven’t been able to pay my co-founders for ages.)

Honestly, we’ve been eating glass as a group for a long, long time now. We are exceptionally good at it. But, it gets old.

The other thing that happened was that I lost a co-founder in the middle of this as well. While we weren’t really paying him that much, the mental investment that was going towards this person was debilitating for years. I didn’t want to see how bad it truly was because I was scared. I genuinely thought I couldn’t live without this person on my team. Turns out, not only could I, but we were incredibly better off for it.

Much of the work he was doing was around accounting, payroll – back office stuff. Fundamentals. So we worked with our advisors and educated ourselves. I’m so proud of my COO, Lauren. She stepped up to this very big, intimidating plate and knocked the living shit out of that ball. We’ve learned so much – it’s been beyond empowering.

Now, I can actually see — this sounds so obvious and it’s embarrassing to say it — but I’m not the only founder, by far, who suffers from this…. Now, I can see – to the dollar, to the dime – every fucking second, where we are, what we’re spending, how to predict and project. I am in control.

I now have the knowledge – where before I was relying upon someone else to have that knowledge. Granted, it’s knowledge that either keeps me up all night or lets me sleep. And I don’t have to ask anyone for it. I don’t have to wait for anyone to answer me. I can just know, instantly.

Talk about a bit of a reckoning…. A Great Reckoning.

“I think… [feeling strung out is] normal and healthy”

Bento’s Jesse Hanley on being aware of where burnout, for him, really stems from, and a work-life routine that helps.

I get overwhelmed, stressed, strung out all the time — I think that’s normal and healthy — but I find most of the issues stem from either me not having some key piece of knowledge (i.e how to scale a specific system) or not thinking about things from first principles (i.e the insight that our support could be done almost entirely on Discord vs. email and live chat was a huge one but felt VERY weird at the time).

Talking to friends, my wife, my dad or hiring help tends to be the unlock required to get out of whatever anxious loop I’m in.

As for routines most days are like this:

Wake up around 6-7am
Go to the gym (clean out Discord messages here)
Make breakfast
Work for 3-4 hours
Have a late lunch, go for a walk, do something fun whilst my food settles
Lock into an afternoon work session until dinner
Play video games whilst doing support until bed time

I’ll often also go exploring on my bike after lunch and find somewhere new to settle into. It’s nice to mix up my environment from time to time and I love finding a new cafe or book shop to work out of.

If I find myself really burned out I just wont work for a few days and forgive myself for it. I think this is the hardest part of being your own boss but I’m slowly getting better at it. After all, we all need rest.

Oh and a fun one I do often — some weeks, I divide a “40 hour work week” by 7 and just work a little every single day (inc. weekends). I find that’s super sustainable for me and slows things down a lot.

“The conflicting scale of advice is one of the most paralysing things a founder faces”

Tray’s Rich Waldron on making decisions when advice, as it so often does, points everywhere

The conflicting scale of advice is one of the most paralysing things a founder faces, handled well it’s a rich source of information, handled poorly it’s a major timesuck. I try to take everything as its own data point and ultimately process and come to a decision that is in the best interests of our overall vision, and the path to getting there.

An example I can think of (in early 2012) was the misrepresentation of the lean startup approach, as with anything it’s best consumed as a guide to support decision making but the emphasis at the time was essentially to create extremely lightweight prototypes of products.

This didn’t sit well with me at the time as I feel there is a balance between setting out your experiments correctly and having the conviction to commit to an idea that you believe it.

“I’ll never get 100% away from trying to be well-rounded”

Referral Rock’s Josh Ho on finding meaning in the constant struggle between a founders’ strengths and weaknesses.

I’d say I’ve gone through life trying to be well-rounded and not have flaws. Liked by all from a personal and product perspective. It’s the typical “trying to be something for everyone”. (UberNote was that).

It’s when I’ve leaned into strengths is when I’ve found the most success. I’ll never get 100% away from trying to be well-rounded as that is in my core being, it’s what makes me the founder I am today… but reminding myself to keep doubling down on strengths will get me further.

Seeing those strengths play out despite weaknesses has been the most rewarding. SEO, building systems (internal + in product). our product positioning, and our great service keeps paying dividends today.

“Honestly addressing: What am I still excited about?”

Chargebee’s Krish Subramanian on navigating the persistently gnawing pull of what’s broken.

There are always phases and days with exhilarating highs and “everything is falling apart” lows. I’ll attempt, here, to reflect upon how we’ve coped with some of those, especially in the first 5 years of our journey. I’m afraid of writing anything that might sound like “advice,” but I felt compelled to try and share my learnings.

Revenue not progressing at the pace you had wanted, a competitor raising a ton or releasing features you’ve been rigorously chalking out, core product updates getting stuck (frustratingly long) in the build phase, a newly surfaced security vulnerability, a fundraising push that sends upsetting signals of falling apart, a key team member quitting, a candidate you were counting on, not joining…The list of things that take a toll — one after the other, or sometimes, scarily at once — goes on.

A useful question I have learned to ask myself in such situations is: “what am I still excited about? what is working well?”

That jolts me out of a default mode of thinking we all engage in. Which is allocating mindshare solely to what’s broken even when there’s little we can act on, aside from dwelling on the equally unhelpful what-ifs and what-will-happens.

That doesn’t mean deflecting or avoiding a fuller analysis of whatever hurdle we’re up against. The opposite, instead. Knowing what’s going well gives me permission to objectively go super deep into what is not. And that, in turn, allows me to accept the obstacle for what it is and clarifies what I can really control, rather than going in circles around what it could/should have been.

Honestly addressing, ‘what am I still excited about?,’ leads me to answers that are often anchored around recent customer wins, the continuing significance of and an exciting obsession with the customer problems we’re solving, the very palpable impact people in our team are making every single day. It pulls me, in other words, into more sunnier, brighter directions.

As a founder, this has been among the hardest areas of personal growth for me — taking responsibility for my role in any situation and evaluating it thoughtfully, so that I can respond with exactly what it needs.

Product-Market-Fit-Relay-SaaS

(PMF: Notes on critiquing the binary of PMF, researching your way towards meaningful progress, and leveraging pricing as the penultimate filter.)

The PMF trifecta

Wethos’ Rachel Renock on questioning the assumed binary of product-market fit.

I believe that product-market fit isn’t a binary, black-and-white thing.

It’s a trifecta, instead.

Which gets completed only when you tie in and iterate as much on the third, equally decisive element — the business model. And the question a lot of people have on business models is: how are we going to make money?

But the question I have is: How are we going to provide value to our users and help them realize that value at the point of monetization?

To expand this line of inquiry:

Where and at what moment are we going to get somebody to an aha moment?
What is that aha moment actually worth to that person?
How does that tie into their overall ability to succeed on the platform?
And who are we actually going after, because that also has to map together, right? (folks you initially target as customers might be very different from those who can actually afford to pay)

“We’d rather make things we’re good at”

Eduflow’s David Kofoed Wind on why they pivoted despite having hit PMF that still results in consistent revenue.

A core philosophy of ours has been that we don’t want a large team. It springs from the fact that none of us likes managing a lot of people. We’d rather make things we’re good at.

This directly informs our product choices. We have a freemium product where users can play around, try out the first few things, and reach out to us only when they’re ready to buy. And we can help negotiate pricing terms and help set up more sophisticated configurations.

Whereas a more traditional product will require many customer touch points from onboarding to closing a deal, which wouldn’t be entirely feasible for our small team.

So, we do have a fairly long sales cycle, but we only participate towards the end of it. Otherwise we will exhaust ourselves dealing with enterprise bureaucracy.

This self-drawn constraint isn’t perfect. We do limit growth because we’re not actively going out and knocking as many doors as we can. But it makes us incredibly profitable in terms of clean margins; a small team that does fairly large deals.

This mindset also informed our pivot three years ago. Before Eduflow, we had built Peergrade, a peer-to-peer feedback product. With very promising PMF signals that last until today (I talk about this aspect below), we found ourselves in a category-creation scenario. Ours was the best product for sure, but we had to drum up demand from scratch.

Eduflow, on the other hand, is a corporate learning management system. Tons of (legacy and new) competitors. And we deliberately chose this space, because we’re a great product team, not a great sales/marketing team.

We aren’t the team that’ll create a new market, but one that can out-innovate alternatives in an existing market. Here, too, growth will take time. It’ll be frustrating. Almost every customer says they’re evaluating us among four other products. But we believe we’ll win in the end as we continue to compete on our strengths.

“…it really helped to position myself as an expert”

Thematic’s Alyona Medelyan on taking on the problem-solution paradox of AI-first products.

When developing an AI-powered solution, experts or enthusiasts of AI have a unique angle. They are seeking a problem, where AI can make a difference. And if they choose wisely, they can have a deep competitive advantage.

Meanwhile founders who “slap on” AI onto an existing solution, usually don’t succeed. Other priorities take over.

But… starting with AI also means starting with technology instead of starting with a problem.

This is, of course, problematic in startup land! First, you have to brainstorm possible problems, then validate them by speaking to potential customers. It can be a time sink. Especially if you get excited about something that isn’t worth solving.

When starting Thematic, it really helped me to position myself as an expert. Then, I didn’t need to seek and validate problems worth solving, they came to me! Here’s what I did:

During my PhD, I published my projects as open-source code and wrote about them.
I jumped on the Twitter wagon early and started using the #nlproc hashtag to tweet about Natural Language Processing (to separate this from those interested in Neuro Linguistic Programming). This hashtag is widely used on other social media as well.
I also started an AI meet-up in my city of 2 million people (Auckland, New Zealand) and offered my services as a contractor.
I created a website and made it easy for people to contact me.

Gradually I could then see a pattern emerge for a recurrent problem. People from three different companies came to me with the same problem: analyzing open-ended responses to Net Promoter Score surveys. This became the first use case for Thematic.

Researching for and selling to buyers who are “allergic to pitches”

Cord’s Nimrod Priell on how user research (and not pitching) helped hone Cord’s core proposition.

A common mistake I see early-stage founders make is that they’re not able to switch or even distinguish between the pitch mode and research mode in conversations with users.

They feel an urge to constantly pitch the solution, probably because that’s where much of the focus of hustle culture and how investments must be chased comes from.

Not realizing that once we start pitching people, 90% of them won’t engage us with honest feedback. We won’t get useful answers. Just versions of, “aha, I get it, that’s cool.”

They’re completely different conversations. On the other hand, even the best sales people focus on qualification, which is not the same as pitching the product but quite similar to user interviews.

Cord, for me, was the first role I had doing anything like sales or GTM. And I learned a tonne by applying what I knew about user interviews into sales.

Although, there are a couple of advantageous insights that I brought to this role, owing to my past experience. Both things that founders often lack. Things that they just don’t notice unless somebody points it out to them.

When I worked at Facebook, I was involved in a very, data-heavy team that helped PMs and PMMs with analytics on how people behaved while using their apps. And this team was married and intertwined with another team that did qualitative user research.

We followed this system that our VP at Facebook had come up with and something we went back to alot. Which was that, every decision had to be made on a 2/2. Where the 2/2 is qualitative and quantitative data, mapped with first party and then third party data.

First party and third party don’t matter much for the sake of what we’re talking about.

But the idea that you always had to have the quantitative and the qualitative data together in order to inform a big decision, led to having these teams work very, very closely together.

At Facebook, I was running this data team, and also acting as a PM for an app with a few million users. So we often used the services of these user researchers. Once I went all the way to India, to Mumbai, with my entire team to do user research there for a week.

Also to New York and to a couple of other places. I got to know how the best in the world, and this place was very particular about who they hired and so on, did user research.

Of course, I couldn’t afford doing everything they did, with the startup. Yet I had gathered the fundamentals of doing it right before approaching Cord’s hypotheses.

The second thing that helped immensely was that I wasn’t tainted by the experience of having done pitches.

I had not pitched to investors. Neither had I been in sales before. When you’re a founder who starts with pitching to anyone (investors or employees), it just shapes how you engage with these conversations even with potential users.

I notice this when I talk to founders who are trying to sell to us as a client on their new SaaS offerings. A bunch of them start with, “oh, this is a huge market opportunity.” They just pull out these lines that are steeped in pitching routines.

If I’m a client, I don’t care if your market opportunity is big. You should ask me about my problems. Best sales pitches that I’ve ever done or I’ve ever been on, are the ones where the seller speaks 10% of the time.

And what they do is just ask: “So, what do you, the client, think we, at startup X, can do for you? What are your problems? What do you need?”

I later read up on this.

Again, this isn’t something I came up with. It’s consultative selling. The best kind.

Especially with our buyers. They’re not used to being sold to. They hate being sold to. We sell to PMs, engineers, and designers to some extent. They’re all allergic to pitches.

How Butter’s best segment wasn’t

Butter’s Jakob Knutzen on deploying pricing as an instant, penultimate PMF validator.

We wanted to price rather early.

But we observed that in the video conferencing space, there’s a reasonably high product hygiene threshold that we needed to hit in order to compete with the entrenched players. So we didn’t introduce Butter’s pricing until a little over a year after we launched.

We launched in June/July 2020 and the pricing came out in late October 2021. A major goal behind the pricing push was to learn which market had core users who were willing to pay for Butter. And this goal stemmed from a (soon to be validated) suspicion we had.

In that first year, we had seen big growth and adoption spikes from the education segment, in countries such as Taiwan and Brazil.

These were power users who were extremely vocal about how much they loved Butter. I should note here that we hadn’t built Butter for academic use cases. This was an emergent segment, with perfect PMF scores to boast, not to mention the excellent product engagement metrics.

Still, our doubts were twofold: 1) whether they’d be able to pay for the product, and 2) will they continue to use Butter post COVID (once lockdowns in their respective countries were over and they had to resume classroom sessions)?

As soon as we introduced pricing, the answers to the above concerns became very clear. Most of these users weren’t willing to pay for a premium product and were planning on moving to classrooms once the COVID restrictions were lifted (and they indeed stopped using Butter).

We would have been in for an unexpected shock if it wasn’t for introducing pricing. I truly believe that any PMF validation exercise is incomplete without the pricing test.

Reexamining the revered Superhuman (concierge) onboarding

Sunsama’s Ashutosh Priyadarshy with a reminder that no matter how beneficial 1-1 customer conversations are, “you do want software to be scalable.”

There were a couple of factors that sort of coalesced that moved us from concierge to self-service onboarding. Initially, it was just my co founder, Travis, and I, who were doing all the onboarding. A two-person team.

And very quickly, within a few weeks that is, we got to a point where our calendars had literally nothing else but onboarding calls, perhaps 12 a day, each.

We were learning a lot. Sure.

But in order to build what customers were asking for, we had to start paring these down urgently from at least Travis’ schedule.

Then we decided to hire someone who would do nothing but customer onboarding. Soon enough, even this person had their calendar booked wall-to-wall.

Thus the question was, ‘okay, if we want to keep growing this way, we’ll need to:’

hire another customer onboarding person,
train them,
make them an expert in the product,
and continue this process over and over.

Going through the training routines, a part of us felt that we were almost building this meta product which was our customer onboarding.

And that made us ask: Did we really want to go down this path where we’re going to need to hire a small army of people to onboard customers? Wouldn’t it be better if we were pouring our efforts into making our product more intuitive for the end user, instead?

Once you start thinking about the unit economics of this method, it’s hard to say that this will ever make sense. Unlike Superhuman, we weren’t rolling in 10s or hundreds of millions of dollars in venture capital. We had raised a fairly modest, $2.4m round, after YC.

We wanted to be a lot more careful about how we were spending our money and we felt that it would be better spent on product development.

Plus, you really do want software to be scalable.

What we did to transition was to take all the things that we were aiming to teach customers in the onboarding process and productize them. Chiefly, what that ended up looking like was a daily planning ritual that guides you step-by-step through the process of planning your day.

Learning deliberately even when everyone is beating down the door!

Teemyco’s Charlotte Ekelund on staying focused amidst the noise of sudden, alluring demand.

Little did we know that just three weeks in, we would be interrupted by a global pandemic.

Some people joke and say, ‘oh, you got lucky because of the sudden need for something you had already been building.’ To be clear, it has been amazing. But of course for us it would have been even more amazing if the product had been more market-ready sooner.

On the other hand, this unexpected demand also risked distorting our product-market fit trials. As all of a sudden, the entire world became our target audience. I know it’s a luxurious problem to have. But it was really easy for us to get derailed from our focus on the audience we had validated our hypothesis with.

We were receiving requests from everywhere. Some people with no experience of beta programmes, those unfamiliar with the inherent work-in-progress nature of MVPs, and overall, very different expectations than we had witnessed during our research.

And we kept a cool head and kept revisiting our initial hypothesis and also the people who had found it most resonant for their challenges.

So we had to cluster different segments and work through the requests, a step at a time, no matter how horizontal the product’s appeal might have been.

And then analyze, week by week — who was sticking around, who was churning, how differently were the offices designed, org structures, behaviors, and personality types — and feed all that data into our understanding of product-market fit.

To sum everything up, our initial audience was a good pick. But we have also found secondary audiences which we’re still simultaneously researching and learning from.

I interview users every single week and I’ve spoken to at least 400 people since we began. I think this is one of my core responsibilities as a CEO, aside from building a strong team, and of course, talking to investors.

People-Relay-SaaS

(People: Notes on not hiring for vague impulses, finding “high-slope” people, and the pitfalls of over-indexing on experience.)

Recognizing (real) hiring pains

Eduflow’s David Kofoed Wind on the “classic misunderstandings” of early-stage hiring

Hiring pains (and their subsequent learning curves) can surface quite early.

Assume that you’re a business person, and you need to build a software startup. If you can’t write code, it’s a pain to not be able to develop the product you want to build, right? So if you cannot start out without a great technical base, you should probably hire somebody.

What I really want to advocate to people, though, is to not hire somebody just because you think you should have a person doing X and not necessarily a real need.

Let’s take marketing. Or even sales for that matter. Many hiring mistakes originate within those two functions. Founders might think: ‘oh, we should have someone run our Facebook ads because that’s what everyone else is doing.’

Then they try to hire someone with that vague impulse. But they don’t themselves yet understand what performance marketing means for their business, as they don’t have any direct experience doing it.

Or perhaps the founders are simply afraid. Not ready to sell, for instance. Afraid of the rejections inherent in sales conversations. So they’d say, ‘well, we should bring in a salesperson or onboard resellers who’d sell on our behalf.’

But it’s really important to market/sell on your own as long as you possibly can. And only when you’re overburdened with work, that’s real hiring pain worth attending to.

We learned this the hardest way possible. Bringing in and having to let go multiple salespeople. Because we didn’t realize that you hire for sales when you want to scale, not to get started with the function.

And this realization has since become a sort of hiring principle at Eduflow. If we wish to do something new, it is difficult to fill that position. But when we know what we’re doing, we know what works, but just don’t have enough time for it, that makes hiring much simpler. Because we know exactly who to look for in a candidate.

And, more importantly, it makes things simpler for them. A lot of founders think that it’ll be great for a new hire to come in and define their job on their own. That’s a classic misunderstanding.

I get that people value flexibility and freedom, but they also want (and deserve) absolute clarity on what they’re hired for. Founders overestimate the value of a blank slate.

The three, broad people traits to hire for

Pulley’s Yin Wu on learning to hire “high-slope” people.

Here are the three broad traits I look for:

Are they passionate about something? Usually if there’s something that they’re really obsessed about, that’s a positive sign. Because it might imply that they can really sink their teeth into a problem.

The second thing is identifying if they can keep answering a series of whys. Give them an open ended question. Ex: How would you launch a particular product internationally? “Okay cool, I would do the following first.” “Why would you do that? Keep going.”

You want to know if they have several layers of critical thought and whether they have a growth mindset. You don’t want someone to stop after the first few enthusiastic takes. Because with a startup you’re always chasing after forever-unfolding problems.

The third bit, something I had noted before, is that they should have the “default possible” mindset. Finding a way should be second nature to them.

The more “junior” folks have a huge advantage here. As they don’t know how things are supposed to work, they’re willing to approach everything from first principles. Bet on that.

Why sales hiring driven by similarities (deal sizes/categories) doesn’t yield much

Airplane’s Ravi Parikh on how people tend to overrate “relevant” experience (faster ramp times offer scant basis for overall success).

I believe people overrate relevant experience in the same field. It’s really tempting to be like, ‘oh, we’re Heap, we should hire reps from Mixpanel or Amplitude or something like that.’

That’s great. They’ll perhaps ramp a little bit faster.

But the right reps honestly can learn most products pretty quickly.

If you hire, let’s suppose, I’m making things up here a little bit, but let’s say you hire someone from a direct competitor, who’s in the same space as you.

They’ll probably do a great job in your interview process, especially if it’s sort of product centric, but you don’t actually know their ability to ramp on your product. You only know their ability to have existing current knowledge of the space.

Your product is inevitably going to be somewhat different from the product they’re coming from. So I don’t want to give too much detail because I don’t want to name specific people, but we have hired people who had a lot of ‘relevant’ experience.

And then their ability to just get that 20% more to learn Heap, specifically, was actually a lot more difficult than I thought it would be.

I don’t know if it took them two years to learn all that stuff. Whereas there’s other people that may have come totally out of the industry. Todd, our first sales rep came from Square. Square and Heap have no relationship with each other. Different deal sizes. Different products.

Yet he figured Heap out within a couple of weeks.

And to me, it’s that slope, that rate of learning that matters a lot more than the knowledge that they come in with today. Especially for your early sales reps, who don’t have all that scaffolding and support.

If you hire from the same industry, you’ve actually diminished your own ability to discover their rate of learning, in some sense. Because they will come in and feel very knowledgeable compared to the average person you’re interviewing.

Why Outfunnel needed a full-stack marketer and you probably won’t

Outfunnel’s Andrus Purde on how they could afford to pivot with the right marketing hire.

If you have a good full stack marketer, you can afford to pivot.

Had we hired a great demand-harvesting marketer, someone who could only scale SEO or performance marketing, we would have been stuck.

Some early-stage startups need to be ready to pivot, to be able to easily (I mean, not easily, nothing about pivoting is easy) change the core of a company.

With full-stack skills, you can at least have a shot at switching up your core channels, redoing the messaging, and if needed, fundamentally overhauling your marketing.

We did that.

We’re still in the process of revisiting our marketing mix. Still leaning heavily towards high category awareness efforts.

In addition, we’ve kicked off cold outreach for users of certain tools. Plus we’re now doing more targeted banner ads for people who, based on signals their websites send about their software tools, use some popular apps together, such as Calendly and Pipedrive.

All in all, we’re doing more interruptions to spark demand than we did in the past. And looking to build and flex this muscle further in the future.

All that said, it’s still worth assessing whether a full-stack marketer is indeed a fit for you.

We pivoted, but then we were always in a category of startups where we knew the problem we were solving, but weren’t certain of what the best actual solution would be.

There was always a big risk and a big opportunity for pivoting. We just wanted to chase the customers’ needs. Identify where we could offer the most value.

Other startups are different. Some start out in a brand new category, which in that particular shape and form, hadn’t existed before. A category that doesn’t immediately make sense to people.

If you’re maybe doing a web3 startup in the finance category, you probably won’t pivot to email marketing or a similar established category with high awareness.

Considering web3; it’s a bunch of early adopters who are present in certain communities, so you need great community-focussed skills, maybe even new media relations skills.

You’re not going to set up PPC ads, or even highly-targeted SEO as core channels. There’s no need to be ready to change your marketing mix completely.

You can just define a fitting role/profile and hire for that.

You don’t need a full-stack marketer.

And vice versa as well. A CRM company is unlikely to pivot to something which is completely new or wacky. But I do believe, there’s a certain type of company, like ours was, that’s quite likely to pivot

So step one is to establish the likely scenarios for the near future and then that gives you an idea of who you want to look for.

Go-To-Market-Relay-SaaS

(GTM: Notes on a community-driven category creation playbook, making strategic media and content bets, and why SaaS ≠ subscriptions — at least not always.)

“We didn’t invent cap table management”

Pulley’s Yin Wu on why (and how) to build for a “non-obviously” large market.

Consider a market that seems huge. Let’s take Search. That’s as big as they get. Google is a trillion dollar plus company. How do you compete against such an all-encompassing incumbent?

Then there’s another kind of massive market. If you look at the CRM space, where Salesforce remains a clear leader, there are tons of other products. An ever-expanding long tail of niches. Which is great, but what’s your differentiation then and how much of the market can that really allow you to carve out?

The way I think startups win is by betting on and building for markets that seem small today but would be non-obviously large in the future. The bet being: Why do you feel this vision of the world will materialize? And can you ride the wave as it does?

Non-obviously large. That’s the key.

The obvious ones already have everyone going after them, especially behemoths with big resources. Thus it becomes really hard to find an edge.

Pre-Stripe, it wasn’t clear how big payment processing could be. The (assumed) ceiling, almost a decade ago, was the price tag of the Braintree acquisition. But Stripe proved that if you can build a 10x better product you can expand the size of a market.

With Pulley, for instance, we didn’t invent cap table management. That category has been around and we have a lot of respect for products in this space. But the thing that most people don’t realize is that this is going to be a much bigger category than it is today.

To begin with, we’ve been pursuing verticalized differentiation. We want to focus on early-stage founders. The GTM for Pulley has been concentrated primarily on serving early-stage founders and then growing with them as they grow.

Other tools in the market are focussed on late-stage companies and are very complicated to use. This isn’t a lot different from when Stripe first came out. They were essentially saying: “let’s focus on startups, a lot of these processors or large companies are not selling to developers and making it hard for them to integrate.”

So, instead of making a product that only cap table administrators/lawyers/paralegals can use, we’re selling directly to founders and making them understand how to manage equity well. Also weaving in the complexity over time, so that their future finance teams can have a robust tool.

What we’re also finding out is that across verticals, whether that’s healthcare or biotech, there are companies that you probably wouldn’t even think will need cap table management.

Large coffee producers that do profit sharing with their employees, for example. All of those are within the scope of Pulley. So although we’ve started with a targeted segment, we understand that we slowly need to build for the edge cases as well.

How do we prioritize building out the edge cases? We start by asking: What is the size of the market? What does the competitive landscape look like? And do we have a plan to win?

Then, most importantly, we drill deep into what our new users are saying.

Tackling category-creation customs, upside down

Pocus’ Alexa Grabell on upending the conventional category creation playbook.

Pocus is a Product-Led Sales platform that helps sales teams turn their existing users into high value customers. Pocus combines customer and product usage data into a single holistic view so that sales teams can prioritize the best opportunities and take the right action… all without engineering support.

For some background, in my former life, I was leading sales strategy and operations at a startup. When I was there, I recognized the inability for sales teams to access product-usage data, specifically data on how users were engaging with the product to inform their sales strategy. I ended up hacking together a bunch of things similar to what Pocus does today.

After leaving that startup, I went to Stanford for grad school where I met my co-founder. We spent three months going nauseatingly deep into this space. We talked to over 300 people in the sales teams at PLG companies.

And we realized this is something new. We’re not dealing with traditional top-down sales. This was a huge, hair-on-fire problem that I was meant to solve. But I couldn’t have just fit it into another category, because that category didn’t exist.

So when I say Product-Led Sales, I’m talking about a new term that we just started using.

When starting Pocus in early 2021, one of my goals was: “We’re not going to just create a product. We’re going to also create a category. We cannot create a Product-Led Sales platform without also defining the category of what Product-Led Sales is.”’

Product-Led Sales is a new way of doing things. It’s a new sales motion, which requires new types of roles/responsibilities, new go-to-market motions, new workflows, new incentive structures. Everything.

When building the category of Product-Led Sales, we did something non-intuitive: we did not start with defining the category. In fact, the first step is not writing down a playbook.

We reverse-engineered everything.

Why founders — undeniably — overcomplicate early-stage sales processes

Airplane’s Ravi Parikh on not juggling sales specializations just because you’ve been told so

I would not overcomplicate your sales process early.

In 2013, when we were starting Heap, SaaS was a lot less mature. In some sense, we didn’t have the luxury of even knowing that we could overcomplicate things, we just said, ‘hey, we need sales.’ So we hired a sales rep. And I feel that was the right thing to do.

These days, you might have had a lot more exposure to the SaaS business model. And you just might know a lot more. You’ve read more SaaStr.com or whatever. And you just might learn that you can have a BDR and an AE and a sales engineer, and this and that, and an account manager and a customer success person.’

And at scale, you’ll have all those things. You’ll have a process where customers are touching like 18 different roles over the course of their journey.

Don’t do that early.

I’ve seen a lot of founders overcomplicate things and say create a wreck with a BDR and an AE and a sales engineer and like another thing. Just hire one role at a time.

Hire your first AE and make them do all the roles you can specialize in later. Hire generalists who don’t need to be pigeonholed in a very small box. Until you get that one thing right and then specialize the thing when you need to. The point of specializations is to get more efficiency out of a given role.

But the cost of specialization is that it’s a management overhead for you. And it’s also like communication overhead internally. You don’t want to pay those overhead costs until you absolutely have to.

Keep the specialization as low as possible for as long as possible. Or like until you’ve hired a VP of Sales who can manage the specializations. They’ve done it five times before. They can.

If you’ve never managed that specialization yourself, you’re probably going to mess things up. You’re probably going to get the boundaries wrong. And you’re going to be spending your time fighting fires internally instead of improving the customer experience.

Subscriptions vs. transaction-based pricing, Shopify’s lessons, and what the future holds

Wethos’ Rachel Renock on why SaaS ≠ subscriptions.

This is another thing I looked at Shopify for. And what’s interesting in looking at Shopify’s history is that Shopify started the opposite way that we did.

They started with transaction-based fees.

Then they found out that the people who were really successful at running Shopify stores hated that. Because they were making a lot of money and didn’t want to trade off those fees.

The people who were not so good at it, although they were signing up a tonne, they were bringing too much of that classic SMB churn, so Shopify was not making money off those people.

Which is when they introduced a subscription model for the folks who were making more money on Shopify. The trade-off there amongst a lot of other features and what not from Shopify, was a lower payment processing fee.

For us, what we’re looking at now is trying to segment not based necessarily on a demographic, or psychographic, but more on just brackets of earnings.

And saying ‘okay, once you’ve hit this threshold of earning over 100k a year, even paying us 1% On that is kind of bullshit.’

If you’re paying us $1,000 a year for that, we could charge, whatever, 50 bucks a month, and you could be saving money by trading off and switching over to the subscription model.

And I honestly think that the world is probably going to move in the direction of a lot of mixed models. We’ll have more features for a more premium tier. Plus there are other things that we can do in a more traditional sense.

In terms of what we’ve heard from the users and how they interact with the platform, the biggest trade-off is saving money on payment fees, because, again, the other thing is volatility and your income.

If you’re earning over 100k a year, you get a pretty steady predictable income month over month. And so it’s easier to add a fixed cost like 100 bucks a month to that.

If you’re still just getting started or things are volatile or unpredictable, then having that subscription to your on your card is like death.

You’re nervous you won’t be able to pay it. That’s kind of how we have been thinking about evolving the pricing structures for different segments going forward.

“It’s never about whether the pricing is right or wrong”

Tability’s Sten Pittet on having a system to make sense of pricing decisions.

I think, “charge more,” is good advice. Most founders should start with that. But then you should learn about other levers from the market, observe your customers, and know that you’d have to come up with multiple iterations.

Still, it’s never about whether the pricing is right or wrong, but about whether we have a system in place that helps us understand the impact of our pricing decisions.

From what I’ve gathered, the following three criteria matter most:

Is the model enabling customer behavior that’ll make them successful?
Does it fit a sales motion that fits your company’s narrative?
Will it financially work for us? Will it be sustainable?

So your pricing should mirror the sales process you can afford. If you’re going to charge a lot, be prepared for longer sales cycles, procurement processes, compliance forms, and tedious spreadsheets with a bunch of questions.

Because that’s going to be your life.

Likewise, if you charge less, you have to know whether there are enough people in the market who’d make up the volume necessary for a low-ticket-price product.

Or maybe you sit in the middle.

We subscribe to the self-serve school at Tability. People find the product themselves. They can onboard themselves. They can put their credit card on their own and then run with it.

When we’re thinking about who we talk to, what language we want to use, all of that goes together with this choice. Because you have to create an identity that fits both the experience and the price that you want.

Understanding high vs low category awareness

Outfunnel’s Andrus Purde on a framework for finding the right channels, messaging that sticks, and hiring first marketers; or “a map to an unfamiliar city.”

For all the marketing choices you have to make, you need some shortcuts. You need something to hold on to, in order to make your first, broad decisions.

And category awareness and category urgency are your best kind of shortcuts. If you operate in the CRM or the email marketing space, there’s pretty high awareness. People are looking for such tools on a daily, weekly, or monthly basis. Your job, then, is to be findable.

On the other hand if you’re creating something which people haven’t used/heard of before, say, a decentralized decision-making platform, then your category awareness is likely very low. Being “findable” doesn’t help here as nobody is searching for what you’re building.

Then there’s also category urgency. We know what a gym is all year but most of us flock to gyms during the first two weeks of January. If people are aware of your product category but not searching, that’s very similar to low category urgency from a marketer’s perspective.

These are the two main marketing models.

I thought these were just a way to shortcut which marketing channels to run with, but I’ve realized (after reading Dave Kellogg’s blog quite a bit) how they’re also a shortcut for arriving at messaging that resonates with users.

If you are in a high category awareness situation, then your messaging is about how you are different, how you are better, and so forth. Addressing these specific hows is what matters.

In a low category awareness business, you have to get people to understand new concepts, and sometimes, to nudge them to adopt new behaviors. Then it doesn’t make sense to talk about how you’re different from others, you have to make a case for why your thing exists in the first place.

Acknowledging this distinction means that your marketing is almost served to you on a plate. You know which channels to use. You know what kind of messaging to experiment with.

Interestingly, most companies and products are not one or the other. They are hybrids. Somewhere on a spectrum between high and low category awareness.

Hipchat/Slack make for great examples of hybrids. As messaging has been around since the mid 90s, it was just messaging for enterprise that was novel. People understood the former, the latter, the enterprise part, had a bit of a learning curve. Thus a need for messaging that communicates the how and the why.

Similarly Outfunnel is tricky because we changed what we do, quite comprehensively, at least once in our history. I would even dare to use the P word.

We pivoted.

Minimum viable funnels

Sendspark’s Bethany Stachenfeld on treating the customer funnel like a product and not just optimizing what’s already working.

My background is in marketing.

Before starting Sendspark, I was doing B2B marketing for other startups.

And, I feel, what founders need to know is that it’s very different to be running and marketing for an established funnel vs creating a whole new one.

Because the customer funnel is like a product. You cannot optimize it if you haven’t built it. The key idea to ponder as you’re starting out is: what’s the MVP for your funnel? And where do you want it to be in the long run?

Because maybe we know that we should have all these free tools and amazing, free-to-paid programs and offer all these incentives. And perhaps give away a lot.

But we can’t just build everything at once. We have to shape these incentives and the funnels they reside in, like products. Piece by piece. In a way that’s continuously adding value.

What I would recommend is to, first:

Identify your ideal funnel. One that you think will make sense for your business, when your product is fully built, and you have customers, and all’s going well. Figure out what that looks like. So that you can track all the key things you are going to need to get there.

Then distill this ideal funnel and sketch out what is the MVP version for where you’re at right now. And that should be based on features you currently have and shouldn’t require development other than tracking a few key events.

It’s to optimize this MVP that you want to run growth experiments. Starting with the simplest tweaks you can make. Revisiting email automation sequences. Showing retargeted ads based on pages people have visited. And others.

There’s a mistake I’ve seen a lot of companies make. Which is, instead of mapping out the ideal funnel and then the MVP funnel, they just look at what’s already working and optimize for that.

I’ve heard a lot of people give that advice, too.

I think that’s bad advice.

Because if you keep optimizing what’s working, but you haven’t actually thought about all the broader, moving parts of a funnel, you are never going to do this right.

You’ll just say, “oh, I’ve been talking to people and I guess at our stage we need to add more sales folks.” And you invest in human resources and start hiring people to fill in holes. But really, you just need to actually build out your funnel and optimize that from first principles.

For example, our ideal funnel looks something like:

→ Visits website
→ Creates free account
→ Records and Shares a video
→ Gets a win from their video (likely a meeting scheduled)
→ Records more videos
→ Hits a free limit (maybe records 30 videos or wants to use a premium feature)
→ Upgrades to Pro ($15 / user / mo)
→ Wants to collaborate with team members
→ Expands account

However, early on we didn’t have many Pro features or team collaboration features that customers would want to upgrade to use. We just didn’t have time to build them yet!

But still, we started tracking our ideal funnel, knowing that conversion rates would be low. And then we built the features to improve them over time. This way, we were always measuring what really mattered, and improving in the right areas.

Running ads to acquire a newsletter, not users

Loops’ Chris Frantz on how they made an unusually early media acquisition.

The only form of paid advertising we’ve done is with newsletter ads. And that too wasn’t really about acquiring new users but for sussing out a potential acquisition instead.

Yes. A media entity.

You’ve probably seen the trend. HubSpot purchased The Hustle. Spotify brought in Joe Rogan. There are lots of these deals taking place and they make a ton of sense. But most companies are making these media investments at the top of the cycle.

We wanted to flip that by making an early bet, at a rate that we could afford, and really grow it along with the person running it.

How did we find our opportunity?

We purchased sponsored spots in 5 different newsletters over a period of a couple of weeks. We compared the results and found that Workspaces (a newsletter that curates and highlights creative workspaces each week) was right at the top.

I know it doesn’t seem like a match at first. But we discovered that a readers seeking inspiration for their home offices were also running/setting up early-stage businesses and that made them a perfect fit for Loops.

In fact, we broke even on our ad almost immediately.

Then the subscriber base also had an overlap with those who could potentially work with us in the future given our async-first ethos so it ended up being a great recruitment engine for talented engineers. We’ve had a number of engineers apply directly to Loops and cite reading the newsletter as how they found us.

Most importantly, this was an awesome acqui-hire for us. We brought on Ryan (who started and grew the newsletter) full-time, as our Head of Content.

Since we’ve made this purchase, the newsletter count has doubled. So the implicit, inherent value of the business is already 2x of what it was at the moment of the sale.

We generate new customers every single week because of this acquisition.

It’s been fantastic.

Everyone told us not to do it.

Lol, that’s why we knew we had to do it. We closed the deal within a week and a half.

I must say though that it worked out great because the audience was a great fit for us, Ryan was an exceptional hire to make, and we realized the value pretty quickly. It’s hard to replicate.

Product-SaaS-Relay

(Product: Notes on why MVPs aren’t enough, setting up engineering for growth, and the rigour of continuously discovering high-impact things to build.)

Burnt pizza and why Instagram never rose out of Facebook

Cord’s Nimrod Priell on why MVPs worked in a different era and what’s demanded from products now

The notion that a minimum viable product doesn’t cut it, in a lot of instances, is fundamental to how people need to think about their startup journey.

Because the Lean Startup was written at a point in time where mobile was just starting up as a platform. And you could get away with things. Really. The first apps on mobile were exceptionally basic and still got propelled into huge success.

On the B2B side, a lot of givens we take for granted today just didn’t exist back then. A self-serve kind of SaaS model for example. Everything was over a long sales cycle. SMBs were completely underserved. There were barely any sophisticated tools.

You could build a basic thing like Shopify (when it started) and score massive success. The need to grab a space first mattered a lot and people’s expectations were low.

Today, there’s a focus on other elements. And we cannot get those right if we serve burnt pizza. People wouldn’t comment and tell us anything if they’re dealing with a poorly executed product.

Essentially, if you measure yourself quantitatively, trying to get high retention for example, which is a good measure of PMF and getting to some scale, or getting a good CAC and better rates across different parts of the funnel, none of it will work if the whole product experience doesn’t shine.

What that means is that, as founders, we do have to put a lot more attention to quality and a lot less attention to metrics than most of the PMs who’re trained or who grew up in these post-PMF, large companies that are scaling or optimizing.

This has certainly been an unlearning for me. Or a relearning for the early days of my career. Because after 5.5 years at Facebook as a PM and as a data team leader, everything that was hammered into me was around how analytics and experimentation give you the right path forward.

And that’s just not the case.

It’s true for incremental growth. It’s not true for new experiments, ideas, and products. That’s actually something that Facebook got wrong.

Facebook had a period where it was investing in this initiative called Facebook Creative Labs, with which they aimed at expanding the core Facebook apps like messenger and building novel experiences that people might want. Essentially, to build the next Instagram in-house, instead of spending billions on acquisitions.

That failed miserably.

Internally, some leaders noted that one of the reasons why Facebook Creative Labs would never have come up with something like Instagram is that it just didn’t allocate enough time, enough patience for these experiments to come to fruition.

Instagram took 4 years to build up. Not to scale. To build up, to refine and hone the product until it was useful. Same with Figma (I know the stories as we share investors).
They took years to hit their stride. Notion, incredible story, again. 4+ years. Where they almost ran out of cash. And they didn’t really pivot much.

All of these companies seem like overnight successes.

They’re all overnight successes, yes, but years in the making.

What we built in the first half of the year was total crap.

Cord is now, 2 years in, with some of the best engineers one can hire in Europe, getting to the level of quality that people expect from the core loops in the product. I don’t think there are shortcuts here. This takes hard work and ardent attention to details.

Without reaching that level, users simply turn themselves off from even the most useful products. And it isn’t just bugs or bad design experience. Things that you can clock in metrics.

People can leave for the tiniest of things in the journey. An interface that’s slightly slower than they’d expected. A brand not quite resonating with them.

Getting all of that right just takes time.

“…we could be opinionated with certain workflows”

Slite’s Christophe Pasquier on figuring positioning (and product) and their intertwined ways

Just as Slack brought B2C UX conventions to how messaging was done in the enterprise world, we wanted to do the same with writing and import the experience of the best note-taking apps and merge those from the start with organizational features.

Which was a new category and thus we didn’t spend as much time on positioning.

Our earliest attempts at messaging were quite direct.

The first: ‘The note app for teams.’

Followed by: ‘Get your team to write things down.’

As we began onboarding more and more successful teams and started learning what set them apart, another realization dawned on us. Those teams already had a deep culture of asynchronous communication powered through writing. They had a remote way of operating that was far from mainstream at the time.

Our simple, early positioning (‘note app for teams’) clearly fell short.

Which lead us to the next, more ambitious direction: ‘Where teams share knowledge.’

Around the same time, products such as Notion and Coda were beginning to explode. That changed things. For the longest time, we had been passive on the differentiation front, because being the only product in the category, it was all being done for us.

Now, we had to proactively convey our particular stance.

Yet another direction (definitely one that was much closer to those exploding alternatives at first) emerged through that competitive push: ‘One combined workspace. All your team documentation.’

Followed by differentiated versions that focussed on our ideal customers.

‘The perfect communication tool for remote teams.’

‘The workspace for async teams.’

This was an exciting shift.

Because it suddenly widened the gap between what we were saying to the market and what we were building. And it forced us to identify Slite’s true uniqueness in the process.

The thing with Notion, Coda, and others is that they’re built (at least that’s how they’re positioned) for everyone. They have to shape the products in a way that works for a senior designer at a startup and someone who just wants to curate a recipe book.

That comes with obvious drawbacks.

We didn’t have those at Slite. We could be more focussed because we were only building for remote teams that had deep async habits. Teams that wanted to bring the whole richness of their work into one tool for the purpose of collaboration.

So we could be opinionated with certain workflows. For instance, if we know a lot of these teams use us for project prioritization and roadmapping, we can chase features that cover those processes end-to-end.

For these teams, a document needed to be a blank canvas, where they could sketch mock-ups, monitor weekly progress, and even record themselves.

All that progress inside the product came about because of articulating why we were really different.

And over the past year or so, the search for that differentiated depth in the product, has surfaced a new featureset. A way to better address: Who owns goals? Are they on track? What kind of decision-making needs to happen for a project to be successful?

That specific product direction has made its way back into our messaging.

Making us highlight the outcomes we enabled over simply stating what we did.

‘Where remote teams make decisions and share knowledge’

And, I know, given how intertwined messaging and product have always been throughout Slite’s existence, a new iteration is never too far.

Multi-stranded learning that never stops

folk’s Simo Lemhandez on discovering what to build with an intense research rhythm.

We are really serious about product discovery at folk.

And there are three key ways in which we pursue it:

First, analytically. Basically, tracking all major events in our product, and knowing what works, and what doesn’t work. This wouldn’t tell you what to build next. But having a sense of existing user behavior does inform the direction of new projects.

The second way we do discovery is through live sessions. We observe our users going through the product during onboarding. Documenting where they’re clicking, the product paths they’re following for particular jobs, and points where they get stuck.

These calls don’t just alert us about UX issues and opportunities, but also allow us to offer a one-to-one service where users can customize their own accounts. In addition to this, we also record all user sessions through Fullstory.

The third aspect of user research discovery is about really understanding the pains, the hard challenges in their own words. For this, we do true user research. Talking to current and past users about their use cases, gathering their thoughts on how well/badly we’re solving for that usage. This research fundamentally dictates what we build next.

And we measure the overall outcomes of these research insights through Superhuman’s product-market fit framework. We send out the PMF surveys — How disappointed would they be if they could no longer use folk? — exactly a month after we’ve onboarded a new user.

What matters to us is reaching product-market fit and more specifically targeting world class engagement (how many times the user uses the product in a month) and retention (how long do they use the product).

So, exactly like our cadence projects, user research never stops. Basically, every new user that’s coming into the product presents an opportunity for learning something about the problem. And we’ve automated everything.

As soon as they take a certain action, we send them an email, inviting them to either an onboarding session or a user research session. I conduct a few of these every week, and since starting folk, I must have spoken with around 500 users.

Based on this research we’re continually discovering the most impactful projects we could be working on. And we prioritize these projects based on a simple framework of balancing internal effort and potential impact on the user pains we’re trying to address.

That is how difficult a challenge is for the user or does a particular improvement make the product stickier and then how confident are we in tackling it? Are there things we need to deep dive on? Do we understand what specifically needs to be done?

For each project, we consolidate data from all the research we’ve done. Which is then turned into wireframes, prototypes, and early designs. To ensure we’re completely execution-ready and everything is clear before kicking off a new cadence. And the same set of learnings help us sequence our backlog.

A systematic, growth-focussed “why” behind every sprint

Tara AI’s Iba Masood on weaving tangible growth goals straight into weekly product sprints

We did our beta launch in April 2020.

And ever since then, as we took the first steps towards building out a team, we’ve been thinking about one specific thing: How do we set up a methodology where growth is ingrained in our culture?

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?

Which meant devising structures, processes, and workflows that a) empowered engineers to make their own decisions and b) had an integral level of routine built in.

Thus 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.”

Having a growth-focussed “why” behind improving tech debt doesn’t just help devs focus better but it also helps the wider team (marketing, sales, non-engineering) stay well-informed on the core product initiatives.

And on the routine piece, I believe we were able to mostly switch seamlessly to remote work because of practices we had already been experimenting with.

And an early process we debated quite a bit over was the ubiquitous yet often misunderstood, Sprint. Sprints, when done well, can be the lifeblood of startups. We also knew that we could only adopt sprints into our culture and into our product, if we could tie them to growth.

You hear a lot about OKRs these days. But the thing with OKRs is that it can be really difficult to tie them to the day-to-day work and to make teams care about them. Because, unlike sprints, OKRs are typically a bit too far removed and top-down.

So for early-stage teams in particular, and even for product teams at larger companies that need to accomplish a certain goal or to get to a certain version of the product, sprints can be the ultimate unit of productivity.

That is, the performance and effectiveness as realized in the weekly (yes) sprint is an excellent leading marker for monthly, quarterly, and annual success.

Here’s a sample weekly sprint goal: Release new user onboarding to reduce avg time to land in the product.

That sprint goal ties directly into the product funnel. And it can be shipped in a weekly/bi-weekly sprint. Of course, it might take some time to actually realize the outcome after a release, however, when engineers understand that outcome, they know exactly why a release matters.

To zoom out a little, this sprint goal stems from an OKR, which was to “improve funnel conversion by 56%,” that is drastically improve conversions from sign-up to activation to payment. A part of which was to better user onboarding.

In this particular case, we experienced a 7-fold reduction in friction for our users. Our prior product “land time” was 5 minutes and 32 seconds, and our new 6-week avg was 43 seconds. Which was huge.

From the work we’ve done researching and understanding agile (some of us have done it at large enterprises, some have done it at startups), we ended up with a version of agile that allowed both senior engineers and interns to quickly get into the flow of the process.

“In our perspective, numbers should follow rather than lead”

Scribe’s Jennifer Smith on the org-wide, user-obsessed mindset shift that the Kano model brought about.

At Scribe we use the Kano model to guide our product direction. Essentially, we ask ourselves “what would surprise and delight our customers the most?” It’s a balance between including the “must have” features necessary for functionality and identifying those delighters. We want our customers to be as excited about Scribe as we are.

We have to be very mindful and particular about the decisions we make, many of which are based on intuition as much as research. We call it “Building for User Love.”

We started getting a lot of feature requests. In some ways it was great — it showed our customers were invested — but it ventured beyond what we could feasibly build all at once. The team realized we needed a prioritization framework.

Before we settled on Kano, we actually tried a model called RICE (Reach, Impact, Confidence, Effort), which is much more quantitative. It’s an excellent framework, but wasn’t quite the fit for us.

We wanted something inspiring and generative so that we could continue delivering meaningful features to our users. In our research we saw that Kano has led product-led businesses to success before, and so we gave it a shot.

With RICE, product development became an estimation exercise that felt distant from the users. At Scribe, we’re much better versed to talk in terms of user stories.

In our perspective, numbers should follow rather than lead.

Unlike RICE, the Kano model has a fundamentally humanistic view. We shifted our mindset from “this is the number of people we can reach” to “What do we all share? What can this project be a part of?”

We had to reconcile that we were now looking at completely different metrics. RICE is formulaic. When you say “reach,” or demand, you’re thinking, how many people will I reach in this time frame.

With Kano, reach really mostly pertains to the “must have” and “little more, little better.” That reach is implied because you have a target audience in mind. With “surprise and delight,” you’re dealing with emotions, and for the most part, that’s universal.

Of course we have targets, of course we celebrate growth, but we are primarily focused on our ability to generate that thrilling experience for as many people as possible.

As far as “impact,” there was always room for that to be qualitative. It just depends on what you prioritize. ‘Am I monitoring conversions, or am I monitoring delight?’ We chose the latter, and while it can be tough to track in hard numbers, it’s often clear in how users respond to our teams or spread the word about what Scribe can do.

We always expected user feedback, but another real “win” for us was to hear teams across the company talking in terms of “surprise and delight.” We’ve seen the framework really resonate and enable us to have more productive conversations about what we’re going to build.

Deleting a 1/3rd of their product to make it 10x better

Arrows’ Daniel Zarick on why “nobody wants another inbox” and other lessons.

When going through this process, we had a few critical things on our mind:

1. “Red Herring” feature requests:

These are features that people ask for which, if you implemented them perfectly, wouldn’t actually make someone buy your product or use it with more frequency. They’re easy things to point out that are missing, but they aren’t core to their need. Be aware of building red herring features!

2. “Nobody wants another inbox”:

A prospect said this to us on a call and it stuck out like a sore thumb in our minds. Sometimes people talk about “software fatigue” and suggest that people have too many products and don’t want anymore.

We believe people actually desire more tooling, they just have “inbox fatigue” and don’t want more products that unnecessarily demand their attention in a new place.

Question if you can push your product’s functionality into a place where your ideal customer is already doing their job day-to-day.

3. Broad innovation vs. Narrow innovation:

Be honest with yourself and figure out if you need to build a broad innovation or a narrow innovation. A broad innovation is something like Figma or Linear, where customers have a high threshold of feature-completeness for any new product in that category.

You can win by adding all those features and making UX+design improvements to that platform, but you can’t have missing features. A narrow innovation is one where you need to do one thing superbly well, and actually having features beyond that one thing can add confusion to your product.

We initially thought Arrows was a broad innovation product, and now we realize it’s a narrow innovation.

4. “If you had to start over today, with everything you now know, what would you do?”:

We asked this question of ourselves and our team regularly. Once we realized we should make a change, we made sure that this was core to the conversation.

Just because we’d built or done something a certain way before… that didn’t matter anymore.

Our goal was to free ourselves from those constraints so we could find the best answer for the moment. Only then would we burden ourselves with figuring out a plan to actually get there. This framework was critical for helping keep us all in the right mindset.

Before assessing product readiness, define what “enterprise” means for you

Contenda’s Lilly Chen on how you can do without “enterprise-ready” bells and whistles.

Enterprise SaaS startups, quite often, start to consider the scaling challenge too soon. Truthfully, most business software does not need to worry about scale for a long time.

Let’s take Contenda’s example.

Currently, we only sell design partnerships. We don’t have general availability. There’s no public pricing page. Our design partnership recently has been going for $8k a month.

A design partnership gives customers early access to a solution for their biggest pain point, while also giving us a tighter feedback loop.

If you think about that price point for enterprise SaaS, $8K a month is just shy of a $100K ACV. That is a lot of money. So you only need 5-6 design partnerships, theoretically, to break even depending on your burn and where you’re located. Could be even smaller than that.

And you can support those handful of customers on entry-level infrastructure. You don’t need to get fancy at all.

We use the Serverless framework, which is just AWS Lambda functions, for our backend. It’s paid by invocation and by the length of time that the function runs. So if nobody is using it, it’s free. And if people start using it more, you pay more and scale it up.

But if you’re talking about 5 customers and their respective orgs, as far as approximate users are concerned you’re talking about maybe 500 or probably fewer. 500 active users isn’t a lot.

Plus, usually there is a ton of work that needs to go into selling and building enterprise software if you have to go through a standard procurement process.

‘Enterprise,’ technically, should mean extremely large companies such as Meta. But I feel that the phrase, ‘enterprise B2B software,’ has actually expanded to also include a lot of mid-market customers.

If you’re talking about selling to startups that are in that growth (series B/C) stage, you actually don’t have to go through elaborate procurement procedures.

Procurement process means that you have to go through a security review. You need to go through multiple layers of hierarchies within different (finance, legal, etc.) departments.

With a scale-up, mostly it’s just the buyer who needs to sign off on it. The buyer is typically a VP, a director, possibly C suite, depending on what you’re selling.

But that person can usually sign the thing and as long as their CEO doesn’t object, they’ll just pay the invoice and you’re fine. So unless your product legitimately only sells to the likes of Google, Facebook, and Apple, you probably don’t need to be “enterprise ready” and invest in developing bells and whistles such as single sign-on.

To add to that, it’s even okay if the platform doesn’t yet do all the things you’ve built in different places. It’s okay for some of it to be self-serve and for some of it to be manual.

You can actually get away with that as long as the value that you bring is unique enough to your customer. And if they value that promise more than how much they get annoyed with the limitations.

Arriving at an all-in-one roadmap for a specific group

Passionfroot’s Jennifer Phan on how they’re building a horizontal product with a vertical focus.

We’ve found that if we wish to truly improve their lives, we’ll have to build a very end-to-end, all-in-one sort of horizontal product like Notion/Shopify. Something that serves as a CRM and an invoicing tool. A single source of truth and a way to make money.

Quite broad, but still solving for one big use case: ‘As a creator, I’d like to make money with my digital products without having to juggle 20 different tools (it’s super annoying even if they’re no-code ones)’

And although the product is definitely pretty horizontal, to learn faster, we’re still niching down vertically by focusing on specific types of creators first.

Seeing people replace existing systems and habits with the product, plus funneling more and more transactions week on week through it, have been really strong signals. The next step is to introduce pricing and gauge PMF signals from that filter.

“It’s just a little bit harder for us because email is such a sticky habit”

Boomerang’s Aye Moah on transitioning from browser extensions to standalone products

And yes, that is definitely the typical approach as evidenced by Grammarly’s resounding success. And yes, we have considered and even started working on a standalone email client at some point in the company history.

It’s just a little bit harder for us because email is such a sticky habit. Part of the magic of Boomerang for Gmail and Outlook is the fact that you don’t have to change your ingrained daily workflow to take advantage of our features. Our users loved how well integrated the product experience is.

So the only alternative is for us to build an email client as good as Gmail or Outlook, competing with their decade of development and hundreds of engineers. What’s considered a table stake for an email client is such a higher bar compared to a service like Grammarly. Superhuman took about 3 years to build with several millions of funding as another benchmark to consider.

I think that’s where we are headed for the company’s future with our meeting scheduling. We are starting with the in-browser extension but ultimately what we are going to become is the platform for meeting scheduling that interoperates with every client and every calendar provider.

SaaS-Capital-Relay

(Capital: Notes on fundraising after 3 bootstrapped exits, how being self-funded afforded an intentional cadence for everything, and a founder’s decade-in-the-making realization that money is just a tool.)

“Capital, I’d tell my past self, is just another tool”

MagicBell’s Hana Mohan on objectively sizing up the possibilities and constraints of the two, seemingly ever-divisive capital choices and reflecting on what must ultimately matter to founders.

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.

“I don’t think Referral Rock would have made it as a VC backed business”

Referral Rock’s Josh Ho on how being self-funded made them more intentional.

Not sure if I’d say “do more” but maybe less waste and being more intentional.

With self-funding we didn’t have pressure to grow, the pressure was internal vs external. When we had the external (investor backed) pressure of demo days, needing to raise… it put us in a way to be in a mode of “trying all kinds of things” to see what works.

Which in itself is a great growth mentality, but too much pressure in that mode leads to desperation and waste. Maybe not enough patience to let an experiment run its course vs not thinking something is working then just moving on to the next.

Honestly, I don’t think Referral Rock would have made it as a VC backed business. A lot more was learned about our customers, market, and behaviors because of the slower pace we moved that had less pressure.

Fundraising after 3 bootstrapped exits

Podia’s Spencer Fry on taking the VC route after having bootstrapped across a decade and a half

We’ve been really fortunate that our main investors are not concerned with liquidity any time soon. They simply want to see us continue to grow and innovate, which completely align with how I want to build Podia.

Raising money versus bootstrapping has meant:

We can focus more on the long-term as we had money to get us through the early days. This is the key one.
We have a board who we meet with quarterly and provides me with helpful external feedback. It provides me an opportunity to sit back and reflect on the business.
It made it easier for us to hire new employees as they knew they were joining a “serious” business. Always found it tough hiring for my bootstrapped businesses until those became profitable.

Raising a major round in a difficult environment

Merge’s Shensi Ding on crafting a “high-quality business” especially when times are good

Why raise a round in the current environment?

Well, we didn’t know where the market was headed in the near future, we were doing really well as a business, and we had amazing investor interest. It was really a seize-the-moment situation.

We’re really happy that we did because now we can scale faster, build out more integrations, support more customers, and hire more post-sales team members.

We could make this fundraising decision primarily because of another one we had made long back. Hiring a Head of Finance and Ops very early in our journey is something we’ve been incredibly grateful for, especially since the market turned.

Thanks to that hiring decision, we have always been a very efficient business. We’ve been really careful about our spend, about how much money we were generating, and we’ve been really deliberate about ROI on every single hire.

Over the past few months, it’s been reaffirming to have been focusing on building a high-quality (and also high-growth) business.

The ethos of pushing and stretching as much as we can as a team has been a helpful, hard-won strength for Merge.

Having a great finance leader really changes the game for a company. It makes you more careful with experiments and more thoughtful when hiring.

It’s definitely a critical early hire in my book.

How to scale well with just a seed round

Thematic’s Alyona Medelyan on how they’ve remained remarkably capital efficient.

We have only raised $1.2M in seed funding. And when we did it, we were already doing $500K in ARR. We have not raised a round since.

There are a few things that we did that allowed us to scale with minimum funding:

Take advantage of government grants.
Be capital efficient before you prove product-market fit (which is more than just having a first paying customer!) The biggest expense comes from hiring too many people too soon. To keep the team lean, we use contractors and try to automate tasks where we can.
Get upfront payments and multi-year contracts whenever possible. For any contract that’s more than $10K, assume that it’s an upfront payment and state the discount provided (usually 20%).

Our AI approach doesn’t require manual training data in order to create custom models for each customer. So we did not need a lot of investment here either.

“…it’s their job to invest”

Momos’ Andrew Liu on how to (re)read the current state of the capital market

I always tell other companies at our stage that we’re all on a ten-year time horizon. What happens in the next 9-18 months over the course of this weird market movement, should not necessarily affect our long term outlook of the companies we’re building.

This correction was going to happen today or 4 years from now.

We’d much rather deal with it now than later.

Plus, it’s also worth remembering that institutional investors have raised record funds and it’s their job to invest. Funding might have slowed right now, but the fund sizes have not decreased. The numerator has decreased, not the denominator.

Eventually we’re going to arrive at a place where investors will start deploying capital in earnest, again. And without a doubt, the best companies will be able to figure out how to attract it.

To raise our seed, we had to pitch ourselves and the first pieces of a good idea. For us to raise a Series A, we’ll need to have the potential of becoming a sustainable business.

That’s the new bar. Something we’ve been building towards from the beginning.

Before it was okay to just grow. Now, you have to prove (through a lot of efficiency metrics) that you can build a sustainable operation with amazing retention and still grow at a good clip.

Growth is still exceptionally important. That’s not changing anywhere. But the notion of growing at all costs is certainly departing; I don’t think that ever worked. Startups need to demonstrate that growth, no matter how impressive it might be, doesn’t come at the expense of the business in the long run.

Companies have been afforded a great opportunity where we can look internally and shore up any weaknesses that we’ve had.

SaaS-Operating-Principles-Relay

(Operating principles: Notes on adding depth to your async and sync culture, adopting a no-silos operating system, and a business-driven engineering culture.)

“Getting everybody to row together is an untrained muscle”

Plum’s Caitlin MacGregor on adopting the Collaborative Operating System.

The way that Plum’s COS works is, each leader, independently, marks an org-wide, quarterly goal as green, yellow, red, or grey:

Red: We’re not going to accomplish this goal by the end of the quarter. So either we need to change the resource allocation or we need to maybe recognize that this is no longer a goal. Or we need to have a serious conversation about why something is red.
Yellow: It’s mostly on track and if we were to course correct, we can get it to a green by the end of the quarter.
Green: Which, of course, means we are perfectly on track.
Grey: Essentially a leader saying, “I have no idea where we are at with this goal, I’d like an update.”

These individual reviews are done async and in advance. So when we meet each month to conduct reviews, instead of running through passive updates on, “we’ve done what we said we’re going to do,” we’re actively discussing how we can act together to influence a goal’s trajectory.

…

Let’s say, three leaders said “green” but two people said “grey,” well, let’s give them an update. Then we’re going to the next one. Woah, one person says “green,” one person says “yellow,” one person says “red.” You know what that just signalled? We’re misaligned.

This exercise facilitates real strategic conversations every month.

The COS practice also raises the stakes of being explicit. You can’t just assume people get the goals. So a big part of the work is being explicit and making sure that leaders can cascade that clarity down to department goals and then into individual goals.

Developers should see how the work that they’re doing contributes towards unlocking revenue; towards ramping up those upsells; towards the pipeline.

At the end of the day why are people coding? Well, they’re coding to accomplish a bigger business strategy, that strategy needs to be clear and explicit.

A related endeavor that has helped is establishing a cadence of cross-departmental meetings. Constant touch points, every other week. Product and customer success meet. Product and sales meet. Product and engineering meet.

It filled up people’s calendars. And at first these meetings were almost universally resisted. But then people found out that we are saving so much time by getting aligned upfront. We’re steering clear of many, potentially time-intensive problems way in advance.

It was a real change to develop the right cadence and we constantly have to reevaluate it as we get new leaders in, and as we set new priorities

Are we meeting too often? Are we meeting too infrequently? Who’s setting the agenda? What’s the type of agenda? Are these meetings that need advance prepping or are we carving out time to sketch the solutions/challenges together?

I think the biggest thing is understanding how to align an entire team around just a few key goals and getting everybody to row in the same direction, is, for most companies, an untrained muscle.

That’s why COS is the operating system we run on as a team, a vehicle for bringing collaborative thinking to every single decision we make.

Making public decisions a norm

Panther’s Matt Redler on principles that inform and drive better, more thoughtful asynchronous decision-making

Okay, so how do we think about decisions in an asynchronous workplace?

The first thing I’d highlight is committing to a lot of public communication. What we attempt (and we’re not perfect at this) to do is that we avoid making decisions in private, direct messages.

Why?

Because that takes away potential know-how on what went into a given decision; why did it happen the way it did, and how could we have prevented it from happening again.

The next principle is nothing special at Panther, this is something I’ve copied from great leaders I’ve followed. It’s deliberately pushing decision-making ability towards individual contributors as much as we can.

In an opposite situation and at a very ineffective org, all decisions will come through the CEO. Nothing would get done. Because people will constantly be stuck, waiting for the “dictator” decision-maker to step in.

So, as long as the decisions are reversible, we try really hard to enable our ICs to make them on their own. If they’re irreversible calls, then it makes sense to slow down and get more people involved.

A prerequisite for having the confidence to give as many folks decision-making autonomy is to hire really damn good people. And, in my opinion, one of the easiest ways to do that is to not filter some of the world’s best talent because of silly, unnecessary reasons like someone’s location or their time zones for that matter.

Another thing we follow is to ensure that every decision, whether that’s for a fundamental product change that someone’s advocating for or something smaller in scope, we have a listed, universally understood decision maker.

“We’re coding to solve business problems”

Contenda’s Lilly Chen with notes on their outcome-focussed engineering culture

If there’s a principle that drives us the most, it’s ‘don’t accept the status quo.’ That means if you’re working in a system and you notice a repetition or a pattern of errors or a particular type of failure, call it out! Let’s talk about why that is.

We don’t accept that something is just ‘the state of things.’

Because I do feel that sometimes when you notice a problem and tell people that a bug comes around a lot for instance, and they’re like ‘we’ve been seeing this bug for the past two years, we just reset it every time it comes up,’ that’s a problem.

Although, we also have a very strong business focus. We’re a startup. We’re not engineers in the sense that we’re coding for the sake of coding. We’re coding to solve business problems.

And sometimes, you run into a bug, and you realize that the only way to fix that bug would be to permanently rearchitect the entire thing. And that’s not worth it. Most of the time.

It’s not going to be worth it to resolve that inconsistency by having to spend a month doing a complete overhaul. And in those situations we have to evaluate that trade-off and do that as engineers and business owners.

That’s probably one of the key things for all the engineers on Contenda, that they have a very strong business focus.

Another important cultural practice is that we do not set traditional individual engineering goals. We don’t bother with them. Because typically goals are tied to promotions or status changes. And we don’t believe titles should be goals.

Goals that we do care about and we help everyone achieve are different. As I’m also everyone’s engineering manager, I talk to them about: what they want to learn next? Or what they want to experiment with? Or what was a problem that they found especially interesting? And then I support what I gather as their goals.

rajaraman · January 22, 2023, 4:22pm

As I look back on all the first-hand experiences that were documented on Relay last year, I remain especially fascinated by one thing. I cannot not notice the sheer multiplicity with which each and every aspect of running a SaaS business can be approached.

All the diverse founder voices, across SaaS categories (from disruptive CRMs to AI-first apps) and geos (from Stockholm to Fukuoka :)) have brilliantly reaffirmed Relay’s central premise: that there’s no one way to build a business. Truly inspiring. Thanks so much to everyone for taking the time to contribute!

Topic		Replies	Views
SaaS Founders at Work: 23 Inspiring Heuristics & Hunches from 144 Years of Building Heuristics and Hunches	0	4517	February 19, 2021
The Truths of Building a Must-Have SaaS, As Observed by Userlist's Jane Portman Heuristics and Hunches positioning , pmf , customer-research	5	2686	July 27, 2021
"No One is Coming to Save Us," The "Need to Reestablish PMF," and Other Earnest Founder Commits for 2023 Heuristics and Hunches pmf , operating-principles , founders-self , constraints	1	1380	February 13, 2023
Things That Matter During Any Crisis, Developing a Combination of Muscle Memory and Scar Tissue, and Other Earnest Founder Missives to Probe the Current SaaS Moment Heuristics and Hunches operating-principles , founders-self	0	946	June 9, 2022
Validating and Selling a Technically-Difficult Idea, Serving 2 Personas, Fundraising in a Tough SaaS Setting, and Working In-Person with Merge’s Co-Founder, Shensi Ding Heuristics and Hunches fundraising , hiring , founder-led-sales , pmf , founders-self	2	2228	November 12, 2022