How to 'beta' test your product

This post is part of our Slidebean Startup Insight series, a weekly digest for early and growth stage founders. You're welcome to subscribe here


Last friday we launched our beta version of Slidebean Worldwide! As of today, we have 1300+ users who have created their accounts, and real presentations are already coming to life through our tool (Thanks!). In these context we came across an important question in our team: Do people really know what the beta label stands for? Some of you may know, others may have a faint notion, and some might not have the slightest clue. So, with this in mind, and since we want our users to have an experience that matches their expectations, here's a quick guide on how beta works!


Software Stages

Beta: Second star to the right 



In today's overly-techy-world, a software's life goes through various stages before becoming a fully polished, final release product. The first stage of software testing is the alpha test. At this point, the product is no longer an immaterial idea; the wireframes of the program undergo several in-house tests  to define the main features the tool will have. The result is a clear notion of the core design and process of use.

That's when the beta test/release comes in! (hence, the second star)

PC Magazine defines the beta stage as a "pre-release of software that is given out to a large group of users to try under real conditions. Beta versions (...) are generally fairly close in look, feel and function to the final product; however, design changes often occur as a result."

Beta also relates closely to an important Lean Startup technique called the MVP (minimum viable product), which is defined in Venture Hacks as "the product with just the necessary features to get money and feedback from early adopters" although in our case we are not pursuing the former quite yet. So...


What's the point of launching a beta?


Making sure you are on the right track is crucial when developing software, specially if you are a startup with small teams and limited budgets. Therefore, the beta approach lets you prove the assumptions about your product/service and pivot/move forward when needed. Here are the main reasons to go beta: 

“We’re excited to have our users test drive this public beta version and provide us with their valuable feedback.”
— Steve Jobs on the release of the Mac OS X Public Beta in 2000
  • Traction: You need to get the bun out of the oven, and you need a significant amount of real users to test your product.  Trends and patterns become significant only if you have a substantial sample of people trying it.
  • Lean development: Coding has a fairly earned reputation of being a complex endeavor, and that is why incremental development let's you code according to your validation, and maintain the ability to make changes at the proper time.
  • Feedback: Mom will always think their kids are beautiful. Same goes to designers and their beloved ideas. Fresh perspective is a must, and usability tests are essential to make sure your audience is reading your tool the way you are intending it to be read.
  • See what's missing: Even though the tool only has the basic functionality, early adopters will be thorough in telling you what they feel is missing, and what's working and what isn't. 



What to expect when you're expecting?


So, having a clearer panorama on what the beta is about, what can users  and software designers expect from this stage?




Bugs: These are almost a prerequisite of Beta versions (even the latest iOS 7 Beta was loaded with them). Codes get refined as users interact with the front end of the tools, so try to be patient and understanding of why they exist. Do make sure you report any bugs you may find to the software team! These reports become really helpful in order to improve the tool.

Again, limited functionality: Some of the features will not be active yet. Several functions won't be ready to use at this point and therefore it is expected that you won’t be able to do all the things you will likely be doing once the tool is in the shelf.

A premise: If the tool is sufficiently attractive at this point, you can rest assured the final cut version will be worth waiting for!


Software designers:


Data, data, data: This is the time to observe and collect data about the real use of the product. Where the steps clear enough? Did users overlook the command? Are they having trouble at any particular step?  Where are they accessing the tool from? Are the actual users consistent with the target market?

Criticism/Feedback: Each user is our most valuable asset right now, and what they have to say matters big time. You made them a promise and now they are entitled  to tell you what they think.


Our Beta is available to use right now, so you 'beta' be part of what Slidebean is and potentially will become!

Posted by