Now that Autodesk Labs and Autodesk Beta are both hosted on the Autodesk Feedback Community platform, I thought it would be a good idea to reiterate some of that information that I shared at our first annual North American Autodesk Expert Elite Summit in San Francisco. The Expert Elite program recognizes community members who make extraordinary contributions to our online and social communities. Members of the Expert Elite group are characterized by their regular and responsive participation in Autodesk’s discussion forums and social channels and advanced knowledge of company and our products.
Autodesk Labs is wide open to the public. Anyone can participate. Labs technology previews have a start and end date. Having a fixed interval gives teams a window where they can get feedback, make a decision, and move to the next development effort. There are also Financial Accounting Standards Board (FASB) rules that prevent Autodesk from providing perpetual functionality outside of the Subscription program. So each technology preview has a built-in time-bomb. When the time-bomb causes the functionality to expire, the team considers what to do as its next step. This could be holding another technology preview to get more feedback, retiring the technology for now, or making a non-expiring version available in the App Exchange or Subscription Center. Which of the 3 possible steps they take depends on the feedback they have received.
Unlike technology previews that are open to the public, generally users are invited to Autodesk Beta under confidentiality agreements. It's like Fight Club. The number one rule about Autodesk Betas is that you don't talk about Autodesk Betas [outside the confines of the Autodesk Feedback Community]. For beta, it's an iterative improvement process until a product is ready to ship. Teams post a build. Team get feedback. They make updates. They post a new build. The process repeats until there are no more changes to be made. The bar for deciding to "fix a defect" versus "defer it to a later release" raises as the release target date nears. This happens because anytime a team fixes something, they run the risk of breaking something else (see example). With your cooperation (thank you), teams want to mitigate that. As such, each defect resolution contains a proposed set of changes that gets reviewed as part of a bug fixing process. Fixes that are too risky, even though valuable to customers, get deferred to a later service pack or future release. The overall quality of the release is more important than any one defect correction. The fix/defer decision is made on a case by case basis at daily bug scrub meetings that have marketing, product management, software development, and quality assurance in attendance. It is truly a team effort.
The iterative Beta process is unlike the Labs process which is more of a one-shot "let's see what we need to do next" process; however, both rely on customer feedback. That's where you come in. Between Labs and Beta. thanks to your expertise:
- Teams don't waste time and money on technologies you don't care about.
- Teams release higher quality products that handle real world data that they couldn't test without you.
The up side on defect correction is that the bar raises as the release date nears, so the earlier a defect is identified, the better chance it has of being corrected. That's why early participation in Beta programs is key. That's why participation in Labs technology previews is key — sooner is better than later. If the very idea of a technology is off the mark, let us know during the preview stage, so the team can focus its efforts on something else.
A process comparison is once again alive in the lab.