Anticipating Customer Wants

Carl has a good little post about referencing Mark Cuban's concept of building the product your customers are going to want versus what they tell you they want now.
Carl said-
"A friend and I were walking down this path earlier this month discussing how all of the applications that we have written over the years were successful if the user'’s did not have that much input. This totally goes against the grain of Agile methodologies."

There are a couple of things going on here. One is that a big difference between commercial product development and enterprise custom development is that in the enterprise your customers are already identified and assigned to you. Still, I have always found it make enterprise custom development as similar to product development as is reasonable. The reasons for this are numerous, but the unanticipated expansion of your customer base and supporting new functions of the existing customer base are two prominent ones. In this analysis, it does make sense to do some generalized product style development in the enterprise versus just building what the customers you have access to say they want.

In my mind- agile software development methodologies, where you only really do what is most important in the current iteration, are actually better than up front requirements definition methodologies where you plot out precisely what you are going to for the next year or two. In the up front case, you basically guarantee that you aren't going to be able to adjust to what the customer is going to want when you figure it out halfway through the budgeted schedule.

It does point to a fundamental problem with the whole concept of requirements gathering in the enterprise custom development context. Who is representing the customers that aren't at the table? This is why treating the project as a product- and having someone function in a product management role is really important. If you have someone that is an advocate for the product itself- you can allocate some of the budgeted time/money to making it a better product.

So, my solution to the problem of representing the interests of users that aren't at the table (including the "future users") is to have someone appointed to serve that role, and give them a "point budget" in each iteration or release. In my current project, we aren't really doing that, but we have a certain number of points reserved for the developers own choice of what to work on (could be reducing technical debt). In our agile development process we are using points to represent the amount of work we are capable of completing in a certain time period, and allocating some of those points to various stakeholders. It's only logical to think of the future of the product as a stakeholder in its current inception.

This differs a bit from the whole Getting Real thing (where the product manager has total control to select from the list of desired features), but it seems more workable in a typical office politics environment where everyone wants their influence to be recognized.