Your Web App has Launched – Now What?
By Des Traynor
04 May 2010 | Category: Web Apps
Editors Note: In his first article for Think Vitamin, Des Traynor - UX Lead at Dublin based Contrast, outlines some extremely useful post launch strategies for ensuring the success of your web app. You can hear Des share more development stories at Future of Web Apps Dublin 2010.
Launch Time
Launch is a stressful time for web start-ups. It’s the culmination of many month’s hard work, arguments, agreements, feature debates, and design decisions. Someone runs a deploy script and poof! You’re not in Kansas anymore, and you’ll certainly need a brain, a heart and a fair share of courage.
Since most start-up advice covers the period before you’re live, I thought I’d write about two of the most common issues I see in web applications post launch.
Budget for Further Development
You’re planning on being successful, right? One thing you should know is that the vast majority of development will happen after you go live. Only when the rubber hits the road will you know what’s essential, what’s a priority, what features are “nice to have” and what ones are preventing sign ups, and real revenue.
You need to budget for development that will happen when you’re live, and you need that money in the bank when you launch. You can’t count on product revenue. You don’t have that much time.
Even if things are going really well and three hundred customers sign up for your app and eventually convert to paying customers. These days you have to at least offer a thirty-day free trial to let customers find their feet. So on day 31, you’ll have three hundred customers ready to pay you their $19.
When you strip out fees, hosting costs, etc, you’ll be left with maybe $5,000 to plan further development. That’s a long time to be running your application without any development, and $5,000 probably won’t buy you what your three hundred customers have been screaming for all month.
Design still Happens after Launch
At MIX10 this year, Bill Buxton spoke about the development of the Seattle public library. One point he made about the design process has massive parallels with application development…
“The design of the building wasn’t finished until the building had opened and there were people using it, because there are some decisions that you can’t make properly until you’ve seen the building occupied, because you’re just not gonna get it right.”
Market research, wireframing, prototyping are necessary to get you a good start, but once you’re live your users will show you how it all should work. Hopefully you got most of it right, but there will be changes, and you need to budget for them.
Where Revenue Comes From
The sad reality is that unless you’ve already amassed a significant following, through your reputation, your blog, your previous company, or by winning a competition, you most likely won’t have three hundred paying customers on day one. Try three. But that’s okay, you’re just getting started.
A motto I drill into client’s heads is that web applications don’t sell themselves. Even the beloved Network Effect still requires a network to begin with.
It’s easy to obsess over the one bug that stops one ancillary feature working in one version of one browser, or dwell upon one user who swears they’ll pay for Ning integration. This isn’t why you’re struggling to hit three digits. It’s just your scapegoat to hide a bigger problem.
Number of users, times value of plans equals revenue. Right? So all you need are more users and you’ll have more money. It’s simple, and that’s the problem with it. Saying “we need to increase users or “we need to increase our revenue per user” reduces you to the sleazy, pin-stripe consultant who chirps in with truisms like “guys, we need to move forward”, and “let’s aim for our deadlines”.
This simplistic way of looking at your application leaves you with no next step. There is no lever called “more users”. There is no obvious next step associated with “increase value”.
You need to focus your efforts. That’s why I draw this second diagram for clients (full size diagram).
This highlights the real issues. It shows exactly what goes into a typical customer acquisition. If you have some basic analytics tool installed, you can quickly quantify all of these numbers and see where your problem lies.
If you’re losing customers on day one of your free trial, you need to evaluate what the first login is like, and talk to your customers.
If your analytics highlight a lot of errors at the sign-up stage, or your funnel view shows that very few get past it, then you need an easier sign-up form, or more motivated users.
In my experience, it’s rarely one of the above problems. It’s usually far earlier in the process; no one has heard of you or your application. In analytics speak, the number of new unique visitors to your site each day is too low to see a solid increase in your userbase, and it itself isn’t increasing.
If/when we agree that’s your problem, then we look at that in detail. This usually involves a third drawing.
How can I put this in a way so as not to offend or unnerve? Basically, start-ups all suck at marketing/branding/pitching and most of all, selling. I don’t mean selling up-and-to-the-right bar-charts to VC’s, I mean actually selling the application you built to the people you built it for.
This is one problem that you can’t code your way out of. There comes a point where coding is procrastination. Unless of course your business depends solely on your respect from software developers, in which case programming is your best marketing tool.
Shouting isn’t Selling
As I type this post, there are four people in my twitter stream “marketing” their application by posting tweets saying “guys, I’d love some feedback” or “Check out xyz.com for all your xyz needs”. Using a link monitoring service like Bit.ly shows you exactly how ineffective this approach is. It’s the online equivalent of storming into a nightclub and screaming “Okay ladies, who wants a drink?”, and it’s about as effective.
By way of comparison, I often receive personal e-mail from both friends and strangers asking if I’ll try out their new project/application/piece-of-fun. These e-mails explain why they’re writing to me, how they know me, why they value my opinion about this app. It’s clear the author has taken their time to speak to me.
These guys get a 100% click-through rate. Some of them will get a “looks cool, but I’m not your target user”, some get tweeted, some get blogged, some will get a list of show-stopping issues, but they all get something, because they showed me some respect.
Broadcast mechanisms such as tweeting, blogging, sponsoring, advertising, even speaking at a conference are all great for making noise. But the value diminishes very quickly afterwards. Having genuine conversations with genuine people, is a far better approach to selling your application. It’s a far scarier prospect too.
It’s much easier to hide between your tweets saying “I’m doing all I can, users just aren’t coming”. The difference between broadcasting and communicating is that communicating involves answering tricky questions like “why is it so dear?” or “can it import Excel files?”
Lessons Learnt
You need to work hard for every user in the early days of a web application, and as you get them you need to have budget and plans for what you’ll do to make them happier as the relationship grows. Getting one hundred paying users is a huge milestone, getting to the mythical 2,000 takes patience and hard work. Act accordingly.
Follow @thinkvitamin on Twitter Please check out Treehouse
