the joys and perils of beta

I’m learning more and more that I believe strongly in the value of a well thought out beta-testing launch for projects.  Not just for technology — the technology industry has simply given us the language to discuss and describe new projects and how we roll them out much more effectively.  Recently I have:

  • Realized that several in-house projects are stalled or struggling because we’re unwilling to implement anything without “finishing” everything.
  • Watched another project spring out of nothing and start to flourish because we decided not to wait to finish everything.
  • Been strongly encouraged to use a new software tool that was, upon use, clearly not finished, though we as users were not informed that it was a beta-test version until after we started complaining about the obvious bugs and lack of functionality.
  • Listened to a group of professionals discuss how and why something can’t happen or can’t be done — and then agree on it, in principle, while still denying the possibility of accomplishing it, mainly because they couldn’t envision how it would really work.
  • Worked on a project to build a new technology application in which everyone agreed that we need to just “try it out and see what happens”, rather than overbuild without any user feedback.
  • Collaborated with a colleague on successful and well-received new library projects on a “let’s try, and see what happens” model.

Here’s what I’m learning from all of that.  We must do things in the beta phase.  We can’t always wait until the process and planning are just right before we move forward.  We sometimes need to roll out projects and try them to see how it works in order to make the best result.  We need to capitalize on energy and interest when a goal is clearly in view.  We sometimes need to move forward to the implementation stage as a way to more effectively evaluate an idea’s utility so that we don’t kill a project because we couldn’t quite understand it in theory.  We need to stop overplanning and actually start to do things in service of our goals.

In addition to those exhortations to move past our own hesitation, libraries who roll out beta projects also must accept user feedback honestly and openly.  We need to be willing to make necessary changes when they’re identified.  We need to communicate with our users about the testing nature of any new project so that their expectations are realistic.  We must be clear about our abilities when a project is still under development.  We must also understand that users may tell us what things we don’t want to hear.

None of that sounds radical to me, but it’s harder than it looks, in practice.  Or so I’ve learned in beta-testing.

One thought on “the joys and perils of beta

  1. Matt

    A good number of the most popular services we offer, were only made “production” services because of overwhelming popularity after “releasing” it to the masses “unpolished”. Nothing is ever “done”, anymore. Nothing is ever “finished”, so at some point you have to release it into the wild, and see if the users shred it (and thus retool, or scrap), or love it (and thus continually improve it based on user feedback).

Leave a Reply

%d bloggers like this: