Finally, the word is getting out the beta (in it’s Web 2.0 form) is dying.
Ugh, finally. It’s about time.
I’ve wanted these thing to die for a long time. It’s turned in to a complete excuse to churn out crap and it really serves no purpose the way it exists in software today.
Beta programs can be well-run. For example, Microsoft has continued to run well-executed betas. They actually serve a purpose; their PMs would outline goals they want to accomplish, identify a test set based on their recognized segments for the product, etc, etc…
There can be a lot of moving parts to a successful beta. Augmenting your logo and slapping up a crappy product somewhere with the promise to iterate on it is not the way to go.
Iterating is necessary. And knowing how to iterate quickly is an absolute requirement, especially with Web-based products.
It all depends on your product strategy and how you wish to execute.
But let’s get the word out – a beta for the sake of wordmarking a logo needs to die. And proper, formulated betas need to be brought back in to the fold again.
I could post on and on about this – but I have seem to be generating some good conversations lately – and there are more product managers out there that are much smarter than me, so what say you?
{ 9 comments… read them below or add one }
I agree. Beta became the alternative to delaying the release. We can ship this with a beta label and then we are covered when people find the bugs we know are there. A beta program is suppose to be a program that makes a pre-release version of the software available to a subset of customers (not all!) to find the bugs we don't know are there. For Product Managers, I think it is important to remember that first impressions are impossible to get back.
I agree. Beta became the alternative to delaying the release. We can ship this with a beta label and then we are covered when people find the bugs we know are there. A beta program is suppose to be a program that makes a pre-release version of the software available to a subset of customers (not all!) to find the bugs we don't know are there. For Product Managers, I think it is important to remember that first impressions are impossible to get back.
I couldn't agree with you more. If there is not goal or purpose to the beta then it shouldn't exist. I liked Fried's comment that betas are often used as an excuse to publish unplanned or undesirable software and “it’s confusing and generally sends a bad message to call something beta in public.†Worse than that I recently worked with a development team who insisted on releasing a product as a “beta” simply because they were unsure of the quality of the product and felt the “beta” tag lowered quality expectations in the minds of the customers. Trying to trick your customers in that way, in my mind, is just plain wrong.
I couldn't agree with you more. If there is not goal or purpose to the beta then it shouldn't exist. I liked Fried's comment that betas are often used as an excuse to publish unplanned or undesirable software and “it’s confusing and generally sends a bad message to call something beta in public.†Worse than that I recently worked with a development team who insisted on releasing a product as a “beta” simply because they were unsure of the quality of the product and felt the “beta” tag lowered quality expectations in the minds of the customers. Trying to trick your customers in that way, in my mind, is just plain wrong.
Exactly.
I've come in to companies before and one of the first things I look to do is
remove “beta” labels – unless there is a reason. If the only reason is “it's
not done yet,” which it is more often than not, guess what's going out the
door the next release?
v1.0.
Exactly.
I've come in to companies before and one of the first things I look to do is
remove “beta” labels – unless there is a reason. If the only reason is “it's
not done yet,” which it is more often than not, guess what's going out the
door the next release?
v1.0.
I think very few traditional software manufacturers do wide-release open betas correctly or well (two different things). One reason? They have no idea how much the software is being used by users, what modules are being used, whether those modules work as expected, etc. So these betas turn a sort of “work release program” for under-baked software.
Is it because instrumenting the software is hard? Because it kills performance? Because it can't be done comprehensively? Because the software hasn't been built in a way that would allow for utilization reporting at a system/sub-system level?
You can't manage what you can't measure. Web 2.0 has it easy – web-hosted apps throw off more data than cats throw off fleas. So-called “traditional” software (whether commercial or not) isn't so lucky.
There has to be a solution out there for this – someone has to have figured out how to make it easy to get software to throw off data that can actually be used for good, instead of just landing in a pile.
I think very few traditional software manufacturers do wide-release open betas correctly or well (two different things). One reason? They have no idea how much the software is being used by users, what modules are being used, whether those modules work as expected, etc. So these betas turn a sort of “work release program” for under-baked software.
Is it because instrumenting the software is hard? Because it kills performance? Because it can't be done comprehensively? Because the software hasn't been built in a way that would allow for utilization reporting at a system/sub-system level?
You can't manage what you can't measure. Web 2.0 has it easy – web-hosted apps throw off more data than cats throw off fleas. So-called “traditional” software (whether commercial or not) isn't so lucky.
There has to be a solution out there for this – someone has to have figured out how to make it easy to get software to throw off data that can actually be used for good, instead of just landing in a pile.
I think very few traditional software manufacturers do wide-release open betas correctly or well (two different things). One reason? They have no idea how much the software is being used by users, what modules are being used, whether those modules work as expected, etc. So these betas turn a sort of “work release program” for under-baked software.
Is it because instrumenting the software is hard? Because it kills performance? Because it can't be done comprehensively? Because the software hasn't been built in a way that would allow for utilization reporting at a system/sub-system level?
You can't manage what you can't measure. Web 2.0 has it easy – web-hosted apps throw off more data than cats throw off fleas. So-called “traditional” software (whether commercial or not) isn't so lucky.
There has to be a solution out there for this – someone has to have figured out how to make it easy to get software to throw off data that can actually be used for good, instead of just landing in a pile.
{ 1 trackback }