Product Development: Getting Customers In on the Act

This week, Sage Software is bringing out version 11 of ACT, its high-flying contact management software. ACT has been around since the mid-1980s and has been through multiple incarnations and owners in that time. ACT was what you used back then if you were tired of keeping notes on paper and wanted to improve the way you sell. I can remember a DOS (disk operating system) version of the product that would look almost alien in comparison to today’s slick GUI (graphical user interface) version.

At any rate, Sage is still doing good business with ACT for people who either don’t want or don’t need full SFA (sales force automation) — I have a hard time distinguishing the two — with about 2.5 million licensed users and more than 30,000 corporate accounts. I was drawn to ACT again the other day when I discovered that Sage had engaged in some very 2.0 approaches in its beta program for the new release. My ears stood up when I heard that Sage had taken a community-based route in the beta, and the story is so interesting I thought I would share it.

Slow Process

The other day, I spoke with David van Toor, senior vice president and general manager for Sage CRM Solutions North America, to find out what was going on. Van Toor is a big advocate of applying CRM 2.0 techniques — sort of drinking the Kool Aid — and this community is a great example of why.

According to van Toor, the traditional ACT beta process involved getting customers to agree to test the product and report issues, complete with reports to the company, some cogitation to fix a problem and a response to the customer. It sounds tedious, and it was. Van Toor told me the process for reporting and resolution took about two weeks, and the approach lacked any broader discussion among the participants. For example, what if two or a dozen people all saw the same problem or encountered something slightly different? How would information about the problem and its differences be communicated and remedied?

In practice, it all needed to funnel down to the company, and the architecture of the process made the whole procedure difficult. This time van Toor approached his existing community with a simple question: Who would like to participate in the beta in exchange for a free license when it was all over?

Seeking Motivated Testers

By approaching an existing community, van Toor thought that he would be dealing with people who had more passion for the product than any random sample, and he was right. Through the community, he was able to over-subscribe the beta group — he got 160 percent of his goal — and everyone involved was clearly motivated.

The beta community had several advantages over a traditional beta group as well as some over a conventional community where people randomly submit suggestions for improvements. The ACT group was given specific assignments, things to test, and they were able to share their ideas not only with Sage but with each other.

That was the key to success — everyone was active and everyone participated in specific activities. It’s nice to give people a suggestion box and to take suggestions, but that’s customer service, not product development, and you shouldn’t get the two confused. While product suggestions might be valuable, they won’t help you figure out something new. To do that you need to get people interacting and working for a joint purpose.

‘A Richer Process’

The results were manifold. As a whole, the group generated more and richer raw information about the product and what was being tested, but it also enabled all the ideas to percolate among members. The development team used this information, which enabled it to turn around fixes and changes in a couple of days rather than a couple of weeks.

The process had it skeptics, of course, but they have been largely turned into advocates. The development team was wary of the change away from what they were accustomed to, and the initial thinking was to run the community in parallel with a conventional approach. However, the community was so successful that, as van Toor put it, “They (the development group) were ecstatic,” and the two approaches merged.

The company had planned to take the same six weeks for the beta that it always has, but the combination of more people being actively involved and the quantity and quality of information that came out of the community made it likely that in the future shorter betas would be possible.

Was the community a success? Van Toor thinks so. “We had a richer process, and the product is better because of it,” he said. The real proof will be visible for everyone to see. The company will be posting a read-only site with comments from the actual participants. If details matter, the people who made the beta work have plenty of them.