Fred Wilson wrote about the value of blogging and building social capital, demonstrated by the hundred requests for invites he received on his post on his recent investment, Boxee, an invite-only service.
Now, while I find the behavior of public invite-requesting curious, I understand it.
I also think there’s another side to this equation that I’d like to point out, being one of the fortunate early adopters who happens to get invited to a lot of early alphas and betas… and that’s understanding the relationship between the creator of the beta and the testers. Or, to put it another way, requesting an invite to a service for one’s own benefit is one thing; understanding that an invite is a privilege given in exchange for feedback and suggestions provided is another. And the secret to getting early access to beta programs is, perhaps obviously, to be a good beta tester.
There are any number of ways to demonstrate that you’re worthy of an invite to an invite-only alpha or beta program. One problem is that a lot of beta feedback is submitted privately, outside of public forums. Whenever I can, I attempt to use more public forums, both for my own recollection, but also for the benefit or other testers, developers and later users.
In other cases, I’ll use Flickr or Twitter, leading to interesting phenomena, similar to what Fred describes.
In particular, I’ve been alpha testing a music player called Spotify for some time. It’s an incredible service and recently opened up with three levels of service, although it’s sadly not available in the US yet owing to licensing issues. Now, the only way to get an account with the service is to request an invitation.
It just so happens that I screenshotted an element of the new interface, uploaded it to Flickr and titled the photo “Spotify Invites“. That photo is now the second result for that phrase on Google and people have noticed, quickly exhausting my supply of invites.
The problem with this scenario, and with Fred’s, is that many folks seem eager to get access solely for their own benefit, without thought to the quid pro quo that makes beta programs successful (and ultimately benefit both the developer and subsequent users!). And I think it’s worth it to point out that beta programs aren’t just freebie give-aways: the gate is there for a reason!
I wrote this post in 2005, back when Gmail was an invite-only service (!!) and I was thinking about the relationships we were attempting to cultivate with the Flock alpha tester program:
So what of all these invite-only (or formally invite-only) services where you have to know someone on the inside to get a golden ticket? Does it artificially increase desire? Does it help services grow organically and cut down on trolls and spam, creating more value for invitees? Does it create more investment from the user community and perhaps establish even minor connections between invitor and invitee? Or does it create a false hierarchy around an inner circle of well-connected geeks?
Who knows?
What I do know is that it’s a curious trend and happening rather profusely across the web. Good or bad? I can’t quite say — except that in the case of Flock, we’re using the invite system to start out slowly on purpose. We want to not only be able to scale up organically, but we also want to cultivate relationships with our brave early adopters so that we can build the best experience possible over time. And to that end — we want to make sure that when we do launch publicly, we’ve hammered out all the glaring issues — as well as minor ones — so that sum total Flock makes you more productive, more explorative, and more voraciously social on the web. So for now, Flock will remain available to few kindred souls with enough courage to shove through our bugs and dodge the sharp edges. In the meantime, do add yourself to our invite lottery so that your name will be there when the next round of invites go out.
Not much has changed in terms of the structure of invite-only betas (even though the tools for managing them have improved), but I think something of the intimacy and purpose of these programs have been missed as more of the mainstream have gotten used to handing out just their email address for access to such initiatives.
As Fred points out that there’s value in building up social capital so that you can help stoke interest in new projects and draw the interest of potentially valuable contributors and testers, but it’s just as important to highlight the value of diligent and hard-working testers who have an interest in improving products and becoming partners in the potential success of such projects. I think there’s the potential for mutually reinforcing and ongoing relationships in the execution of a productive beta program, and that those longer-term relationships should not be overlooked.
. . .
To that end, I’m looking for some highly motivated and qualified testers for LittleSnapper, Real Mac Software’s new webpage screenshot utility. Be one of the first ten to leave a comment with your proper email address and a description of how you approach beta testing and I’ll send you info on where you can sign up. As I’m eager to see LittleSnapper mature, I won’t settle for just anyone — prove to me that you’d add value to the alpha tester program! 😉
Factory Joe 
I would like to betatest LittleSnapper. As a webdesigner I take screenshots everyday of websites to keep my inspiration in one place and Skitch i a good tool for it but i need a better one and I hope that this is going to be a killerapp.
You know Chris, the truth is in the past I think I have failed at being a good beta tester. Maybe for the reason you present above. I was in it for myself, but much more so because I was lazy and trigger shy. You know the old saying, “there are no stupid questions?” Well there are, and I’ve asked plenty of them.
So often I’d find myself noticing a bug or something amiss and let it pass – “Oh they already know this,” or “Geeze, I’ve never built an application. Who am I to tell them it stinks?”
Perhaps these were justifications for inaction, and I don’t mean to spill my insecurities on your weblog, but in the past I think I’ve missed the point with betas. That I’m the user. That if something seems wrong it’s my responsibility, not just to the developers, but to other users to mention what might not be working, to mention it with grace and wit and humility, but to mention it nonetheless.
Anyway, this is all to say in the past and on occasion I have stunk at beta testing, which seems a funny way to ask for an invite – give it to me I suck balls – but I kinda feel as if I have an idea about what the responsibilities and tradeoffs are of a beta tester, much more so that one or two years ago.
So, with that said, and in light of my past missteps, I think I might make a good beta tester for LittleSnapper because I use Skitch everyday and have a good relation point from which to work, I like to use an application like this for the blogging, and, most importantly, I want LittleSnapper to rock for us all and will due my part to insure that it does.
A little long here but such is my style.
For projects I work on, whether we go with an invite-only or wide-open approach depends on a number of factors, but primarily on what the project team thinks they can handle. Even with a beta label, there’s a measure of confidence in the readiness of a product or feature that comes with a wide-open approach. By using invites, the team can ensure a slower rollout that doesn’t get people’s hopes up only to lose their interest because the product isn’t *that* ready or the team can’t keep up with the amount of feedback. So for me, the decision comes down to “are we ready for everyone and anyone to take a kick at this?” and as such an invite-only path means a more controlled rollout, until we’re confident about opening the doors to everyone.
An extra benefit of invite-only and the slower pace they bring is that those answering feedback can take more time to have good discussions with testers, get followup data, and from that bring better feedback into the project. With a doors-wide-open approach, that’s not as easy, and the relationships that might have been built through an invite-only process might not happen.
I’m also a Skitch user, and would love to give LittleSnapper a try to see how it compares and contrasts, as I know what does and doesn’t work for me with Skitch.
During the course of -our- invite only beta, my team has been passing a tremendous amount of screenshots back and forth to hunt down active issues and space for improvements.
By beta testing -your- product, I hope we can improve -our- product, to improve -your- experience. Very ouroboros.
Hi Chris,
I think you I could be a good beta tester for LittleSnapper. Some of the reasons to ‘invite’ me are:
1) I’ve been eagerly waiting for LittleSnapper.
2) I’m a software developer who can help ‘explain’ bugs to other developers more easily
3) I use screenshots everyday, and looked at a number of screenshot applications, for both Mac and Windows.
Thanks!
I would love to help give feedback on ls.
I’ve got folders full of screencaps as I haven’t yet migrated to a management utility.
Just yesterday I told someone I wasn’t a good choice to alpha test his product because I wasn’t in his target demographic. I think that while testers have had the wrong idea, so have some who give out invites. Their motives are sometimes for buzz rather than good feedback and measured growth.
That said, I take screenshots all day as I write for Webmonkey. Currently I use a combination of Mac’s built-in tools, the Pearl Crescent Page Saver extension for Firefox, Pixelmator and Skitch.
I’m always on the lookout to improve my workflow and I’d be happy to provide feedback from the standpoint of a daily user.
I would love to have an Invite.
By the way thank you Chris for everything you do for the open web.
Nicolas
I’m going to play the devil’s advocate for a bit and pretend I’m not a developer who craves feedback.
There is definitely a difference between a beta user and a beta tester. The problem with beta testing invite-only tools is that a lot of these services are like blind dates. You don’t know what you’re in for until you’re committed for dinner, and sometimes you’re so turned off afterwards you can’t wait to get away.
When I asked you for a Spotify invite, all I had to go on (beyond your advocacy) was https://www.spotify.com/en/about/what/
“Spotify is a new way to enjoy music.”
How is that going to help me decide if I want to commit to being a good beta tester? The cost of requesting an invite is so low, it’s easier to ask for an invite first and decide once you’re in. A lot of web sites with invite-only programs don’t let potential users know what they’re in for, and do a poor job of cultivating their community.
If you use something that’s invite-only that you enjoy, the quid-pro-quo should follow naturally. It can be valuable feedback or strong advocacy, but that requires that the tool is igniting some passion in users, and that’s impossible to know sometimes without trying. You’ll get both beta testers and beta users in your invite-only phase, but in my opinion beta testers graduate FROM beta users. The graduation percentage depends on how well the service cultivates its beta community, and that community begins before invite codes are even sent. I suspect, like how to implement the login page, is an aspect that’s never given much thought by developers.
So, uh, given my stance…you don’t have to send me a LittleSnapper invite. =P
@Dave: I think you make a good point.
But I think it reinforces my broader point that there are two ways to approach beta programs — from a selfish perspective (i.e. “an invite is the only way I can access this app”) or from a generous perspective (i.e. “I want to help make this product better.”).
Certainly people just pounding on an app are going to reveal issues — scaling and whatnot — so it is useful to get “bodies in the room” so-to-speak.
But I think it can be counterproductive for your later ambitions if people sign up just to try-before-they-commit and write it off because it’s too “buggy”. This certainly happened to Flock, and I imagine it’s happened to Songbird and other apps in the past. People didn’t really think about what the “beta” meant, or didn’t care, and evaluated the app prematurely. And I think that’s damaging.
Instead, they should have been patient and waited until the final product had been released (or something close to final) to evaluate it. Unfortunately, betas are so commonly used and abused now that by the time you get around to getting access, you forget why you were interested in the first place.
In any case, I still think it’s worth thinking about one’s approach, as either a developer or as a tester, and optimize to whatever is more important to you at the time.