How Early Adopters Don’t Have to be Ideal Customers, Founder-Done Customer Support as a Growth Strategy, and Other Notes on Building with Reasonable Ambition with Missive’s Co-Founder, Philippe-Antoine Lehoux

Missive-App-Philippe-Lehoux-SaaS-Founder-Interview-Relay-by-Chargebee

In the following exchange, Missive’s co-founder and CEO, Philippe-Antoine Lehoux (@plehoux), argues for a timely, earthbound sense of building. One that’s rooted in valuing the day-to-day, incremental work of crafting and eagerly supporting exceptional B2B software.

How their first (not quite best-fit) users helped
Why Missive wasn’t their first product
Why there’s no shortcut to user love
Twitter as an early acquisition channel
Why they don’t have an end goal for Missive
Winning at pricing without a pricing strategy

The-SaaS-Baton-Relay-Newsletter-1


How the first (not quite best-fit) users helped

The answer to how we landed initial product traction is quite simple.

We just built a product for ourselves.

With the first two versions, we were aiming at creating something that we personally liked.

Before launching Missive, we had gotten to a point where our previous business (also Missive’s main source of early capital; more on that below) Conference Badge seemed done. The product was coded. Plus, we didn’t wish to expand into other adjacent, event niches.

We felt that it was time to toy with a different idea.

The idea for Missive came from the fact that we had never wanted to use a traditional help desk for Conference Badge. A multi-player version of email seemed much better. So we started building one. Just something we would find cool to use.

Then, gradually, we released it to early adopters. People who were mostly solo users interested in trying various kinds of email clients. They weren’t our best-fit users. But their feedback informed the first important layer (more on this later as well :)) of our roadmap.

Following that, we entered a period where:

  • we needed to find our real, paying customers among all the different types of people that were using Missive for all sorts of use cases,
  • it was hard to focus on what we could build, given that the list of things one can build for an email client is pretty much infinite.

The first challenge required us to observe usage patterns and simply ask who was willing to pay for Missive. The second one was a bit more perplexing.

How did we figure it out?

Well, I wouldn’t call it a framework. But we always had two product choices.

Let’s say we have the resources to implement something new or to improve an existing feature. There are two primary roadmap buckets we can target:

  1. The things that make Missive a really great email client

  2. The innovation around collaborative, shared inbox features

That first set might seem secondary, but it’s as (if not more) important.

Because Missive shouldn’t just be embraced as a help desk by a team, but also as a daily email driver by all of its members. The ability to, for instance, assign tasks, doesn’t sound as useful if we’re not, first and foremost, a good email client.

If they don’t like the email experience, users can go back to Gmail/Outlook/Superhuman or whatever else they’ve used for years. Or worse, they get forced to operate two different tools. One that their manager insists on. One where they actually get stuff done.

With that kind of individual adoption, Missive won’t be a viable product choice for any team, no matter how many cool collaboration features we come up with.

This is where working with early adopters was really important for us.

As I had noted earlier, we couldn’t monetize these first users.

But the fact that they were willing to spend a lot of time telling us what they wanted from an email product, helped us get a lot right. And even though most of them didn’t convert when we started charging, they were deeply satisfied users (even fans) of the product.

When we reached Missive’s first paying customers, we already had the hardest part figured out. I’d even say, this underpins the reason why we’re able to compete with players who’ve raised hundreds of millions of dollars: They try to build everything at once. Fast.

Whereas allowing ourselves to focus on making the best email client and only then layering collaboration features, bit by bit, on top, led us to a rare, consistent product.

Today, when a 50-member team signs up for Missive, we’re confident that a lot of them will happily move their inbox habits to us and also then get the most out as a team. In return, Missive becomes a product valued by both the users and the buyers.

Sometimes we receive emails saying, “Missive changed my life” and we’re like, “isn’t that a bit too much?” Then they start to explain their past email workflows and we realize that they aren’t exactly exaggerating.

Why Missive wasn’t their first product

How are we able to build things step by measured step? To begin with, we’ve never had the urgency that some companies self-impose when they raise money.

My co-founders are incredible engineers. But they’re not people that can be told, “do that fast, we won’t sleep for two weeks so that we can ship.” They’re just not like that. And we all respect it.

They’re more about, “let’s build something every single day, show up, get something right, and improve what you didn’t get right on the first go.” I don’t see how one can fail with that methodical approach. You will create something good in the end.

Again, how did we sustain Missive?

Our previous product, Conference Badge, helped finance it. In some ways, Missive was us scaling up our ambitions. Asking: Now that we have a profitable product, how can we focus on something we couldn’t have done before?

It took us four years to get Missive to profitability. Going that long without salaries would have been impossible without our first, moderately successful product.

Herein lies a lesson.

Now, I’m not the “advice” guy, in the sense that I don’t usually reflect on our journey. But I can say that what we were always good at was being rational about what was possible next.

That informs how we look at our roadmap and products we’ve built. We would have never created Missive first. Because we knew it was too big of a problem. We didn’t have the means to accomplish that vision.

Creating a tool to create name badges, though?

That was reasonable. It took us three months to build a prototype and release Conference Badge. And we were lucky that there was a lot of demand for it and we could scale it to the point where it was profitable.

This is advice I can stand behind.

Try to work on things that you know you can achieve in a reasonable period, given the means you have. People tend to forget this. Because if you can build with great deliberation, nothing is going to stop you.

Why there’s no shortcut to user love

Why are we invested in customer support as an SMB-focused, self-serve product?

And why do we still do all of it on our own as founders?

For one thing, really.

Customer love.

That is our only marketing strategy. It’s really important to listen to what customers have to say. We can’t agree to all that they ask for, but we can always talk to them.

A good percentage of customer issues are just bug reports. When you have a dedicated team focusing on this and they sit even one level away from the development team, you eventually start to lose track of product problems.

That’s why, at Missive, all of us co-founders do customer support.

It’s not fun! Because you’re always learning about things the product doesn’t do. But being builders forces us to quickly act on most of these reported issues.

That’s been a big part of our success. Still. To this day, that’s how we do it. And we’re at a point (3000+ teams using us) where it’s starting to feel less realistic going forward. So we will have to arrive at a slightly different arrangement soon.

But even today, I personally respond to support emails.

After this call, I’d probably have around 20 of those to get to. :))

We don’t see this work as a pain, but a fuel for our product. There are a lot of people who should be craving more customer requests or bug reports. Because at first nobody cares about your product.

When there’s at least one person making the effort to ask questions, you ought to really answer them as truthfully as you can. Even offer to have a call with them and try to understand their problems. Because they’re interested in what you’ve created.

It’s probably not perfect for them. But you have an opportunity to figure out why.

I know, it can be frustrating. When a solo user sends 20 emails a week. But it’s worth remembering that even when there’s a small pain that they’re trying to communicate to you, there are many others who won’t and just churn instead.

I never write to companies with support issues. I mess around with the product and if that’s not satisfying, I just stop using it. They’ll just never know why. And there are a lot of people like me. So we should respect everyone who actually reaches out explaining a problem.

There are a lot of people that simply want to code and build things. They’re not keen on customer conversations. Some are even successful. Pieter Levels with his 8-9 projects (all 100% self-serve and he never replies to emails) comes to mind.

But for most founders, this isn’t realistic.

We have to have these calls. For a long while, on our own.

Aside from helping us build a better product faster, this has directly driven our growth with expansion. When a 5-person company grows to 100 employees and if they like Missive and know that we care, they won’t shop for a new solution.

To put it simply, there’s no shortcut for user love.

Even VC funding cannot create user love. Each week people email us saying they hate a VC-backed alternative despite having been with them for years. They say they don’t feel respected. They tell us how their pricing was doubled with no reason and things like that.

Why do companies do it?

Why disrespect your long-running customers with unjustified price hikes? The answer perhaps is VC money. These businesses need to grow fast and the needs of small customers are often clearly deprioritized, if not entirely overlooked.

Twitter as an early acquisition channel

Twitter [Now, X] was fantastic for finding Missive’s early users.

It’s totally fine to drop into other people’s conversations, if you do so respectfully. At first, it was a way for us to mention Missive wherever someone was talking about shared inbox or email delegation products. And we did hesitate and wonder whether we were being annoying.

We also found out that people actually clicked the link and, 9 times out of 10, wrote to us saying ‘this looks amazing.’ Many of these respondents went on to schedule calls with us.

But it’s also worth noting that Missive, at this point, was already a great product. We weren’t landing in these chats with a half-baked solution. As I had said earlier, we built it for ourselves first. And we’re pretty hard to please!

Then, we brought something useful to the conversation.

Why they don’t have an end goal for Missive

There’s no end goal for Missive. If there’s one, it’s to make something that’s good for our customers, every single day. That might sound cheesy, but that’s how we think about goal-setting (that is, in the general sense, we don’t! :)).

Whenever you set big goals, even when you achieve them, you often realize they have not quite changed your life. Instead you find yourself chasing a new set; ignoring small, incremental wins in the process. The cycle repeats.

I do not find that motivating. None of us co-founders do.

And since Missive is such a small team, our business reflects our personalities.

Similarly, we didn’t really have a goal to “exit” Conference Badge. We could have kept running it. We could have even hired someone to manage it and would have made a lot more money in the long term.

But, as a small team, having a second product, even when you’re not actively involved, is still a bit taxing. You need some space in your head. So yes, technically, we’re going all in on Missive. Freeing up the 5-10% of our attention that Conference Badge demanded.

And if there’s no grand objective, what’s the strategy going forward?

We probably need to change from a lean group of 4 to being a bigger team, eventually. Things can scale almost indefinitely that way. It’s the huge next step for us. Especially as our culture has long been tied to being small, scaling the team would be a major milestone.

That’s where we’d focus our energy next.

Especially as the existing team is so incredibly aligned that we can work independently for long periods. My wife is often wondering, “do you even have meetings with your co-founders?”

It has probably been a week since we spoke last.

So yes, we’ve got a lot of work ahead to find really good new teammates and then establish/scale that sort of deep alignment.

Winning at pricing without a pricing strategy

Missive was always priced lower than the VC-backed competition.

That has served as a great lever for attracting attention.

But it isn’t necessarily a “pricing strategy”.

Our costs are low — we don’t pay for ads, people generally find us via referrals, SEO, and other organic channels — when compared to other products, so it’s normal for us to offer reasonable prices.

The pricing advantage is also tied to the fact that all of our VC-funded competitors tend to move towards the enterprise segment sooner or later. Which wasn’t the case earlier. Today, though, it’s fairly clear when they have plans starting at $299 per user/seat.

To us, that’s preposterous.

And, of course, it also means that there are big organizations that are willing to pay those sorts of sums. Which is amazing and good for them. But we remain focused on SMBs. There’s no way we can bring them in at such price points.

People exploring products in the space, often click on our competitors’ ads, find that the pricing plans are out of their budgets, and then look for alternatives and find us.

We’ve never spent too much time thinking about pricing. We don’t do A/B tests or surveys or anything of that sort. We started with something we felt was right. Ran with the same pricing for three years. And only changed it when the product got significantly better.

The-SaaS-Baton-Relay-Newsletter-2


Related reading from the Relay archives:

Typesense’s co-founder, Jason Bosco, on why the SMB market is (predictably) left stranded
Bento’s founder, Jesse Hanley, on serving a $30/m customer and a $3000/m customer the same

3 Likes

Thanks for sharing notes from the Missive journey, @plehoux. Kudos on carving out a solid presence in a hyper-competitive category, that, too, as a self-funded business. The deliberate scaling of ambition you are advocating is really timely for startups across stages and types.

And I completely second your commitment to customer support. I’ve also long believed that companies often overlook the service half of SaaS. You’ve noted that there are no shortcuts to doing this, but now that you’re 8 years into it, are there some specific routines/automations that help you offer high-touch support as founders?

2 Likes

Fix bugs.
Do webinars instead of 1 to 1 calls.
Improve documentation.
Improve UI/UX based on support requests.

2 Likes