When I’m winding down on coding for the day, it helps me greatly if I take a minute (or even a few seconds) to write out exactly what I’m going to do when I pick things up the next time. It saves me a ton of time by letting me not have to figure out where I left off. I can just jump in with a pretty good idea of where to go and what to write.
Awhile back, before the Internet was a glimmer in anyone’s eye, if you ran a business, chances are pretty good that you knew your best customers well. When you saw them, you might ask if they wanted the usual, and you’d get to know them on a more personal level because you saw them in real life and had real conversations. You’d know the names of their children, what their preferences were, and more. These relationships, paired with a good product are things that kept your customers coming back. It also made them more understanding if/when you had inventory issues, when service wasn’t up to the usual standards, or when someone else came along who did the same thing, perhaps even for a cheaper price. You said “thank you” face-to-face when they made a purchase.
The Internet has made a world where anyone with the skills and the ambition to start a web business can easily start one in a short period of time and make money from customers all around the world. It’s revolutionary, and it’s an awesome world to live in.
However, as people who run web apps, we haven’t had the same sort of connection to our customers. We see hundreds, maybe thousands of people signing up for our apps, but other than responding to support requests and making announcements, we don’t really interact with them much. And some of that is a good thing, because you can be available only when someone really needs you, and be out of the way at other times. However, after years of running successful web apps, I’ve learned that the people who I personally connect with are some of my best customers: the ones that are happy to pay me for my app… the ones who tell their friends about it… the ones who stick around for the long haul.
These days, customers are quick to press the delete button on their account if they have any issue at all, because they don’t know you. From bad experiences with customs support in the past, they assume that there isn’t a human who cares on the other end. What if they knew that you cared before they ran into issues? What if you both knew each other better?
As we build apps, it’s important to realize that we are building them for people. We’re trying to make their lives better, or their jobs easier. At the end of the day, we’re trying to improve people’s lives. And our customers are giving us money in exchange for our product, so let’s try to be more thankful and tell our customers that we appreciate them. Reach out to them when they sign up for your product with a personal email that thanks them for giving your product a shot. Give your best customers an unexpected discount, with no strings attached. Send out handwritten Thank You cards to people who have been with you for years. Whatever you do, just tell your customers Thank You somehow, on a regular basis. You won’t regret it.
If you’ve hung around startup-land long enough, you’ve heard the term “freemium”, which describes a product pricing model where you offer a feature-limited version of your product that has no time limit. Generally, free plans are offered in the hopes that some percentage of users will convert to paid users because either they’ll get far into using the product and decide that they need some feature that’s only available in the paid plans, or they’ll hit some sort of usage limit that you set, in which case they upgrade to paid for more of something that you offer. Conversions generally aren’t that great (as users will go out of their way to not give you money if you’re giving them something for free, such as religiously managing the contents of their 2GB free on Dropbox, or deleting less important photos from a photo sharing service that only lets you see your last 200 photos). However, some small percentage of those users do convert, and you also get good mindshare out of it if you’re big enough, because free users will be aware of your product and may recommend a paid plan to others… therefore your marketing reach is greater. Also, you can officially deputize your free users and make them affiliates, which gives them incentive to promote your product to people who they know, in exchange for a cut of your profits from the sales that they bring in.
If you aren’t running a SAAS app, but rather creating a downloadable app that people can install on their own servers/hosting, a different way to make money emerges. I’ve long been aware of companies out there who offer a completely free, downloadable software product that has paid support (so if you never need support, you’ll never pay, but if you do, you’ll pay a good bit).
Until recently, I thought that these were pretty much the only ways to run a software business that offered a product that’s free (for a limited time, or forever) and still make money at the end of the day. I was wrong.
I came across another model the other day, where a self-hosted app that appeals to a wide market is sold (let’s say shopping cart software, because that can potentially be used by anyone who wants to sell products online). The product is offered completely free to anyone who wants to download it. That makes it spread far and wide quickly, if the app is stable and has a good reputation. You build a community around that app, and add the ability to use third-party modules to add features to your app. Then, once your community/app users has grown to a sizable amount, you charge third parties a lot of money (I’ve seen $18,000-$30,000 so far) for the ability to integrate with your app and/or have their modules preinstalled when a user downloads your app. You’re basically using a free app to build a valuable platform that other companies will pay a lot of money to have access to. You don’t have to sell too many things at $30,000 to make real money, and it’s a way to make money that hides in plain sight. Next time you see this particular model in action, you’ll know exactly what’s going on.
I’ve run multiple web apps for years now, and over the years they’ve had different pricing models, from completely free to paid-only, with free trial periods of differing lengths.
As web app owners, we all know that one of the best things to do is to just get the first version of your product out of the door so that you can see how the market responds, instead of overanalyzing decisions before they can be tested in real-world conditions and with real customers. But of course, once you get your product out into the market, you should always be keeping an eye on things to see what you can be doing better, and improving on things that are working.
One of the things that I’ve messed up on repeatedly (but am constantly working on) is pricing. When Chris and I launched Are My Sites Up, we had totally free accounts that could check 60 sites at once. We didn’t even do the math about how much it would cost us, or how many sites we could reasonably check from each server… the numbers just sounded right. We immediately had server-crushing “success”, because people signed up like crazy for it, but quickly we realized that we could only afford to offer monitoring of 5 sites for free, and dialed the plans back.
With apps I launched after that, such as Are My Sites Up White Label and the original version of Dispatch, I used the lessons that I learned from launching AMSU to inform my pricing choices. In the case of both, there was no free version at all, only a free trial. My mistake there was not requiring credit cards on the trials, though, so many people would sign up and never convert after the trial period. Some would even sign up, promptly forget that they signed up, then never use the app again.
As a web app developer, it’s nice to see that a bunch of people are signing up for your trials… but it just makes you feel worse later when only 1% of them actually stick around and pay you for your product. What really matters at the end of the day is that you have a product that is helping people to do something more effectively, and that it’s making enough money for you to keep it going and support the users who need your product most. Also, as an independent developer, it’s also very important for me to minimize time spent dealing with users who will never give me money for my product.
I was always afraid to require a credit card on sign-up because I feared that it might cause people to close the browser tab and not bother signing up at all. I’m not afraid of that anymore because I know that now when I see a new signup, it’s someone who is actually actively interested in what I have to sell. Thinking about my own behavior when I see a signup form that requires a credit card: If I am truly interested in the service, but not ready to fully commit to testing it out, I’ll just bookmark it and come back when I’m serious and have time to use it, because I know that there’s a time limit before I need to make a decision, or my card will get charged.
Also, I’d much rather have a situation where I have 50 people who sign up for a trial, and 30-40 of them stick around than one where 300 people who aren’t serious about using the product sign up for the trial, cause a drain on support resources that could be used to help paying customers, and then have only a few of them even stick around after that.
Instead of letting them filter themselves out after trying your product and deciding that it isn’t right for them, let people self-select themselves out of even signing up for your trial by cutting out trials that don’t require a credit card. You won’t regret it. Recent apps that I’ve launched, like Stunning and the latest version of Dispatch have had trials with credit card info required since Day 1, and I’m starting to go back through my older apps and do the same thing. You should too. Learn from my mistakes!
As web developers, we’ve all run a beta, right? We think up an idea for an app based on what we see as needs in the community/on the web, ideally we validate the idea before we start to build, and then we get users to come and check out our beta, hopefully breaking some stuff along the way so that we can see what the pain points of the app are and make it as good as it can be for its release. We’re feeling good because we have all of these beta signups, and people seem to be using the service. Then we release it and not one of the hundreds of beta users sticks around and gives us their credit card information. Not one.
So you find yourself questioning pretty much everything: How could you have gotten things so wrong? Didn’t you build something useful? Weren’t all of these people actively using the service that I made? Why did everyone read the launch email that I sent, yawn, and completely ignore my email?
Recently I ran a beta for Are My Sites Changed (page change detection for web developers, letting you know if/when the source of your web pages changes). Some betas that I’ve run before this one have failed dismally, in pretty much the way that I’ve described above. This time was different.
What changed? Communication. I made a conscious effort this time to look closely at user activity, and follow up with people at their points of pain. Think about how you use web apps, and apply it to your thinking about how users will react to things in your app. It’s a lot lower-friction to just close the browser tab and never come back to an app that’s confusing or malfunctioning, and that’s what many users do. They hit a wall, and you’ve lost them… unless you notice and proactively follow up with them! I have never reached out to a user who has abandoned my app to let them know that their issue was fixed and been met with anything less than surprise that I noticed, amazement that the issue had been fixed so quickly, and thanks.
If someone signed up, added a site, and got a bunch of notifications about the same thing, I would email them and tell them how to set up exclusions, which tell AMSC what parts of the page you expect to change, so it doesn’t alert you about those. I saw those as potential users who would sign up, get non-stop notifications, not know what to do about them (even though there are instructions in every email alert, because people sometimes don’t read), and figure that the service was just broken. If I didn’t get in touch with them proactively, when I asked them to stick around a month later after the beta (if they didn’t delete their account beforehand), why would they give me money every month? Why would they give me money for a service that fills up their inbox with non-stop email alerts?
If someone added a site, but didn’t add any pages under that site, I’d follow up with them to see if they meant to do that, or if they only wanted to check one particular page for changes. If, during the beta they changed something on a page that they thought was being checked when it wasn’t, they might have assumed that the service was broken. Then, when I launched out of beta and asked them to stick around, why would they give me money for a service that looked like it didn’t work?
Also, when I noticed that things were broken, or I found out from a user that something wasn’t working or was confusing, I dropped everything and worked to make it right, then let either the user or everyone know about the fix, depending on how large the fix was.
There are lots of reasons that your beta users might not convert to paid users. Some of them aren’t within your control, like tire-kickers who sign up for every beta ever and never sign up for anything, or users who love your service, but don’t find it valuable enough for the price that you’re charging (that usually just means that they aren’t in your target market), but there are some that you can control. If you keep a watchful eye on what’s going on in your app and communicate with your beta users, you have a much better chance of keeping them on as customers.
In the case of Are My Sites Changed, 93% of the people that I talked to during the beta stayed on, gave me their credit card information and are happy customers. 93%!
We like to think that we’re building cool software that solves problems, and a lot of the time we are, but we should always keep in mind that your apps are made for people. Talk to them. Find out what they need/want. Do that.
retaining existing customers, and attracting more.
If you’d like to come along for the ride (and be part of the eventual beta, haha), sign up here!
For me, it’s the inability to effectively communicate with beta users and track their comments and suggestions in one place.
At this point, running a beta of your app is commonly accepted as a great way to iterate and test your app with real users and to figure out what the app really needs, but some parts of that process are broken.
I ran a beta lately for Are My Sites Changed, and I’ve run a few before that. I’ve started to notice a trend. During betas, more than almost any other time, I get lots of suggestions and comments, and they’re from all sorts of places, like email, Olark live chat, and even Intercom. It’s hard to keep track of who said what, when, and where, even when I know that a particular conversation happened.
During betas, the app is rapidly changing, bugs are getting fixed, features are being added and removed, and I want to keep my beta users informed, so that they know what’s happening, and that the app is getting better all of the time. So far, there is no good, integrated way to do that.
I want an app that will take my users/app from beta through launch and beyond, providing a great way to keep my users/customers informed about what is happening, to have an open dialog with them, and to use best practices to retain those users as customers for years after launch. I also want an app that takes what I learn from my users and helps me to turn it into knowledge that I can use to convert more users.
Is this something that you need as well? Sense Labs is starting to work on an app that will help to solve this problem, and more that we’ve seen while running betas and the web apps that come out of them. We want to build a toolkit for web app owners like us.
- Keep users informed about what’s changing in the app
- Surface useful data to you that you can use to find and reward the most valuable users that you have
- Remind you when the best times are to do things that will benefit your business, based on information that we keep track of for you.
- Give you an easy way to announce important things to all of your users at once.
- Find out what actual paying customers want, when they want it, and how they’re using the app, so you can best focus your development
- Find out how to retain users who are thinking of canceling their subscription to your app (and then actually retain them)!
- and a few more. I’ll be talking about them as time goes on.
Basically, we’re going to take what we’ve learned from years of running successful web apps, and use it to build an app that will help you be more effective at running your own web apps, communicating with your customers,
retaining existing customers, and attracting more.
So you’ve just released a new web app, but people are signing up and then not using the product, or signing up and then deleting their account shortly after. You can’t figure out why this is. You know that you’ve built something that’s useful to your target market, so why aren’t people sticking around? We hear a lot these days about the importance of A/B testing, using content marketing to get more users to our sites/apps, optimizing conversion rates, improving our funnels, and more. That’s all great, and it really starts to pay off later on, but what if you could improve your chances of converting a user who has already signed up for a trial of your service by making simple improvements? You can.
For a long time, I incorrectly assumed that customers who were having trouble or who hit an error with a product that I’ve created would contact me via one of the support channels that I have set up (live chat, Intercom, etc) if they ever needed help. Links to support are readily available on just about any page of my web apps, and I try to respond pretty quickly to all support requests.
Over time, as I’ve monitored my web apps with exception tracking software, I’ve realized that after hitting just one error or glitch during their trial, some users will completely abandon my apps and leave, never to be seen again. They’d much rather take the path of least resistance and just abandon the app altogether than spend a minute typing their support request into a box. I’ve seen this play out multiple times: Someone hits an error or has an issue, and 2 minutes later, they delete their account.
Here’s how you can fix this:
- Install some error tracking software. I recommend (and use) Sentry, but there are several alternatives to be found. Generally, this requires installing a tiny bit of code into your app (if you’re using Ruby on Rails, you just add their gem to your Gemfile and then bundle), and adding your app’s key into your app.
- As soon as you get an email notification that a user has an issue, fix the issue ASAP (I’ve found that issues which users hit during their trial are usually relatively simple errors).
- Then, be proactive and reach out to them that same day, ideally within an hour of their error.
- Bonus points: Don’t forget to style your error pages to match your app, put easy ways for a user to contact you right on your error pages, and give them an easy way back into the app. Don’t leave generic framework error pages up. They usually just leave a user stranded and out of your interface, with only the Back (or Close Window) button as their escape.
I generally say something like this (I’ve made it generic so that you can modify and use it if you’d like):
From our logs, it looks like you hit an error this morning when you were trying to do THING THAT THEY WERE TRYING TO DO. I’m very sorry about this, and I just wanted to let you know that the issue has been fixed. I know that it’s frustrating to have problems getting started with a new app. I’d like to invite you to give it another shot, if you’d like.
LINK TO APP
I’ve never seen this fail. I’ve gotten exactly 0 replies to this email but a 100% success rate in people signing up again and giving the app another shot. You’ve gotten a user all the way through coming to your site, reading about your app, signing up, and even being convinced to give you their credit card in some cases! That’s the very definition of a qualified lead. Don’t leave these users out in the cold.
We all know that when someone submits a support request,we should get back to them as soon as possible, but what about the support requests that take more than a few minutes to resolve? If a problem isn’t resolved on the day that a ticket is received, let customers know where you are with the issue, that you’re working on it, and how much longer they can expect for it to take. They’ll appreciate and respect you for it. As a customer, it’s terrible to take the time to write in about a problem and not know if you’re going to get a response in a timely fashion, or at all. Put yourself in the customer’s shoes and you’ll know what to do.
I’m doing this in jest, but if you do build some app that I’ve come up with as a Silly App Idea, please link back to the associated post
Here’s a silly app idea that I had today:
I want to make a to do list app where the font/checkbox gets larger and larger the longer you wait to check something off, so you feel more awesome when you check off that item after 3 months of staring at it.
When Are My Sites Up launched in 2009, we didn’t have many options on the Settings page. Over time, as we added more and more features, we started to outgrow the original layout, which was a few fields that just contained email address and a few checkboxes to turn some options on and off, and a field for the user’s SMS number. Since 2009, we added
- The ability to change credit card info
- iOS Push Notifications
- Android Push Notifications
- Voice Calls
- International SMS
- The ability to buy SMS and voice call credits
- RSS Feeds
- User Management
- Contact information for invoices
Each time we added something else to the page, I noticed that it was getting longer and longer, and that eventually the straw would break the camel’s back, but there was always something more important, or more pressing. Today a user asked to get a copy of their past invoice, and I decided to add that to the site so that users can generate their own invoices at will. As I scrolled all the way down the page looking for the best place to add the invoice links, I realized that today was the day that it all had to change. It’s pretty embarrassing that it got to this point.
Today I took the extra 30 minutes to implement a jQuery accordion, and now the page looks much better.
It actually contains more information than it did before (now there’s a list of links to all past invoices in there), but it is much easier to digest, scan and actually use. I’ve already heard from a few users who love the change. I just wish I’d made it sooner.
The moral of the story is: Always make your product better on both the technical and UX sides. Keep tabs on design choices that your feature set has outgrown, and assess your UX periodically to see whether or not things need tweaking. It’s a difficult balance, but your users will love you for it, and be more loyal because it shows that you have a dedication to improving the product over time. The same thing applies to iOS apps: if you continually make small fixes and updates, your users will notice and appreciate them. I’m working on getting better at both.