Why you should test your product
Getting your product out to market before the competition does is important, but not at the expense of customer relations and trust, and long-term relationships. While existing customers may cut you some slack, newcomers to a half-baked product are unlikely to be impressed.
The main reasons to test your product, when all said and done, are your reputation, to build and retain customer trust, and to avoid customer annoyance. Unfortunately, many people won’t tell you directly that your product or upgrade sucks: you’ll discover what they think on a reviews website. Public shaming is never a great experience, and it’s not surprising that many companies display a slogan to the effect of “If you like what we do, tell your friends; if you don’t, tell us.”
So how do you go about testing your product? The process used in testing software and apps can be applied more generally. The approach is essentially a two-stage one usually referred to as alpha testing and beta testing. (In the case of books, the equivalent stages are proofreading followed by sending the book to beta readers. This is, of course, a simplification.)
Alpha testing takes place within the company, when engineers, and others, put the product through its paces and try to identify and iron out any glitches.
They are unlikely to find every possible problem for one simple reason: they are not the end-users. You absolutely need to find out, for example, if your product is likely to work in a real live classroom.
As a case in point, I looked at a product a few years ago at the Bett show that was designed to be used to teach primary school children the concepts of computer programming. This product consisted of what seemed to be scores of tiny plastic shapes of various colours. These had to be distributed to the children at the start of the lesson and collected at the end. Now, bear in mind that primary school IT teachers are not usually blessed with a technician who can set things up and put them away. I asked the person demonstrating the product what happens when bits are lost. That is to say, can you buy small replacement packs, or do you have to buy the whole thing again, or can you buy packs of particular shapes?
“That’s irrelevant”, said the salesperson, “because the parts cannot get lost.”
“Really?” I asked. “Why’s that?”
“Because each part fits into the corresponding shape in the box, so you can see immediately if any are missing.”
What are we to surmise from this response? One could draw the conclusion that merely noticing that a piece is missing is enough to make it magically reappear. Perhaps. My own conclusion was that this product had never seen the inside of a typical classroom and that neither the people who had designed it nor this salesman, had a clue what giving out and collecting in dozens of small bits of plastic from 30 children would be like.
That company could have done with a proper process of beta testing. This is where a group of users test the product, in situ. In other words, teachers need to try it out with pupils.
To some extent that’s an artificial situation in itself. Most teachers would be wary of trying out a product that could lead to mayhem and chaos in the lesson and result in very little learning. Therefore, they are likely to try it with small groups of well-behaved children or run some trial lessons with the product after school, so that if it all goes pear-shaped it won’t matter too much. Artificiality isn’t ideal, but surely better than nothing?
Where to find beta testers
Now that I’ve convinced you to have beta testers, the next question is: where to find them? You could appeal to complete strangers, not all of whom will be teachers necessarily. If that’s your preferred option here’s a list of sites and directories to explore.
Probably a better, as in more appropriate, option, would be to invite applications from your existing users, or by approaching schools and academy trusts.
Existing customers are better, in my opinion, because they have skin in the game. That is, they want the product to be the best it can be, so they are likely to give you honest feedback.
You need to be clear on what sort of people you want in your beta testing group (Primary teachers? Specialist secondary Computing teachers? Bursars?). And you need to be clear on what you would like feedback on. Thus you should have a pro forma or online survey rather than a general “tell us what you think”.
Should you pay beta testers, or charge them?
There’s an argument for charging beta testers in the field of software development, on the grounds that people value what they pay for and will therefore take the process more seriously.
My own view is that if a school or a teacher is testing your product, they are already paying for the privilege in terms of potential disruption to kids’ learning, the time required to gather feedback from children and others, such as parents, where appropriate. This being so, the least you can do is provide the item free of charge!
If a product is in beta, people understand that it may not be perfect yet – that, after all, is the whole point of beta testing. However, what nobody wants is to be used unwittingly as testers.