Write code and talk to users. Here’s a good way to do the latter.
This is the easiest way for you to stay in touch with your community.
A ton goes into launching and scaling a successful product, but the two most important things are to improve your product and talk to users.
It sounds simple and repetitive, and maybe it is. Build a product. Talk to users. Make your product better. Talk to users. Make your product better. Talk to users.
At Assembly, we’re past those early days of focusing only on those two things, but our philosophy still focuses on improving our product and talking to users remain top priorities.
We talk to our users through many channels (Assembly general chat, email, Hangouts, events, etc.), but I wanted to discuss one particularly effective way.
A few days after each signup, we send a plain text email to check in. It looks like this:
And the most important part of this is that the email address they come from (firstname.lastname@example.org) goes to our entire team’s inboxes.
I know that lots of people like to cut down on email, but I can promise you that your team will love to be included on threads like these.
(And, of the many thousands we’ve sent, we’ve received surprisingly few complaints about these emails)
Here’s a bit of data:
Open rate: across tens of thousands of these emails, we’ve had an open rate of 64.2%. The average open rate for email marketing campaigns in our industry is 23.3%, so this email is clearly performing well.
There’s not a lot of industry data to compare with for response rates, but we see about 30% response rate, which — at 6% above industry standard open rates — must be pretty good.
The most important part of any product experience is the first impression, and this email gives us the chance to understand thousands of first impressions of our platform — from the very best to the very worst.
They range from positive messages that encourage our team to keep going:
To questions that point out places where we could better inform new users:
To specific platform feedback:
And sometimes, the responses are interestingly confused:
Now imagine these emails for your product. Would they help you improve your product? What if you had dozens of them? What if you had dozens of them every day?
This is such a great way to keep your team’s fingers on the pulse of your community. Everyone doesn’t read every email, but everyone skims them from time to time and looks for interesting things we can improve on.
And it’s amazing to see how responding to feedback works.
We’ll notice a trend in comments about a specific thing. Then we’ll build a feature that addresses it, and the comments will move on to a new bit of feedback.
Too much email
I think as we grow, we’ll still want the whole team to receive these emails — but, it has gotten really hard for me to be the one responding to all of them, so now I’m not the only one handling responses— but we obviously don’t want to respond twice to any emails.
Helpful is a super simple, totally free support tool. We’ve been using it for more than a year for support requests, but recently realized it would also function really well as a shared inbox— especially because it doesn’t have support tool jargon, responses look just like they were sent in Gmail.
(e.g. no ## PLEASE REPLY ABOVE THIS LINE ##)
In order to let people other than me reply naturally, we’ve had to tweak the email a little bit (still feels personal, but comes from email@example.com)
Now, we get all of these responses in Helpful, our entire team sees all of them, and anyone on the team can jump into the discussion at any time. It’s a really great way to stay in touch with our community.
To set this up yourself: helpful.io (it’s totally free, too!)
To see what these emails look like, sign up: assembly.com