On May 8 and 9, Autodesk hosted 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 the company and our products.
As part of the summit, I gave a presentation on Autodesk Labs and the Autodesk Beta program. You can download my PowerPoint slides.
Today I thought I would cull one slide, the process slide, and cover that.
Autodesk Labs
Autodesk Labs is wide open to the public. 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 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 Center or Subscription Center. Which step they take depends on the feedback they have received.
Autodesk Beta
Users are invited to Autodesk Beta under nondisclosure agreements. 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.
A process comparison is alive in the lab.