What I’ve found is that, in the end, users WILL encounter unanticipated problems, because you can only test so many desktop/browser configurations (until you can afford running all of them). The key is to be able to identify users that run into problems as quickly as possible and then try to engage them directly with an offer of help, gift certificates, extended trials… whatever it takes to get them to talk to you as they hold the answers (actually they hold the problems, it’s up to you to uncover the answers).

Thanks for sharing.

-Leon

loving the detailed posts. laying out your thinking as you go through customer discovery and validation gives me new ideas about how to go about the same processes on my biz. please keep up the great posts!

kareem

Right now, these are really just based on gut-feel estimates on the value I would place on each of these events, working backwards from the one real dollar event which is Revenue. CloudFire is priced at $50/yr so that’s the starting (or end) point. Then I just discounted from there. Some people choose to use lifetime value of a customer (which assuming 3 yrs would be $150) but I decided to keep things simple for now.

Once I get all my conversion numbers, then I can actually do the math based on that. So for instance, assuming that 1% of visitors that viewed my pricing page (Acquisition) convert to paying customers (Revenue), the value of Acquiring a user would then be $50*1% = $0.50

We had started with that but wanted to isolate the effect of a downloadable app from the UVP on the landing page. It will make sense to revisit at some point (once a baseline is established) and A/B test it’s impact again.

Regarding the download process, I still believe, based on our own experience and numbers, that the download button has to be the call to action button on the homepage / landing page.

I got a similar suggestion from Niall Smart (from http://www.echodio.com) to build some more visibility into differentiating “installer downloads” from “installer launches”. I agree and have contemplated doing that before. The challenge, for us, comes in building the right hooks from the installer to the back-end metrics system. We are using NSIS for Windows installs, and PackageManager for Mac OS X installs. I think I’ve figured out a way to do this. Are you using a 3rd party installer or a custom one?

In the right environment, Mac OS X + Safari web browser, launching the installer isn’t a problem as Apple auto-launches install packages. This is certainly a minority case but worth mentioning.

I haven’t had much experience with surveys and have always erred on the side of collecting less versus more at sign-up. I want to start with some installer events and maybe a/b test a sign-up form with a survey.

Cheers

Something like a ping when they start an install, a ping when they finish certain steps, and then another when the installer completes successfully. I’m feeling the need to know if users are even attempting installs, if they are trying and failing, and if so, where, etc. Your thoughts?

Also – you mentioned changing your process so that get an email before allowing a download. I took that a step further and put a quick one page survey in-line with the download link, so before they can get the installer they have to tell me some demographic information that I really want. It only takes them a few seconds and this helped me tremendously in figuring out who was responding to my attempts to drive traffic, and did not appear to deter anyone from completing the download.

I’m happy the posts have been helpful. Writing really helps me crystallize my thinking and forces accountability.
So thank you for reading..