re available, would provide good input for planning the product's roadmap. This would help the product go beyond meeting what is stated to be customer's input, but also help ensure the customer's needs are satisfied. These steps could be made to work where there is one customer or a few major customers who are primary recipients of the product under development. What could be interesting though is if the product is positioned in such a way that it is planned to be used by a set of users who are too numerous to be targeted individually in the manner described to collect their inputs. How are inputs to be collected for roadmap development in such a scenario? In fact, many products may fall into such categories where they have the distinct need to target possible customers who may not even be signed up for the product. In cases where the product has a wide variety of users to cater to, it would be valuable to do end-user modeling. Such user categorization could then be used to associate with specific requirements or features that are part of the roadmap, which can be recorded in the form of user stories or use cases or user scenarios. Users could be modeled in terms of: Usage profile of the product (e.g., in terms of amount of data used) Applications used by the user (e.g., business and corporate applications, home entertainment) Age profile of the users Note Some inputs related to user categorization can also be derived from the discussion earlier in this chapter where product usage has been covered in more detail. Another way of capturing enough end-user input from customers is by using the technique of customer representatives or customer surrogates. As part of roadmap development, one could have representatives for customers or for specific customer roles and gather inputs from these. These could be real people who are playing roles of customers from outside the product organization. Business representatives could also play the roles of customer surrogates to ensure that they provide valid and vital input that c