Technology Adoption Programs (TAPs) are intended to serve one (or both) of the following purposes:
1. Product Validation—Customers provide technical feedback, feature validation, and bug identification for a pre-release product so that engineering can improve the product before release.
2. Early Adoption—Customers partner with product marketing to adopt the new technology and share their experiences publicly in support of the product launch.
Over the past five years I have noticed a trend whereby TAPs have continually gotten larger. To me this indicates how crucial TAPs are to the launch of a new technology, and how very successful they have been. So the natural inclination is to take something that is going well and pour more resources into it for a bigger return. However, TAPs are meant to be “high touch” and scaling them larger can jeopardize the ability to provide a certain level of engagement to participants.
For this posting I would like to focus on the second purpose mentioned above (Early Adoption). I am sure you’re on the edge of your seat wondering, but when is he going to share his thoughts on Product Validation programs? You will just have to check back at a later date. Always leave them wanting more.
Great Expectations:
A challenge for a company releasing a new product is objectivity. There are always so many great reasons why customers should and will want to adopt your new product, but we have to separate what we know about the product and put ourselves in the customer’s shoes to answer the question “what business need is this technology addressing?” If that question can’t be answered during the course of a pilot or proof of concept, then true technology adoption is not in the immediate future for that customer.
So, the first thing I would say to a company looking to run a TAP is to set realistic expectations on what the immediate uptake of the product will be. There is a sweet spot in figuring out how much and how soon. Gone are the days where customers adopt new technology for the sake of new technology. More and more companies are hesitant to be on the leading edge, mainly because complex IT environments often prohibit them from quickly adopting a technology. The real challenge for a successful TAP is to find those few that will be able to adopt (and experience benefits) quickly. TAPs are a partnership between a company and its customers. There needs to be open communication during the recruiting stage to make sure customers know what is expected of them, and to confirm that they intend to meet this expectation to the best of their abilities.
The key to a successful TAP is not purely on how many customers you have in the program or how big the customers are. Rather, it is finding the right customers that are comfortable being on the leading edge and are happy to discuss it. The lure of a large, brand name company interested in participating in a TAP is hard to resist but your decision to accept them into your program needs to be based on their ability to deliver against program requirements and not whether they are a Fortune 100 company that may or may not deliver on the requirements. This is most apparent when PR and customer reference activities are a key requirement of the program.
Is Bigger Better?
So, if some customers aren’t set up for a successful outcome should we just pile on more and see what sticks? Remember, one of the benefits to a customer participating is the “high touch” value they receive—without this, they might as well just enroll in a public beta to evaluate the product. Also, depending on resources you are making available to participants just piling on more customers is potentially a costly and inefficient solution.
What the heck are we supposed to do now? Well, remember when I talked about realistic expectations? I hope so because it was only a couple paragraphs ago. Make sure you spend enough time in the recruitment phase to screen nominations or invitations and don’t be afraid to ask for clarification/verification before accepting a customer. That should help to eliminate some of the customers that aren’t set up to provide a successful outcome. Also, you will have to identify your program’s success metrics and prioritize them. Is your primary goal based on the number of customer references or PR wins? The number of units deployed? You’re probably going to answer “both”—I knew it! If so, consider two phases to your TAP where the first phase is smaller and designed for PR purposes and building strategic customer references for launch. The second phase wouldn’t really start until the product releases and is geared towards moving units. Different customers can be slotted into one phase or the other based on realistic expectations of what they can deliver. This in turn helps you maximize ROI on your program resources. And, if you can answer what business need the technology is addressing you are headed towards success on both fronts.
That brings us to the importance of business value in a TAP. But that is another topic for another day.
For more information about TAP:
IBM Technology Adoption Program, Microsoft Windows Server MSDN Blog
Check out our TAP project:
Windows Vista Technology Adoption Program for Rapid Deployment, 2007 Microsoft Office TAP RD