In the following exchange, Vimcal’s co-founder and CEO, John Li (@John), chronicles how worries of shutting down were swept resolutely away with a product that people were instantly willing to pay for; and how it happened on user onboarding calls that became so much more soon after.
— How onboarding users manually saved Vimcal
— Unlocking what-users-don’t-even-know-they-want features
— Why they prioritized retention above all else
— The 50-75-100 process for running product reviews
— The subtle philosophy that makes Vimcal unique
— Driving a freemium motion with an iOS app
When we launched Vimcal back in early 2020, I did all the onboarding calls in the beginning. Partially, strategically. Partially because we only had a month and a half of runway left.
We needed revenue on day one.
To summon up a specific, stressful memory from that time: We were in touch with our lawyer, asking them about the prerequisites for shutting down, including how much money we had to put aside for legal fees.
How did we get there?
My co-founder and I had quit our jobs early in the journey, as soon as we had gotten into YC. We had already pivoted twice, previously having attempted an AR product and a fitness app. Then building out Vimcal’s MVP had taken us much longer than we had anticipated.
We were well into our third year of starting up, without much to show for it.
The weeks preceding the launch were certainly nerve-racking, but there was also this sense of nothing-to-lose lightness. At any rate, the launch was a complete Hail Mary.
Luckily, people loved Vimcal enough to pay us from the get-go.
A lot of them even asked to invest.
The other (more technical) reason we did those onboardings was because we just hadn’t had the time to develop a self-serve onboarding and payments into the app. We had to get on calls to onboard all users and charge them manually.
These calls were a do-or-die necessity at first. But they soon turned into — given the amazing lessons they produced — something we wanted to continue committing to.
The good thing about a calendar is that everybody uses one, so we had a lot of experience going in. Plus, this was a product we wanted to build for ourselves. Us wanting certain features really drove the first leg of development.
Post launch, when we started spending 30-45 minutes talking to people (asking them about how they used their calendars, observing them as they clicked around in the app) we quickly began to get a better idea of Vimcal’s best-fit users.
Founders, VCs, and other people who were scheduling a lot of external meetings really liked Vimcal. They still do. Vimcal is a product anyone can use, of course, but zeroing in on an ICP was still crucial to figuring out who was willing to pay for a calendar.
We then became hyper-focused on qualifying and bringing in just that group of power users from the waitlist. We got better at discerning feature requests. And in figuring out, not just what people wanted, but also, what we could safely say no to.
Then came a real element of surprise and delight.
We found ourselves shipping things that solved problems people didn’t even realize they had, because they were so used to operating the old way.
If I was to place a feature set on a 2x2 matrix, you’d have on one axis:
- Features users asked for
- Features users didn’t ask for (note: they didn’t explicitly say they didn’t want these, they just didn’t talk about them)
And on the other axis:
- Features they want
- Features they don’t want
This is where we, as a team, have excelled at.
Having closely surveyed thousands of calendars across all the years of talking to users, we’ve developed an eye at figuring out the quadrant that makes up what users want, but that they didn’t ask for.
These types of features are what lead to the most delight and pleasant surprises in an app. Users get an “holy crap I didn’t know I need this” type of euphoria, and this deep know-how is something no one can take away from us.
It’s SO clear what we’re going to be building next that we always have a roadmap for the coming 2-3 years. Today, I can close my eyes and pick the next set of features out of a hat.
And it isn’t just this product knowledge that has mattered.
For a huge percentage of our users, thanks to these calls, there’s a face to the company. Someone they’ve spoken with for at least 30 minutes. Someone they can email directly whenever they have questions.
For the first two years, we required every single new user to go through a 30-minute onboarding call. We’ve since gone primarily self-serve, but we still give access to only a select number of folks from the waitlist.
So, by definition, we’ve deliberately limited our own growth.
(A step from Vimcal’s still-active Request Access form)
When you’re trying to acquire the first 100/1000/10,000 users, a major trade-off appears: “Do we want more people at the top of the funnel or do we want better retention?”
Obviously, you can always tweak both levers at once.
In Vimcal’s case, we decided to focus purely on retention for a while.
We had thousands of people on the waitlist.
Yet, retention remained our no. one priority.
This has led to multiple experiments focused on driving better activation and expansion. Also towards doing things that don’t scale.
Providing unexpectedly quick customer service and continuing to push as many people as possible towards onboarding calls (to maximize what we were learning from above mentioned experiments!).
Over time, our retention rates have become extremely good. For example: 90% of users keep paying for Vimcal after 30 days. And the figure hovers close to 70% even after 12 months.
With the sheer abundance of roadmap ideas, we pick certain themes to run with, over a quarter or across a few months. A single direction for a short, concerted burst of product development effort.
A few months ago, we were focused on shipping mobile features (more on that channel in a bit). As a result, we’ve already been featured on the Apple App Store a couple of times.
Given the stage we’re at, we’ve also been working on features that can help accelerate acquisition. Vimcal is a PLG product. As calendars are inherently social, viral, and multi-player. An ideal tool to expand bottoms-up within (and outside) an organization.
So lately we’ve shipped some helpful teams-focused features. Solving for complex use cases where, say, a couple of internal users can schedule with three different external folks. And thus are incentivized to invite more teammates to Vimcal.
Our product development cycle is pretty similar to most companies.
Where product people and designers come together to decide on specs, arrive at what the feature should look like, and then hand it over to engineers who build it out.
One thing that we do differently is that we follow this review process of 50-75-100.
Because we’re a fully remote team spread out all over the world, there’s always room for miscommunication. This could be on the designer’s end or the engineer’s end, or something to do with the spec itself. It’s mostly human error that happens every now and then.
What we don’t want is for an engineer to take up something, build it out completely, only for us to realize that 2 specific parts are not as intended in the spec. You just waste a lot of the engineer’s time this way. The whole team’s time, really.
And time is money.
So we do a check-in at the 50% stage when the engineer has a really rough prototype. We just get together for 30 minutes, and say, “okay, this looks right, perhaps focus less on that other thing.” The designer is also in there tweaking.
The first design is never the ultimate design that goes out. No team is that perfect. Designers tweak once they have something to click around and realize that maybe the shade could be a shade darker or that an animation has a missing transition.
We follow a similar review 3/4 of the way through and then, finally, once more before we ship.
It’s similar to what Toyota popularized in the automotive sector. Having all the pieces go through the entire factory and reviewing each step, so that what’s broken can be caught as early as possible.
What people like about Vimcal is a very subtle thing.
We’re actually working on explaining our philosophy better. Vimcal is the only scheduling tool that’s designed to give you more control over your calendar.
We place scheduling in three buckets.
There’s external scheduling. As you and I are from different companies, if I schedule a meeting with you, that’s external. Then there’s internal scheduling. Meetings that I schedule with my teammates.
Then, finally, there’s personal scheduling. Which is, my deep work, my to-dos, my personal time, my family time, and all those things. Any productivity book recommends that you should schedule time for that focused work first.
But, if you’ve noticed, even if you have a single external meeting, usually your entire day revolves around that. For instance, I have this external call with you, so I’m not going to schedule an internal meeting over this.
This is a more high-stakes meeting than the one with my product team, because I can always be flexible there. I’m going to prioritize our chat over internal meetings.
By the same logic, I’m going to prioritize internal time with my team over personal time.
Vimcal is perfect at this because our availability features let you pick specific times for specific people depending on what you’re prioritizing in a given week or a day. The alternative is to use a booking link like Calendly.
I think Calendly is a really good product. We actually use it for some of our operations. But it’s not designed for one-on-one, ad hoc meetings.
This is a very important meeting. A less important one follows it. If I were to share a Calendly link, you folks would have the same access to my calendar, right?
That shouldn’t be so.
Then, merely because I have a three-hour block between 2pm and 5pm today doesn’t mean that I want a meeting there. Next week it might mean that I do. The week before that as well. This week, it doesn’t. My calendar must know that.
It’s not about Calendly. It’s that people misuse that product. Calendly is designed for people who have only one specific type of meeting, like office hours, phone screens, or customer onboarding calls.
But if you’re a founder or VC with all types of different meetings (investors, employees, lawyers, sales, etc.), using one link for all your meetings is not ideal.
Vimcal helps you design your day according to all your different types of engagements, ultimately leaving you more time for deep work and personal life. It allows you to have guardrails around your calendar.
That’s why our users feel this deep sense of satisfaction.
We have a very interesting business model.
Our iOS app (the mobile calendar) is free forever. The desktop app, which is the full-fledged experience, is paid with a seven-day trial. It’s $15 a month or $150 a year.
We decided to go free with the mobile app because when we looked at the market, we were surprised about the fact that there’s no calendar in the App Store or Google Play Store that’s made for work. Everything seemed consumerish.
Daily planners. The default Google/Apple calendars. Nothing built for people who schedule a lot of meetings on the go, probably work remotely/semi-remotely, and have these meetings spread across ever-varying timelines.
Last I checked, Vimcal was the only app on the App Store where you could pull coworkers’ calendars to see their schedules.
With the iOS app, we made it our goal to make it the most useful mobile app for work. One main way to do that was to allow users to create and schedule meetings more easily.
It’s so difficult to create a meeting in other mobile calendars that most people wait until they get to their computer to send out an invite.
On top of that we’re offering some team features as well.
So noticing this gap, giving the app away for free became a way to increase our top of funnel. Especially knowing that the full experience, the Vimcal desktop, is so good that as long as we get people in we can retain them.
As I noted earlier, we were featured by Apple among the “Best New Apps” within months of launching and are consistently recognized under the “Best Calendar Apps” category, which is very rare for a brand new productivity tool.
— Sunsama’s founder, Ashutosh Priyadarshy, on reasons that led them towards concierge onboarding and those that made them reexamine it
— ProdPad’s co-founder, Janna Bastow, on how product roadmaps are “a way to outline and check your assumptions about the obstacles your business will face”
— Compose’s founder, Rami Kalai, on the Race Car Method and prioritizing engineering momentum over accurate timelines