We are now with 5 in total: Dany and Cameron started this quarter, and we’re super happy with them, and their impact is already visible in the app.
When thinking about what to do in Q1 we ultimately decided to spend most of out time on the core of the product: the scheduling engine. Combined with great UX we believe this is our biggest asset and differentiator that’s going to help teams schedule way smarter and have more time for important stuff.
We started with an already powerful version of the engine that can find times in calendars of colleagues, combining signals like distance to other meetings, working days and times and preferences for focustime, all in real time.
We expanded on the scheduling engine with a couple of things that make it radically more useful:
-
Intelligent suggestions – You can request a time with our engine, eg ‘1 hour this week’. But what if one of us can’t make it? A common case. We spent a lot of time expanding our engine to be able to do multiple searches in parallel. If not everyone is available this week, we’ll nudge to broaden your search. Like: 1 hour early next week would be an option. We also try different durations: you might really want to meet this week, so if possible we’ll suggest shorter meetings that do work. We are not just using this when there’s a conflict. We are also using this technology to suggest improvements when we can drastically improve your focus time by altering the time or duration. Think about the collective impact Rise can have if on average all meetings are 15 minutes shorter – we believe our smarter suggestion are super promising to deliver on the promise of Rise: more time for what matters most.
-
Autopilot – Improving meetings when scheduling is great, but schedules are forever changing. So what about those meetings? You can now enable autopilot for specific meetings. Near the end of the day we’ll reschedule all of those, where we not simply move each meeting individually but take the complete calendars of each team member and check if we can improve it as a whole. If it does, we’ll reschedule and notify everyone. We think this can be a groundbreaking feature that radically improves days of individuals and teams.
-
Rise to Rise – We are all still fumbling with Calendly links, copying and pasting times over chat and email. Nice in 2019 but not in 2022. We enabled Rise to Rise scheduling, meaning for our engine it does not matter in which team you are, you can just say ‘find 30 mins with emiel’ and you’ll be able to find a time with me. In this case you will not see any other details about my calendar, obviously.
-
Simple and meaningful ratings – We also spent a lot of time revising the way we indicate the quality of a meeting and tweaking the internal scoring. Since this is the foundation of our engine, it’s super important to get it right and also to be able to instantly communicate to the user why a certain event can be improved. We switched to displaying relative focus minutes gained or lost, which makes it way simpler to understand.
Though our biggest focus was to leverage our scheduling engine more and focus on what sets us apart from today’s calendar, as a goal in Q1, we spent 25% of our developer velocity to work on getting to feature parity:
-
We finally support HTML and markup in our meeting notes. You can now finally click those video conferencing links if you need to.
-
Shipped the first version of recurring events. You can now make a meeting recurring every day, every week, every month etc. This covers around ~90% of the cases you’d like to create a recurring event.
-
View you colleagues events. You can now see what your colleague is up to. We also show our suggestions from the engine when viewing your colleagues calendar.
-
Shipped the sidebar that lets you quickly schedule a meeting with someone, look what someone is up to, as well as changing calendars.
We want to roll this out to teams as fast as possible, to get more feedback. That was one of the things we focussed on too, and will be focussing on in the next quarter as well. Zooming out: we’re aiming to have between 200 and 500 teams actively using Rise by the end of 2022. An ambitious goal, looking at the complexity of the product and individual wishes of teams, but we think we are onto something that’s immensely valuable and sticky, so this is what we’re going for.
It is really easy to fall into the trap of building something nice and not knowing if people will like it. We are really mindful of that. And we are also constantly asking ourselves: can we roll out faster? That means striking a careful balance in moving a bit faster than we’re comfortable and not wasting good teams with a subpar first experience. Here is what we’ve learned:
- Doing manual onboarding is incredibly valuable for us. We learn more about how people use their calendar and get to see their first reactions on the things we’ve built.
- We have enough teams that want to give Rise a try. Also, ~7000 people are on the waitinglist.
- We get a ton of valuable feedback, sometimes more than we can handle actually. :-)
- The value is starting to show. Inspired by Superhuman’s approach towards PMF we ask our users a set of questions to evaluate how much they like Rise. It’s been incredible to see how we’ve improved in so little time and we believe we’re onto the right path. Here are some of the things they’ve said:
"In 80% of the cases planning a meeting using Rise is way faster. That makes it worth scheduling with Rise.”
“The added value is starting to come. Also I’m under the impression when an entire org uses Rise it adds more value.”
"I see how this potentially is a very nice tool for our team. But there are quite a few quality of life issues that I bump into regularly.”
- Our ambassadors/early adopters are okay using workarounds, their colleagues are not. In order to roll out faster, we need to spend a bit of time ironing out bugs. Nothing groundbreaking, but it happens a little too often. We'll lose too many people if we increase the pace we're onboarding new people today.
In Q2 we’d like to hire one frontend and two backend engineers. We interviewed a lot of candidates but are quite picky so didn’t find the backend engineer we forecasted to have hired already.