Early adopter programs (EAPs) deliver several valuable opportunities that make EAPs an important ISV path to success with Microsoft. You can use EAP participation to:

• Create and maintain technical and market leadership
• Drive innovation by building on/exploiting new MS features and technologies
• Gain visibility with customers, investors, etc. by tapping MS’ marketing machine
• Gain influence over future MS product releases, APIs, etc.
• Drive revenue by engaging MS field sales to help sell your product

EAPs are invitation-only and you’re competing with other ISVs for a limited number of slots, sometimes just a couple dozen, so it’s helpful to understand MS’ motivation – why they bother with EAPs in the first place, and what they expect from the ISV partners that participate in EAPs.

Disclaimer: early adopter programs vary widely across MS – the requirements of participants, the benefits offered, what they’re called (EAP, TAP, Metro, First Wave), etc. There are also different programs at different stages in the product release cycle, run by different parts of MS, targeting different numbers and types of partners or customers.

This post focuses on early adopter programs run by the MS product team and the technical evangelists working with that product team, engaging partners 12-24 months before RTM, with participants selected primarily by the product team and evangelists, based on the participants’ proven expertise with that product and related technologies.

Why Microsoft Runs Early Adopter Programs

You’ll often hear MS refer to “a rich partner ecosystem” – that’s MS-speak for the vast array of partners that invest around MS products and deliver additional capabilities, services, etc., that are not available from MS. The richer the ecosystem, the more likely MS will have a partner that can deliver whatever capability a customer wants.

When MS puts out a new product release, they want customers to start buying it right away. Customers, however, are reluctant to deploy a new product release the moment it’s available. They’ve learned they’ll have an easier time if they wait for the first service pack (“SP1”) to fix the most annoying problems in the original release. MS can influence this perception, but they’ll have to ship many rock-solid, bug-free releases before they’ll change this customer belief and behavior.

Customers also delay deploying new releases because they’ve tapped that rich partner ecosystem and become reliant on add-on products from ISV partners that deliver important additional capabilities; and until those add-on products support the new MS release, the customer delays deployment.

This is something MS can control; indirectly. They know which ISVs’ products are widely used and will become “deployment blockers” if they are not updated promptly to support the new MS product release. MS can accelerate when those ISV updates are available through … early adopter programs.

Long experience has proven that when planned and executed correctly, MS EAPs result in a high percentage of participants delivering updates that support the new MS product release, shortly after MS releases it.

Microsoft’s Goals for EAPs

MS has several goals for EAPs:

• Early support by partners for new MS releases
• Partners and customers to showcase at various stages in the release cycle
• Pre-release testing of product features, APIs, documentation, etc.
• Expert technical feedback prior to RTM

Delivering support by key ISV partners shortly after the new MS product release is the key result MS expects from EAPs, for reasons discussed earlier. A close second place is “customer evidence”, a collection of whitepapers, case studies, video interviews, etc., which showcase the experiences of actual customers using early builds of the new MS product release prior to RTM. This “customer evidence” is widely distributed within MS and, when customers allow, published on the MS product web site.

MS achieves its technical goals – pre-release testing and technical feedback – through direct interaction with the partners participating in the EAP; more on that below.

How ISVs Join an Early Adopter Program

With a limited number of EAP slots available, MS must be selective in which ISVs they invite to participate. Without question, the most important criteria is that you must support the latest release of the MS platform, and take advantage of the MS platform’s features appropriately. If your product supports only a “down-level release” like Windows Vista or Windows XP, or does not use relevant technology, like HTML5 and CSS for browser-based applications, you stand virtually no chance of being selected.

A contact at MS that works with ISVs put it very clearly:

“You can’t just call [MS] up and say – Can you put us on a list so that your biggest and best customers will use us? – without having shown your willingness to get in and build apps on the platform!”

Next, you need to be known to the people who decide which ISVs will be invited. For most ISVs that will be your technical evangelist – if you aren’t working with an evangelist, see my earlier post, Technical Evangelist – An ISV’s Best Friend, and How To Find Yours. You need your evangelist to:

• Be explicitly aware you want to participate in the EAP
• Be aware of specific, cool things you’ve done in your product, with the current MS release
• Understand your company and product messaging
• Understand your target market, and who some of your key customers are

All of these could be tagged “make it easy for your evangelist to choose you”, since your evangelist will need to know these things to convince the other MS folks involved in choosing ISVs that you should be invited.

The EAP Agreement

Each EAP has some kind of agreement which details the “gives and gets”, what you’re committing to do, and what MS is committing to do. (The agreement and its specific terms are confidential, subject to the terms of your NDA with MS. In this post I’m speaking generally, and carefully abiding by my past NDAs.)

You’ll typically commit to:

• Develop a version of your product that uses one or more specific features, APIs or technologies from the new MS product release, selected from a list that MS provides.
• Release that product shortly after the MS product RTMs, typically in the range of 30-90 days after RTM.
• Travel to MS several times for hands-on technical events specific to the EAP, at your own expense.
• Promptly install each MS product build you’re provided, test your product on it, and file bug reports for any problems you encounter.
• Maintain regular communications with your MS contact to provide your feedback on the new MS release, and keep your contact informed of the status of your work (e.g., “green” = on track, “yellow” = some issues but under control, “red” = dead in the water, need help!).
• Commit sufficient staff to fulfill these commitments.

Think about this from MS’ perspective. MS is inviting you to fill one of a very limited number of slots for ISVs in the EAP; they want to be sure you’re clear about what’s expected of you, and that you’re committed to following through. Despite the best of intentions, stuff happens and sometimes partners cannot fulfill their commitments – new leadership wants to take your company in a different direction, your company is acquired, etc. In situations like that, keep your contact well informed and there’s typically little fallout from failing to fulfill your commitments. Stuff happens.

If you lose interest or simply fail to deliver on your commitments, watch out – although there’s rarely any direct consequence, you probably won’t be invited to another EAP for a long time. You wasted the valuable spot in this EAP and that’s something the MS folks won’t soon forget.

The most effective way MS can ensure your product update is ready near the MS RTM is by having members of the MS product team work with you, face-to-face. When you attend the EAP events at MS, any member of the product team can be brought into the conversation, explain things and/or look at your code, help you overcome any obstacles you encounter, or file a bug report against the MS product on-the-spot. These events go by a variety of names – “dev lab”, “developer kitchen”, etc.

Your presence at these EAP technical events is seen by MS as the primary indicator of your dedication to delivering on your EAP commitments. It will be virtually impossible for you to successfully complete the work you’ve committed to, without attending these events. Failing to attend sends a very strong signal to MS that you’re not serious about your EAP commitments, and that means MS wasted a valuable slot in this EAP.

The MS technical evangelists and product team are expected to report on how you and other EAP partners are progressing, so keep those communication lines open.

MS will typically commit to:

• Provide training on the new MS product release
• Provide a series of early builds of the new MS product release
• Providing a technical contact to work with you
• Invite you to EAP technical events (the same events you committed to attend)
• Invite you to participate in various press, publicity and marketing activities

Your technical contact will typically be a technical evangelist or program manager from the product team that’s focused on ISV partners. That contact will review your plans and architecture/implementation, ask for your feedback, pursue resolution of problems you encounter, champion your suggestions for change to the product team, etc.

Some EAP marketing activities may be mandatory, i.e., when you sign the EAP agreement you’re agreeing in advance that your company will participate in specific activities. Providing your company logo for MS to include in the “partner logo slide” is a typical example.

Occasionally MS makes customer evidence a high-priority deliverable from the EAP, and the EAP agreement will require you to commit to cooperate in developing that evidence. This protects MS from reaching the end of the EAP only to discover participants have decided not to cooperate in developing that customer evidence. Note that MS wants to detail your customers’ experience with early builds of the new MS product release, not your experience as an ISV; in which case you’d need to line up one of your customers that’s willing to join the EAP with you, to qualify for an EAP like that.

MS may also list a variety of benefits that you may qualify for but are not guaranteed, e.g., your product may be considered for demonstration during the keynote of the MS product launch event. You’ll be competing with other EAP participants for those benefits, and MS will decide which partner and product will be included; or that no partner product will be demo’d.

For online services like Windows Azure or Office 365, instead of receiving product builds to install yourself, you’ll typically receive credentials that give you access to a private area on the service where MS has deployed early builds of the next service release. Periodicially MS will deploy new builds of the service, which you’ll continue to work with.

What to Expect During the EAP

The focus of the MS early adopter program changes over the course of the EAP. Initially MS is focused on educating you on the features and APIs of the new MS release and best practices for using them (i.e., how MS anticipated you’d use them), answering questions, and providing feedback as you make plans for how your new product release will use those features and APIs.

During development, you’ll run into a wide variety of problems – things that doesn’t work as documented, things that aren’t documented at all, things that are documented but not yet implemented, disconnects between how you intend to use features and how MS thought you’d use them, etc. This is the central experience during an EAP – stuff doesn’t work. Deal with it! If everything worked, the EAP would be over and MS would have ship the product.

MS seeks feedback from EAP participants, and MS values this feedback very highly. Imagine if MS shipped a new product release and ISVs didn’t support it, because it didn’t deliver the features and APIs ISVs needed; that would be a disaster. EAP participants send very smart people to the EAP events, people who set the future direction of their company’s products, and if several of those people don’t like what they see or have recommendations for improvements, that’s taken very seriously by MS product teams. MS counts on EAP participants to validate (or challenge, as appropriate) their product plans and implementation, to ensure MS ships “the right product”.

When MS provides an public preview release, whether called a “Community Technology Preview” intended for developers or a “Community Preview” intended for power users, the EAP team typically invites EAP participants with the most compelling stories to provide quotes for MS press releases (MS will provide quotes for your press releases as well), participate in demos, etc. These are the early stages of “rolling thunder”, the ever-increasing decibel level of marketing activities leading up to the MS release and launch. MS wants to demonstrate to customers and industry pundits that their partners – that’s you! – are onboard with early support for the new MS product release.

As the MS product approaches RTM, the MS product team is increasingly reluctant to make changes, and builds are put into escrow as Release Candidates. RC builds could become the RTM build, if they do not have any “ship-stopper” bugs. As MS cycles through a series of RC builds, you’ll be asked to quickly re-test your product on each RC build, and let your EAP contact know whether your product is ready to ship if that build is named the RTM build. After a few RCs, a build will be Released To Manufacturing (RTM), and for many MS products that milestone will be widely reported across the tech industry.

At RTM, you’ll make a last test pass, fix any of your own “ship-stopper” bugs, and release your product; so the MS RTM marks the beginning of the end for the technical work associated with the EAP.

The marketing team, however, kicks into high gear as RTM approaches – finalizing your own marketing materials, data sheets, case studies, product demos, etc., as well as your participation in MS’ marketing materials, case studies, launch events, press and analyst activities, etc. You may spend several months involved in MS marketing activities, depending on the extent of MS’ efforts around their product release.

This is your best opportunity to get MS to publish case studies, etc., about your customers using your product, and the value your products deliver. Once published on the MS site, these materials typically stay there for years, influencing thousands of potential customers.

After the EAP

EAPs typically end 60-90 days after RTM – there are no more builds, and if you’ve kept up, your product was ready to release with support for the new MS product release shortly after RTM. The EAP marketing activities will run through the MS product launch, and perhaps several weeks or months beyond. YMMV.

But there’s always a “next release”, and the EAP for that release – so finish strong, and set the stage for your participation in the next EAP.

Make sure your EAP contact and technical evangelist – the people who will once again choose which ISVs participate in the next EAP – are aware of specifically how your product uses the new features and APIs from the new MS product release, your interest in participating in the next EAP, and your thoughts on what should be included in the next MS release. Chances are MS did not give you every features and APIs you wished for in the just-RTM’d release, so you’ll likely have some specific suggestions to offer.

Windows 8 just RTM’d, Can I Still Join The EAP?

The EAP for Windows 8 has been closed to new participants for many months, perhaps a year. But there’s always another release coming – MS is already at work on “Windows v.Next”, and the EAP for the next Windows release will typically start 9-12 months after the previous release RTMs. MS is also already working on Windows 8 SP1, and the EAP for that will typicaly start in 3 months or so.

Take the steps described above under How ISVs Join an Early Adopter Program – do the work to qualify for the EAP (e.g., do something interesting with the newly-RTM’d Windows 8), let your evangelist know you’re interested in the EAPs for Windows 8 SP1 and “Windows v.Next”, etc.

Engaging the Microsoft Field

Your work in the EAP and with the MS product team will not automatically lead to opportunities to engage with the MS field (or that would be listed as a benefit MS provides, in the EAP agreement), but that work is a valuable stepping stone to engaging the MS field.

Your evangelist is once again your key contact – he/she can help you prepare materials targeting other evangelists, most of whom work out of MS sales offices around the world. Through these connections you can work to build further engagement with the MS field, but that’s a topic for another post.

Next Steps

In my next post, we’ll take a deep dive into how ISVs can achieve compelling results through EAP participation.

This post is part of my “ISV Paths to Success” series:

• ISV Paths to Success with Microsoft
• ISV Paths to Success – Early Adopter Programs (this post)
• Deep Dive for ISVs – Early Adopter Programs
• ISV Paths to Success – Microsoft Partner Network
• Deep Dive for ISVs – Microsoft Partner Network
• You Have Questions, I (May) Have Answers