When the COVID-19 pandemic put a stop to all in-person events and social gatherings, Toasty had to adapt, or die. Kevon Cheung, Toasty’s CEO and Co-founder, decided to move the entire platform online and within four weeks, his team launched their new remote team engagement platform. He shares how they maximised prioritisation as a strategy in order to pull this project off in the time they did.
Toasty was a SaaS platform and events startup, and worked with events ranging from meetings to team bonding workshops. By using interactive activities at these in-person events, Toasty encouraged event participants to connect with each other and stay engaged. For example, participants might answer icebreaker questions on their phones as talking points to initiate conversation. “This was to get them to interact with each other, and get to know each other”, Kevon explains. “When people actively participate at events, they always walk away with more meaningful results.”
However, even though Toasty is technically a digital service, it hadn’t been used for fully online events before COVID-19: “If you were a host, and you had 60 people in the room”, he says, “you would put up the Toasty QR code somewhere and everyone could join the app from their mobile phones like that.”
When all in-person gatherings were banned, Kevon’s team had to respond quickly and find a way to adapt and expand their product in order to survive. They knew they had to build a fully virtual experience, but they didn’t know what it would need to look like to be successful. “We weren’t sure whether people would like it or not, because we have never done this before”, he explains.
In order to survive as a company, and learn quickly about this new environment, Kevon’s team decided to ship and test an MVP for a fully online remote team engagement platform in four weeks: “We decided, ‘Okay, let’s just put video and audio on our platform to make it easy for our users to use’. And from there, that’s when we made that big pivot to move from offline event engagement to remote team engagement.” This would give them real data from active users, which they could then use to iterate and improve their product from there.
To get an MVP live in four weeks meant his team had to move fast, which required them to be really clever about what they prioritised. Kevon says: “We had to find the easiest, fastest way to get there. Because of that methodology, we decided to put together iframes, cut all the unnecessary features, make it a very, very simple version, and then just put it out there.”
By focusing on a few key aspects of Toasty’s platform, Kevon and his team could build a functional MVP in a month’s time, and get active users onto their virtual site for further interaction and improvement.
The three tips Kevon shares on how his team thought about what to prioritise are as follows:
- Build as little as you can from scratch
- Let your users guide your app’s features
- Mould your UI/UX around the ‘new experiences’ first
Build as little as you can from scratch
Kevon’s team had a lot they needed to build and develop before launching Toasty as a remote working engagement platform. They needed video and audio capabilities, and they needed to adapt their interactive activities to work online as well as they do offline. If Kevon’s team built everything from scratch, they would’ve taken much longer than they did to deliver their MVP, and time was a critical factor for keeping their business afloat. Instead, they built only what they had to, and outsourced what already existed.
For example, developing a video conferencing software would’ve been a huge blocker to shipping a live virtual version of Toasty: “Video conferencing is actually really, really difficult to implement”, Kevon says. “The reason we could do it so quickly is that we didn’t build our own video software. We use an open-source encrypted technology called Jitsi, and we just figured out how to integrate it, how to turn it on, turn it off, and how to configure some of the settings.”
This enabled Kevon’s team to put more development time into the features that set Toasty apart. “When you have a startup, it’s really about ‘Let’s just do one thing really well’.” Toasty’s unique pull was keeping participants at events engaged through their interactive games – like the icebreaker questions, for example. Focusing on the things that would set them apart was more important than spending time on building software that already existed. This meant his team could fast track their app’s launch, and start getting feedback from their users
Kevon suggests deciding which builds are ‘musts’, and which are ‘nice to haves’ when you’re working with tight turnaround times. “Just find what is good, that is already out there, and don’t reinvent the wheel.”
Let your users guide your app’s features
Toasty had never operated as a remote team building platform before. This meant that Kevon’s team had no idea which features were more important to build and have ready first when their online app went live. What helped them move forward with confidence, and therefore speed, was letting their decisions be guided by data as far as possible – and this data came in the form of feedback from their users. Kevon says that user feedback helped them develop a better product faster:
“You should always stay close to your user. Building a product is the first step, but distributing it to the right person is actually really important too. Having conversations with them before we even had the product ready, meant we were able to get it to them quickly, and get their feedback quickly, so then we could evolve from there.”
To understand what would be most useful to start working on, Kevon and his team let go of their assumptions and focused on the data they got from product usage behaviour, and direct outreach.
Product usage behaviour
Toasty uses Mixpanel as a way to see how users interact with the app’s features, and then use that data to decide which features are most important. Using the data from customers’ behaviour on their app before their service offering went online meant Kevon’s team could decide which features were most important to double down on for the service to succeed in the new environment:
“Whenever an event is triggered”, he explains, “we send that data to Mixpanel. Pretty much from day one, we engineered all those triggers so we can easily see, ‘Wow, actually this thing, no one has ever used it – let’s just remove it, because it’s confusing for our users. It’s not adding any value’. So we strip that away.”
Moreover, Kevon says this made it really easy to be able to remove one’s ego from the decisions making, and prioritise which features to build first more effectively:
“Mixpanel really helped us to understand our user behavior and make those kinds of tough decisions, because they’re not ‘emotional’ anymore.”
“If you tie your ego to those things”, he adds, “you can’t move forward and improve as fast as you would if you kept those decisions ‘unemotional’. Sometimes we really have to strip away whatever we spent a lot of time on building, and that’s okay.“
The other kind of user feedback and research Kevon leveraged to prioritise features was reaching out to Toasty users directly. “Every time someone used Toasty when we first launched our in-person offering, I would reach out and ask, ‘How was the experience? Tell me everything, good and bad’.” By using this same feedback approach while building the new online platform, Kevon and his team could gain targeted and specific insight where there were gaps in the already-saturated video conferencing market that their app could fill.
However, Kevon says that most companies don’t have the right approach when asking their users questions: “Generally, you’re pitching your product to them, and so they tend to be nice – ‘Yeah, that’s a great idea. Do it!’ Instead”, Kevon explains, “find people that you think might be your target market, and don’t pitch to them; ask them how they’re currently solving the problem – are they struggling? Have they got a unique way of solving it? If they don’t, and if they say, ‘This is really painful’, then you have a chance to build something around it.”
This results in more accurate feedback about the problem you’re trying to solve. By doing user research like this, Kevon’s team got feedback faster, had better data to work with, and therefore could make quicker iterations and improvements.
For more advice on asking the right questions when doing user research, Kevon recommends The Mom Test by Rob Fitzpatrick.
Adapt your UI/UX to the ‘new experiences’ first
A big challenge for Kevon’s team was translating their in-person user experience into something that worked online too: “Before, people would use their mobile phone to join, but people are still in front of each other. So the UI/UX experience could be geared in that way.” In other words, the product was focused on using a digital app to facilitate human interaction, where the UI/UX was designed to improve that interaction. “When we moved online, though, we only have the screen to work with – no one can read emotions or meet up in person – so we had to think of ways to cater for that.”
One of the key adaptations they had to work on was how to make getting used to the app as easy as possible without having someone to give verbal instructions at a meetup: The design has to be intuitive enough for users to understand the app on their own. “We realised that we had to add more prompts and instructions to the user. When someone is hosting 30 people (team members) online, they’re not going to have time to be introducing this button and that button. We had to do that job well for them, so that everyone knew where to click so they could get started,” Kevon explains.
However, Kevon’s team couldn’t simply add prompts and instructions for everything. So, in order to prioritise which features would get prompts, they focused on building for how their product worked within this ‘new experience’ first: “For example, with video conferencing, most people know that you can mute yourself, that you can turn off your camera. So, we didn’t really need to educate them on that.”
Instead, Kevon’s team only worried about the features that were unique to their platform: “For example, when we look at our activities”, he explains, “some might have a timer, where you have to do something within 40 seconds. If you don’t give them an instruction ahead of time, they are going to freeze in the first 20 seconds and be like, ‘What is going on?’ and not get as much as they could have out of the exercise”
By using the above techniques to prioritise what needed to be done for quicker, more effective results, Kevon’s team managed to launch their new platform in four weeks. Although they’re still gathering feedback as they go, and iterating on improvements, new features, and new games all the time, they’re able to keep operating during these difficult times.