put does not get invalidated. One of the prime reasons for this is that, depending on the size of the product and time taken for roadmap development, which may again depend on the number of stakeholders involved, we may be talking about a process that could take from weeks to months to complete. In such times, when customer requirements are not properly represented, some of them may get overlooked in further development. It helps to make explicit note of certain customer commitments that need to be fulfilled by the roadmap and also to ensure that when decisions need to be made in between the selection of features for the roadmap, these customers are kept apprised of the impact. CHAPTER 4 NETWORK ROADMAPS Primary inputs from customers for roadmap planning include mainly the need for specific features to be deployed to help customers meet certain requirements. For example, support for E-TM Transmission Mode self-tests may be needed to meet regulatory requirements. In addition to these features, however, additional customer input, as list below, is also quite important to ensure that the roadmap covers all of the necessary aspects required by the customer. These could also be considered indirect inputs for roadmap planning, which could help explain the gaps in this information and also help tune the plan: Specific requirements toward quality assurance of the product and the network. This may depend on the kinds of interoperability tests customers expect the product to go through. This would need to be planned in product development or in early customer testing. Time taken toward integration of the product with all equipment at the customer's premises so that product releases can be planned in time for demonstrations that need to happen on specific dates. Specific interdependence and interoperability requirements toward hardware and software components the product needs to work in the customer's networks; support for these needs to be planned in the roadmap. Roadmaps that the customer shares with their end users, whe