CustomerInsideTranscript

Some notes about the case are included, as participants asked for clarification. The results are, however, wider applicable. Participants shared their own experience of similar situations.

The subject chosen from the focal topics is "How to handle the conflicting wishes of multiple customers?"

CAUSES

• Customers place different business value on functionalities. Even if they had the same wishes, they would prioritize them differently.
• The mix is the problem, combining projects into product development
• Note: customers are not competing in this case, so they could talk. It would be a good thing if costs are spared by implementing things for different customers only once.
• Idea: do the first iterations separate for each project. Later on combine them into a product.
• So more resources are needed. But that leads to problem: on long term you have to pay for resources, so as projects finish you have to find new ones.
• Maybe you have some bad customers, not explaining good enough what they want, preventing similarities from being seen.
• Can you prioritize the customers? What's the vision of the project? Do the customers define it, or does the developing company define it and later get customers to join? (Getting them aligned can then be a problem.)
• Problem can be: what is the objective of the company? Not the customers are problem, but the company is unclear about what they want.
• Situation: we first had 1 customer, then a second one, wanting completely different product. But there is an existing customer base. So you cannot satisfy all what they want, then it would not fit with other customers.
• Situation: we wanted to scale up teams in order to get dynamic pair programming happen (first there were too little programmers). So now x projects done by one team, rotating over projects. This solution creates the same problems we are talking about.

SOLUTIONS

• Why more then one customer in the first place? Then no product would be necessary (it's other approach)
• Select customers to have similar problems (you'll soon find out because of the short iterations). You can have them 'argue' over priorities.
• In order for the company to survive, try reusing a set of components. Two approaches: 1) customers doesn't need to know you're reusing, pretend to custom-make (like a consulting firm), or 2) or fabricate a product and adapt it for customers.
  The problem here may be a focus on selling a product vision instead of a product.
• Figure out priorities yourself (like a visionary) or let the customers haggle (is this the real world?). Idea: voting of customers, e.g. in a representative board (will they?). And state clearly what you will and will not implement.
  Note: customers are not competitors in this case, so they could come to agreement.
• Note: product is open source, GPL, so not for commercial use. There is mainly one development company (an institute).
  So what is the main goal? Doing a project, giving services, doing research, create work? or some other agenda? A question to be asked.
• Idea: customer sponsoring of functionalities (each with a price tag). But will customers specify functionalities in the same way? A well-defined process needed for that.
• Idea: an overall team manager is needed, the producer of the software programming, someone with vision. Why not make him internal customer (but will this shift the problems to him?). He prioritizes, but combining functionality and delivering on for each customer then gets to be his problem.
• Voting for priorities by customers may not work in a commercial environment, where customers won't sit together.
• Idea: each customer gets amount of fte (man hours per week), with equivalent number of gummy bears and resources. Want more? Negotiate with the other customers. The problem then is with the customers, where it belongs. Will the customers accept that, or say "I will get my wishes satisfied elsewhere then"?
• Idea: if you get a new project, look what you already have, and put a price tag on it. If your product is open source, that may conflict with the philosophy of open source. So that can stand in the way of a good business model.

Some basic assumptions where questioned. Do we have to develop a product? Maybe that's not the best solution.

Why do you want to make a product? It's open source, so what is the overall goal? Is it a valid vision and does it work with the current customers, or at all, in this world? ;-)

It can be much cheaper to do things for multiple customers together - instead of multiple separate products. Is it possible to do it cheaper, without these problems? It can be a pitfall to do one big project with everything in it instead of doing multiple, successful projects.

Multiple customers are much harder to deal with then normally in XP. There can be a continuous coming and going of customers. It's up to the development company to streamline development resources over projects.