Instead of relying heavily on analytics, we collaborate with our community and read every piece of feedback to figure out what to build next. Here is what we've learned so far.
The first two pieces of advice you get after joining a YC batch are launch early and talk to your users. Both will help you to make something people want. At Raycast, we’re obsessed with user feedback. We read and answer each message that we receive. We value it more than metrics, and it’s one of our ways to collaborate with our community to shape Raycast.
"Amazing response speed. You are the only app I write feedback for. You are actually listening and helping." - by Antonio Stoilkov
For us being obsessed with user feedback doesn’t mean to collect and instantly forget about it. It means treating feedback as a conversation, act on it and close the loop. In this post, I’ll outline how we run our feedback loop at Raycast and what we’ve learned so far.
It should be easy and quick for a user to send feedback. Nobody wants to go through a five-step questionnaire to report a small bug. Instead, we provide a command to send feedback from within Raycast. During onboarding, we hint the Send Feedback command to new users to make sure they know how to contact us.
The command is a simple form with a plain text description and an optional email address. We don’t differentiate bugs, feature requests or general feedback. This is on purpose. We want to make it as seamless as possible to reach us. The email allows us to respond, ask follow-up questions and keep a history of previous submissions.
In addition to our built-in feedback form, we use our Slack community to collect feedback. Usually, users join our community after they’ve used the app for a few days. They are motivated to exchange ideas and Slack makes it easy to add more context. However, communication in Slack is different. People expect quick responses, and it’s no-longer a 1-to-1 conversation. Other community members can chirp in to upvote feedback or provide answers. Played well, this can foster a feeling of belonging.
Slack offers direct messages which are great to deepen the relationship with your power-users. I chat with Thiago, one of our early community members, at least once a week. Many ideas pop up during these chats. One idea was to generate the documentation of our script commands. Eventually, Thiago went ahead and built it himself. This isn’t so much about bug reports or feature requests any more. This is more about how can community members contribute from the outside to Raycast. And this benefits the community as a whole.
There is a caveat of having a community on Slack: People expect quick responses which can easily distract the team. For this, we’ve introduced an on-call rotation to sort out and respond to feedback.
Each week, another person of the team reads, filters and replies to every piece of feedback. All messages from the app get send to a shared inbox in Front. This allows the on-call to collaborate with the feature owner on a response. Additionally, we persist each feedback to a database in Airtable. This allows us to query it later.
At the beginning, we sent everything in real-time to a Slack channel. It turned out that this was very distracting for our team. Now, we batch the feedback of the last 24 hours in a daily digest. The digest is automatically posted in the morning. This way, everybody can stay on top of the received feedback without getting distracted throughout the day. It’s important to us, that every team member has access to the feedback for two reasons:
Some of our most-used features are based on feedback from our community members. For example, many users asked for a global hotkey to toggle the clipboard history. They were used to it from other apps. After hearing this feedback over and over again, we addressed it in a generic way. Now, users can assign global hotkeys to perform a command or open an app.
Don’t treat feedback as one way! When somebody takes the time to send you a bug report or suggest a new feature, you should respond. Our on-call’s job is to respond to feedback within 48 hours, even quicker in Slack. We want to make our users feel heard and encourage them to keep providing feedback.
It’s crucial to be honest with your users. If we receive a suggestion that we won’t build, we let them know. We want to set the right expectations. If they share our opinion and adopt the tool, that’s great. If they stop using the tool, that’s fine as well. You can’t build for everyone but you can stay flexible. We declined some suggestions initially, and after they came up more often, we decided to build them anyway.
"Awesome shipping tempo, keep it up!" - by Brian Lovin
In addition to responding to the feedback directly, we have a few other mechanisms to close the loop. We keep a changelog that lists new features, improvements and bug fixes for each update. We share each changelog entry in our Slack community and on Twitter. This makes it easy to follow our progress on the channels that our users already use. And for the folks that prefer email, we send a semi-regular newsletter that highlights recently released features and other tips.
As mentioned in a previous blog post, we don’t keep a backlog or have a roadmap. We try to stay flexible to fulfil the needs of our users. The user feedback guides us what to build in the short term. Our limited set of metrics help us go in the right direction in the long term.
A working feedback loop is based on trust. The quicker you address a bug report, reply to a feature suggestion or answer a support question, the more trust you gain. You build more trust with every positive interaction, and at some point you have collected enough to become friends with your user. And if that happens, you won somebody that cheers for you and spreads the word about you but also tells you when you screwed up.