The first step to take when attempting to induce change through learning selection is to produce a “plausible promise,” or something that convinces potential stakeholders that the new technology can evolve into a tool or process that they really want. Experience shows that it is difficult to enlist co-developers if the whole project is abstract. Mokyr (1990: 9) believes that the process of inventing plausible promises is by its nature something that " ... occurs at the level of the individual." He says that creating a plausible promise is " ... an attack by an individual on a constraint that everyone else has taken for granted." It is not something that lends itself to a broad consensus approach. Therefore, creating a plausible promise is often about doing excellent, groundbreaking science that produces something that at least a few innovators in the target group might find useful.

The plausible promise does not need to be refined or polished; it can be imperfect and incomplete. In fact, the less final it is, the more scope there is for the stakeholders to innovate and thus gain ownership of the technology. The more problems there are, then the greater the chances that the key stakeholders will give up in frustration. A delicate balance must be maintained.

The next step is to identify the innovation or product champion. He or she needs to be highly motivated and have the knowledge and resources to solve problems. Someone from the R&D team is likely to be suitable, because he or she will probably have both the necessary technical knowledge and the motivation; it always helps if the product champion already has a stake in the technology. He or she must also have good people and communication skills because, to build a development community, it will be necessary to attract people, interest them in what is going on, and keep them happy working for the common cause. The product champion's personality is therefore crucial.

Don't attempt to dazzle people with the cleverness and ingenuity of the prototype's design. A plausible promise should be simple, flexible enough to allow for revision, and robust enough to work well even when not perfect. The critical comments of your colleagues don't matter. Your potential co-developers' needs and knowledge levels do. For example, if you are designing a combine harvester and you know the manufacturers and farmers you'll be working with are familiar with a certain type of thresher, then use that in your design, even if it is technically not the most elegant solution. As John Gall (http://www.quoteland.com/qldb/author/59) said, "A complex system that works is invariably found to have evolved from a simple system that worked."

Allow the participants in your learning selection process to select themselves based on the amount of resources they are prepared to commit. Advertise or write about your plausible promise in the media, do field demonstrations, or post on the Internet and wait for people to contact you. Don't give inquirers anything with a resale value for free. For example, if your prototype has an engine, then charge the market value for it. Otherwise, people may be motivated to adopt it to get something for nothing. In addition, people generally value something more highly if they have paid for it, and they will be more committed to sorting out the problems that emerge.

On the other hand, you must make it clear to the first adopters that they are adopting an imperfect product and that they are working with you as co-developers. You need to reassure them that you will be contributing your own resources to the project and will not abandon them with a lemon. You should be prepared to offset some, but not all, of the risk they are taking in working with you. Getting the balance right is very important here, too.

Your co-developers will be influenced by their environment. Their motivation levels will be sustained for a longer period if they live or operate in an environment where your innovation promises to provide great benefits. In addition, they are more likely to receive encouraging feedback from members of their own communities.

a) The product champion/selector.

As soon as you have the key stakeholders working with you and generating novelties, you need ways of selecting and promulgating beneficial changes. Initially, the product champion usually plays this role. An effective selector must be able and prepared to recognize good design ideas from others. This means that, when this person is also the inventor, he or she must be suitably receptive and thus able to accept that others might have better ideas.

Very few people are capable of effectively championing their products and selecting novelties at the same time. This is because, to be good at the former, it is necessary to believe deeply in the product's benefits and be able to defend it against criticism. An effective selector, on the other hand, must keep an open mind and be able to work with others to question fundamental design decisions.

If a product champion defends the technology too strongly or shows bias, then "forking" occurs, and the disaffected person or group branches off to do what he or they felt prevented from doing by the selector. It is good to have people test alternative design paths, but, if it is done in frustration or spite, then cliques form, making any comparison and subsequent selection between rival branches difficult. Creative talent is split, and energies can be dissipated in turf wars.

b) Alternative selection mechanisms.

Even if the product champion can be open-minded and unbiased, he or she may have problems convincing others. One option is to set up a review mechanism that is well respected by the key stakeholder community. There are a number of ways of doing this. Three that work are review by an independent organization, peer review, and the provision of enough information to potential adaptors that they can make informed selection decisions themselves.

For the innovation to evolve satisfactorily, the changes the stakeholders make to it need to be beneficial, and, because those generating the novelties will have gaps in their knowledge, product champions should restrict the number of co-developers so that they can work with them more effectively. When people show enthusiasm for a prototype, it is very tempting to release it as widely as possible, but this should be resisted. The technology will always be less perfect than the inventor initially thinks.

However promising the technology might appear to be, there are many things that can and will go wrong. First adopters need to be aware of this and have ready access to the product champion. Otherwise, their enthusiasm will quickly turn to frustration, and the product champion will end up defending the technology against criticisms when the problems appear. Once the product champion becomes defensive, he or she will be far less useful at solving problems.

In learning selection, people cooperate with each other because they believe that all will gain if they do. The process is, therefore, seriously damaged if one person or group tries to gain intellectual property rights over what is emerging. First, the community spirit is damaged. Second, patents are monopolies that immediately reduce the novelty generation rate and thus slow down future development and the flow of ideas.

The Tanzania bean example given in the text shows just how much difference local culture can make. The negative impact of women being dispossessed from their land would not have happened in a culture that gives women stronger rights to property. Culture can also influence the degree to which knowledge is guarded within a particular group, or spread around. Learning selection is going to be greatly impeded in cultures where new knowledge is carefully guarded, either by keeping it secret or taking out and enforcing intellectual property rights.

Product champions need to become personally involved and emotionally attached to their projects to do their jobs properly. However, this makes it easy for them to go on flogging dead horses long after it has become clear to everyone else that the technology is not going to succeed. Equally, project champions can continue trying to nurture their babies long after they have grown up and market selection has begun. It is, therefore, a good idea to put a time limit on the product champion's activities.