Many of you are familiar with our Beta Management Resource Library, where we publish detailed content on beta testing best practices. Well, we also have a ton of resources on Centercode’s software and service offerings. So we’ve put together a resource library specifically aimed at helping people determine whether we are the right fit for them and their beta challenges.

In the new Centercode Purchasing Resources Library, you’ll find:

• Case Studies about the challenges our customers faced and the results they achieved with us,
• One-Sheet Brochures that give a high-level view of Centercode’s various offerings,
• Executive Overviews that show how the different editions of Connect can bring value to your beta,
• …and much more.

We’ll add resources to this page over time, so if there’s something you’d like to see, let us know in the comments below or by email. We hope that these resources will provide a clearer, more complete picture of how Centercode can bring value to your beta program and help you determine if we’re the right fit for you.

Visit the Centercode Purchasing Resources Library now.

Product launches are often shrouded in secrecy, with a focus on making a big splash when the product is launched. Teams often devote months (if not years) to developing a new product. As you and your team get closer to the release, you get more and more nervous about confidential product details going public. In those final weeks, putting your product into the hands of a group of complete strangers for a beta test can feel like a huge risk. What if someone finds out about the bugs we uncover? What if a beta tester tells the press about the product? Or worse, gives it to my competitor?

What most teams don’t realize is that beta test leaks are actually quite rare and easily prevented. By putting a couple best practices in place, you can greatly diminish the likelihood of a leak while preparing yourself to handle a leak if it occurs. Our new eBook will help you identify the risks and take the right steps to ensure that your confidential information stays that way.

Our Keeping Beta Tests Confidential eBook covers:

• The Different Types of Prerelease Leaks
• Why Companies Fear Prelaunch Leaks
• Where Leaks Really Come From
• How to Increase Beta Confidentiality
• Monitoring for Leaks
• What You Can Do if There’s a Leak

The processes and suggestions in this eBook are taken directly from our best practices after running hundreds of beta tests for the biggest names in tech. It’s our hope that this resource can help you breathe a little easier as you prepare for your beta test, knowing that your product is protected.

Download the Keeping Beta Tests Confidential eBook now!

In beta testing, your schedule can be a moving target. One little slip can throw your whole beta plan off track, leaving you with a pool of anxious beta testers and looming deadlines. In this installment of the Beta Tips series, we’ve put together some tips for managing beta schedules and delays.

1. Be Regimented, But Not Specific

It’s best to be vague about dates when talking to your testers. The nature of beta testing often requires you to shift your schedule to accommodate issues and changes. If you lay out everything in numbers of weeks, most of what you’ve told testers will still be true if you have to adjust your schedule. If you give testers specific dates, one small hiccup cascades into a dramatic change that affects every subsequent date. For more on this, download our software or hardware beta planning kits.

2. Practice Consistency

“Keep to a regular test schedule. Overall participation improves when keeping to a consistent test schedule. I send out new testing instructions on the same day each week and ask testers to complete surveys by the same day each week. I’ll often see my numbers drop off when forced to diverge from our regular schedule.”
— Geoff Griffin, TiVo

3. Incentivize Extensions

If you need to extend your test beyond the specified period, it’s important to budget for additional incentives. Your testers committed to a specific term, and your good will with them can take a hit if you extend those terms without sweetening the bargain. Just as important, the extended commitment needs to be optional. It’s likely not their fault the test ran long, and they shouldn’t be penalized if they can’t continue.

4. Make the Most of Slips

If you have already shipped a product or people are prepared to test but some last minute issue has caused the project to slip, you need to change your focus fast. Examine a part of the product that is unrelated to the slip and ask testers to focus their energy on it. If the slip is severe, it may make sense to put the test on hold. However, only do that if you believe that you can’t solve the issue within a day or two of test start. It’s very difficult to regain test enthusiasm and momentum once a project has been placed on hold.

If you do face delays in your tests, our beta management platform and managed beta tests can help you catch up by completing your test in half the time.

Want more tips? Download the full set now.

In honor of March Madness, we’re releasing a case study on Future Stars Gaming and their brand new Facebook game: Basketball Dreams.

The team at Future Stars Gaming (FSG) has been working hard on their suite of Facebook games for nearly two years. Before they launched, however, they wanted validation that their first game, Basketball Dreams, had everything their players wanted. With this in mind, they came to Centercode’s Managed Betas team. The result was a flood of objective, constructive feedback that helped the FSG team improve and launch their game.

To read more about FSG’s experience with Centercode’s Managed Betas team, download the complete case study. Afterwards, be sure to head over to Facebook to check out Basketball Dreams for yourself!

Download this case study now!

For this installment in our Beta Tips series, we’ll be looking at best practices for handling feedback. The rush of information you receive during your beta can feel overwhelming. These tips will help you manage it in a way that gets you the data you need while keeping your testers engaged and focused.

1. Be Responsive

One of the easiest ways to improve participation in your beta is to be responsive. Participants (understandably) get discouraged when they offer feedback but receive no response or indication it has been read. By being responsive, you demonstrate that their feedback is valued. It’s also an opportunity for you to get more information on reported issues.

2. Be Genuine and Specific

One caveat to being more responsive is that you shouldn’t fake it with boilerplate responses to feedback. Canned responses are hardly better than no response at all. Users see it as impersonal, and it makes them feel like you don’t really care about their input. Instead, make your response specific to the feedback at hand or to the user’s participation in general (e.g., “Thanks for your hard work recently. You’ve given us some very helpful bug reports and feature ideas this week.”)

3. Use Bug Frequency for Severity

Redundant beta feedback may sound like a nuisance, but it’s actually an excellent way to measure the severity of bugs. If a significant number of testers report the same problem, it immediately escalates its severity. Thus, it’s important to encourage your participants to report all problems they encounter. Doing triage on bug reports is a much better problem to have than releasing a product with small, widespread bugs that slipped through the cracks during beta.

4. Use a Variety of Feedback Mechanisms

It’s good practice to offer your testers several ways to share feedback. Some people like discussing the product on forums where they can chat with others. Other people aren’t comfortable with the idea of bug reports, but will provide amazingly detailed feedback in a daily testing journal. Some will thrive when given specific directions via tasks and surveys. By providing different opportunities to participate, your testers are more likely to find feedback mechanisms that resonate with their individual preferences and ongoing needs.

5. Stay Off the Low Road

At some point, you’ll run across a participant who doesn’t like your product, gets frustrated with a bug, or just has a negative attitude. This can be a tough situation, but try not to suppress criticism or respond negatively to it in any way. If you publicly censor testers, you risk alienating them and limiting future feedback. And if you attempt to rebut what was said, it looks like you’re not interested in honest and candid feedback. On the other hand, if you feel like you could learn more about the problem by asking questions, by all means do so. Just be careful of your mindset.

6. Enable Tester Creativity

You might think it’s best to discourage testers from using your product in unintended ways, but there are benefits as well. When you allow testers to use the product how they want, you’re tapping into a great resource for future product and feature ideas. And since you can’t always control how paying customers will use the product, it’s also a chance to get insight into support issues that may arise from unforeseen use cases.

Want more tips? Download the full set now.

Being able to communicate with your testers is a big part of any beta test. From recruiting, to selection, to thanking them at the end, you want to make sure that your emails are getting through. Otherwise, you run the risk of your testers missing out on important information as your emails languish in spam, and you get more frustrated with their lack of response.

We’ve put together a list of tips that can help you avoid the spam folder and make sure your emails get where they need to go.

1. Use spell check. It may sound silly, but misspelled words can trigger a spam filter.
2. Avoid using words like: free, win, or sign up now. This is especially true for the subject line of the email.
3. Include the “opt out footer” in every email. In our software, Centercode Connect, this option is located under Advanced Options when you create the email.
4. Minimize the use of all capitals. This is especially true for words such as “UNLIMITED” or “NOW”. It’s another red flag for watchful spam filters.
5. Be careful when you cut and paste. Often when you cut and paste from a Word document, you can bring over extra unrecognizable HTML characters that are ignored by most browsers but picked up by spam filters. To avoid adding extra or broken HTML, copy and paste your text into notepad before putting it into your HTML editor or email application. This will remove all the HTML, resulting in a much cleaner email.
6. Get on your users’ safe senders list. When you can, encourage users to add your email address to their contacts or safe senders list. This will allow your emails to bypass their spam filters completely. Keep in mind that this email address may be different than your own, particularly if you’re using a tool like Connect to communicate with your testers.

Want more help? Below are some resources that provide more tips on how to craft emails that are less likely to get lost in the internet ether.

SpamAssassin’s Tips for Legitimate Senders to Avoid False Positives — These guys actually make an anti-spam tool and have great advice to help you draft emails that won’t get picked up by spam filters.

Microsoft Outlook Spam Triggers List — Periodically, Microsoft puts out a list of words to avoid so that your emails don’t get stuck in their junk email filters.

MailChimp’s Guide on How to Avoid Spam Filters — This in-depth guide comes from a company that specializes in mass email marketing and provides some great inside information and best practices.

Do you have an additional tips for avoiding the junk pile? Leave them in the comments below.

Learn more about how Connect can help you manage your next beta.

The Slice team was busy putting the final touches on their photo-sharing mobile app and didn’t have the time, experience, or internal resources to run a traditional beta test. They had given the app to friends and family to try out, but simply weren’t getting the feedback they needed to perfect their app before launch.

Through our partnership with Idealab, the Slice team was able to connect with our Managed Betas Team. Our team was able to help get the Slice app into the hands of real customers. Read more about Slice’s experience by downloading the case study below.

Afterwards, be sure to check out the Slice app for yourself.

We’ll be releasing more case studies in the coming weeks, so stay tuned.

Download the complete Slice case study now.

We’re continuing our Beta Tips series with a crucial topic: maintaining tester participation during your beta test. Many beta tests suffer from dropping participation after the initial excitement of the beta test wears off. Below are some of our favorite tips on how to keep testers engaged with the product and providing feedback. Looking for something more in-depth? Download our whitepaper on Reaching 90% Beta Test Participation.

1. Use Good Tools

At the risk of self-promoting, beta tools matter. Giving beta testers access to good tools for sharing their experiences helps ensure that you actually get feedback. Tester-friendly and well-organized beta tools build momentum early in the test. On the other hand, if your testers struggle to share data with you or have to juggle a bunch of different tools (and separate user logins), they’re less likely to participate. There’s a reason why we see an average of 90% participation in our beta tests, and Connect is a big part of that. Beyond reducing tester participation, a collection of disconnected tools also makes it much more difficult to monitor participation as a whole, as well as work with the incoming feedback.

2. Throw Out the Bad Apple

One bad tester can spoil the whole bunch. If you have a person who is excessively abusive, negative, or offensive, it’s important that you pull them from the test. Otherwise, you risk letting that person ruin the experience for your other testers. The more people are negatively affected by a bad tester, the less likely they are to participate. So, effectively, you’re not only hurting your other testers, but your product as well.

3. Rely on Open-Ended Questions

You can really encourage participation by relying on open-ended questions. When you ask simple “yes” or “no” questions, you’re closing off opportunities to learn more about what participants think of the product. They might have had great feedback if the question asked “why” or “how” instead of “yes” or “no”. There are times when you might have to use simple, closed-ended questions — particularly toward the end of long beta tests, when participation is dragging — but these types of questions should be a fallback rather than a standard.

4. Use Expedited Shipping

If you’re testing hardware, use overnight shipping when possible. The added expense comes with benefits. First, it’ll help you ramp up the test faster. Everyone experiences launch lag, but when your product spends less time in transit, you get shorter test phases. Second, it sends a very positive message to your testers. By spending more on overnight shipping, your testers will see that you’re just as eager as they are to start testing the product.

5. Practice Creative Thankfulness

We always encourage you to thank your testers early and often. They really respond well when you show them that you appreciate their feedback. By offering positive reinforcement throughout and incentives at the end of your beta, you’ll be well on your way to making your testers happy. If you want to build an even more positive relationship though, consider adding something creative, unique, and commemorative into the mix. Tester team t-shirts, for example, show your appreciation and add an extra sense of exclusivity to tests.

6. Be a Good Moderator

This means being careful to watch for tangents and diversions. They’re a natural part of beta testing, especially when you run discussion forums for your testers. But if testers start to focus on one thing for too long or become mired in unproductive discussions, don’t be afraid to gently steer them back to the charted course.

7. Emphasize Exclusivity

One of the best tools at your disposal for building a sense of community is the exclusivity of beta testing. Testers thrive on that idea. It makes them feel like they are special as well as part of something special. The result is a more dynamic community of beta testers that are highly-motivated to help shape your product.

8. Avoid Over-Releasing

It can be a fine line, but try to keep product updates to a minimum during your beta. On one hand, updating your product during beta does show responsiveness and gives you a chance to perform regression testing. On the other hand, too many updates can frustrate your testers and discourage participation. Even simple software installations can get tedious if you subject your testers to them regularly (hardware can be much worse). And if you release updates frequently enough to become predictable, people will stop testing in much the same way as if you were announcing upcoming builds.

9. Don’t Demand Conformity

Beta testers are all unique. Sometimes it’s better to adjust the test to accommodate them rather than to force them comply with specific demands. For example, while user forums are a great way to keep users invested daily, some people just aren’t social enough to effectively utilize that channel. In that case, asking for daily update journals can be a better option that produces the same results.

10. Act Quickly with Idle Testers

The longer you let idle testers slide, the more it makes it seem like you’re not serious about participation requirements. Give your testers a gentle nudge if you notice they haven’t been providing feedback regularly. A simple email showing them what they’ve done and what you expect from them will get most people engaged again. If you let it linger, they will think you don’t care and then it will be too late.

11. Keep Your Opinions to Yourself

Testers are easily swayed. If you express that you like or dislike anything related to the product, they’ll demonstrate an aim to please. Suddenly, your data will trend toward those opinions. If there’s a need to share an opinion, be objective. Point out the good and bad of both sides or ask questions that make testers think about the idea. The only time you should use strong opinions is to encourage or discourage a discussion.

Want more tips? Download the full set now.

In recent years, the mobile app market has come into its own as an exciting, highly competitive industry. In a world where a couple of negative reviews can doom an app to obscurity, we’ve found that beta testing can play a valuable role in helping app developers put their best foot forward when launching their product.

As mobile apps become more complex and mobile customers more demanding, external testing and customer validation is becoming a crucial part of the app development process. However for many companies, the development budget hasn’t grown enough to run a professional beta test. This inspired us to put together a managed beta offering specifically aimed at the needs of app developers. This solution is intended to offer distinct value based on the challenges inherent to each mobile platform.

iOS Beta Tests

Apple limits iOS beta tests to 100 testers annually. Given this constraint, our iOS tests consume only 50 of your seats, but are designed to maximize the participation of those users, focusing on functionality and customer validation of your app.

Android Beta Tests

Android, on the other hand, is plagued by device diversity, with new products being released every week. Given this challenge, our Android tests include up to 150 testers. This allows us to recruit a wider range of devices to test for compatibility.

Regardless of your platform, our recruitment processes will identify and find the right testers so that your app is put through its paces. And since we know your budget is limited, this new offering only costs $3,000.

Our hope is that this offering will allow more mobile app developers to be able to take advantage beta testing’s benefits, maximizing their chances of success in this challenging, rapidly evolving market. If you’d like more details, you can read about our offering on our site and contact us with any questions you have.

Ready to get started? Request your free mobile beta test plan now.

We’ve been providing managed beta tests as a service to companies of all sizes for more than 10 years now. We’ve managed tests for countless product categories, from mobile apps and massively multiplayer games, to next-gen thermostats and enterprise hardware. At this point I think it’s safe to say that we’ve managed a wider variety of beta tests than any company, ever.

Each year we listen to our customers, and further adapt our offering toward what’s most valuable to them. This year, more than any other, we’ve made radical changes to improve our Managed Beta offering, all of which we believe you’re going to love.

Free Beta Plans

Professional Beta Test Plans have been a staple of our Managed Beta offering since its inception in 2001. In 2012 we improved our plans with a complete redesign (based on our new free Hardware and Software Beta Test Planning Kits). For 2013 we’ve decided to make these plans part of the sales process, replacing our current proposals entirely.

What this means is that we’re willing to develop a free beta plan for any company (with no commitment), just for the opportunity to demonstrate our value and expertise. As an additional benefit, we’ll more clearly understand what you’re looking to accomplish, and you’ll more clearly understand exactly what we’ll be doing — before any money changes hands.

The plan will be delivered with a mini-proposal that includes our fixed bid for running that project. You can then choose to let us run it, purchase our software and run it yourself, or go a different direction entirely (no hard feelings, we promise).

If you have a beta in your future, please take us up on our free beta plan. I’m confident that you’ll be impressed.

Simplified Pricing Model

Full disclosure: given the diversity of product types, markets, and beta objectives; pricing a managed beta service offering has always been more than a bit challenging for us. That said, we’ve been at this a long time, have a solid understanding of the variables, and have built great processes to handle them. With that in mind, we’ve developed new predictable pricing based on only two axes — duration and testers.

Duration is calculated in weeks, which are based on the number of goals you’ve set. Testers are grouped into tiers of 25, which is based on the number of target markets (or personas) you’re attempting to reach in your beta test. This allows us to not only provide quotes faster, but also provide price charts to our Beta Program customers, giving them the opportunity to more easily budget for their annual beta tests.

In many cases our new pricing model will result in reduced prices, with our fully Managed Beta Tests now starting at $6,000, along with a new special $3,000 Managed Mobile Beta package.

Severity & ROI Estimates

Determining the ROI of a beta test can be a difficult task. For one, an effective beta touches and improves nearly every aspect of your product; from more effective sales and marketing messaging, to direct quality improvements, to better support preparation. Altogether these improvements lead to better reviews, higher sales, higher customer retention, fewer returns, and lower support costs (i.e. “why we exist!”). That said, we feel that it’s very important that we directly illustrate the impact our Managed Betas have.

To accomplish this, we chose to focus on defects, which are central to nearly all of the betas that we run — and valuable to everyone. We’re inserting a new step in the planning phase of each beta project, in which we’ll present you with a list of defect severities (from cosmetic to critical), each with an objective definition. You’ll have the option to adjust these descriptions to better match your product, and then also assign a monetary value to each of these types of bugs. In other words, what is a unique critical bug worth to you, if it slips through?

Next, we’ve expanded our feedback filtering routine (one of our standard Managed Beta services) to include Severity Tagging. So, beyond filtering duplicates and ensuring clarity (our current process), we’ll also adjust the severity for each bug to match the definitions included in your beta plan. As a positive side effect, this will also provide additional context for each bug, helping you further prioritize your efforts.

At the end of your beta, we’ll include the result of this (your bugs [by severity] * value [by severity]) in your case study (more on that below) as a simple ROI estimate for the project. This value isn’t intended to provide a total or precise ROI indicator for your beta, but it will serve as a basis to estimate its impact, from which you can adjust to meet your own ideals.

Weekly Status Reports

Similar to ROI, another challenge in our Managed Beta business is to quantify the total time savings our Managed Betas deliver, versus doing it yourself. We believe that this is actually our own fault, by design. Our goal in delivering Managed Betas has always been to absolutely minimize the time investment and effort required by our clients. In other words, you’re hiring us to run a beta not only for our expertise, but also so someone else (“us”) is doing the heavy lifting. The problem with this model is that as a result, you don’t see that heavy lifting, as we’ve gone out of our way to hide it.

In 2013 we have two solutions for this. The first has already been mentioned — our new beta plans more clearly demonstrate just how much work we’ll be doing, that you don’t have to. Our new Weekly Status Reports are the second. Each week we’ll be delivering a standard Status Report which outlines key details about your project, including the state of the severity of all bugs. Note that this is in addition to your ability to ask for whatever data you want, in real-time.

The second goal of our Weekly Status Reports is to provide you with a consistent means to measure the progress of your beta test, which will help you make better decisions in regard to pivoting, extending, etc. — again, ensuring your betas have the biggest possible impact and ROI.

Standardized Final Tester Surveys

Surveys are a common tool used in most of our betas. In the past we’ve helped you develop these surveys, or you’ve provided them exactly as you’d like posted. While these options are both still available, we’re also going to be running a single standard survey at the end of every project we manage.

This is a short beta-product-focused survey that we’ve developed as a benchmark to help understand how your product compares to others at the conclusion of beta, in the eyes of its customers. It covers customer satisfaction, quality perception, and NPS (Net Promoter Score).

Mini Case Study (Internal)

In the past our Final Report has been our ultimate deliverable, offering an extended overview of your project. While you’ll likely find great value in the details, your peers and executives would probably appreciate a simple high-level synopsis. To address this request, we’ve created a simple one-page case study template, which we’ll complete and provide at the end of each beta test. This case study is for your internal use only (i.e. we won’t be sharing it with anyone), and you’re encouraged to share it with your executive team and peers.

Our goal is that this will help you summarize and justify your investment in us, and of course if they like what they see, we’d always appreciate a reference. (:

Tester Incentives by Centercode

Our last change is an improvement to the way participation rewards are handled for our testers. Traditionally beta incentives are built into each project deal. We prefer that testers keep the products (as they often grow attached to them), but quite often other rewards are provided.

While we’re still keeping this system in place, we’re also strengthening it with an addition of our own. While your own incentives will reward the testers who’ve met the participation requirements of the project, Centercode will be providing an additional higher tier for those who went above and beyond.

There are two reasons for this change. First, we feel it’s always important to reward our testers, and given their relationship with us we want to go out of our way to clearly thank the rockstars in each project. Second, we feel this additional tier will stimulate tester engagement even more, providing you with better results — thus adding more value to every beta test we run.

The Whole Process

As part of our recent web refresh, we’ve created a new page which outlines our entire Managed Beta process, including all of these changes. This offers our customers and prospects a clear and detailed overview of exactly what they should expect in working with Centercode.

More Still to Come

This concludes my second tome on our 2013 changes. Thanks for reading! In the coming days I’ll be addressing a couple of items not detailed here, including our new Mobile Managed Beta offering, and our improved Beta Program offering. Stay tuned!

Request your free beta test plan now.

image courtesy of Flickr user Thomas Hawk.