Regular sessions with Product Management and Customers

One of the most common experiences I had while interacting with people on product development teams, especially those who have been on 2-3 development cycles, from start to end is, that they seem to get a feeling for what the features in the product should be, how the workflow should happen and so on. It can get tricky when they have a strong feeling in this regard since they might incorporate their feelings in the workflow that they are implement and it would take some effort by the workflow designer or the product manager to get the design as they want (may not happen very often, but it is something to be watched out for).

But when you get the team members on the beta release program, or to monitor the user forums, or to attend sessions where actual product users meet the product development team, it can get interesting. Even when team members get to review the prerelease program (the beta program), they can seem surprised at the type of defects or feature requirements that come through these programs. I have seen cases where the team members almost dismiss these as defects that are worthy of deferring or not part of the general workflow and they have to be reminded that these are actual users, the ones who actually pay and use the software program.

The more perceptive of the team members welcome such interactions, since it gives them a great idea of how their customers are actually using the product (or atleast a section of the users) and the more they take part in their interactions, the more they are connected with how the users actually use the software and this in turn benefits the product since they are more attuned to the requirements of the user, and in fact, would actively hunt to figure out the requirements of the user.

At the same time, it is necessary that all members of the team are exposed to such interactions. Such interactions help team members understand what the users feel, that sometimes their perception of what users feel and what they themselves feel about how a feature should be like, or the severity of a defect can vary drastically, and such interactions help reduce these differences and give them a better understanding of the customer perception of what is important for features. The next when a new feature is being designed, it makes the process much smoother, and actually helps the product manager - for the case of teams that implement the Scrum development methodology, such a customer centric perception from the team members is absolutely essential and helps to drive the process of feature delivery. 

One example of this was where the feature requirement was detailed by a customer to the product management team who wrote feature specifications for the development team. However, the developer was a senior developer who had his own ideas of what the ideal feature should be like and proceeded to tweak the feature specification. It required some amount of rework to ensure that the feature was finally done as per the product management / customer requirement. 

Not every defect should be fixed

During the course of a software development project, whether this be an updated version of a product or a one-off software project, the key currencies of the project are primarily features and defects (features and defects are what the teams end up doing most of the time during the development cycle, and in fact, at some intense points of the cycle, the team will be doing mostly defect finding, fixing, releasing fixes and re-test (in the Waterfall cycle), once the feature is released, it is bug fixing and more bug fixing.
In the software team, these are busy times. In a number of such development cycles, the number of defects that there are there in the product are such that it seems tough to think that all of these will be fixed in the given time cycle. This cycle of defect fixing primarily involves the developer and the tester. Some of these would be simple defects, where the feature as defined is not working and needs to be fixed by the developer. However, there will be other cases where there is some ambiguity in terms of how the feature is working and whether it is as per the definition - it could be that the feature definition is not complete to cover all the cases or that there is some disagreement regarding the way that the feature was supposed to be working vs. how it was written.
The biggest problem could be that the resolution of such issues happened in a path not intended to happen, something that the product manager had not intended. Now, it is not necessary that it happens this way, but one has to prepare for such an eventuality, or to be more clear, to define a process so that such a thing does not happen. The actual process is something that needs to be defined for each team, since what works for one team may not work for another team. For example, I once worked with a team that asked that all defects be triaged by a bug committee which decided whether it needed to be fixed or not, and if so, what would be the proper method of fixing (although the actual fix is something that the developer and tester could decide). Why this process may not work for all teams is because of the quantum of defects that may come in, overwhelming the defect review committee and causing a backlog. Other teams may find such a process too severe, trusting the developers and testers that they will not automatically make suspect fixes, checking with a defect committee or with the Product Manager before actually making a feature change or refinement.
However, it is essential that this be talked about and decided with the management and with the team before proceeding, else there is a chance that feature changes may happen just at the developer and tester level.