One reason that companies fail is that their software isn’t really differentiated from their competition. Just adding all of the bells and whistles that your customers ask for is not a way to differentiate. Your competition is being asked for exactly the same things.
While the appeal of rapidly responding to customer requests is very tempting, there are a few cautions in order. Customers don’t always know exactly what they want and don’t always express their high-level requirements. Often, they will ask for something because they have established a manual process to work around the fact that you are missing a whole feature set and there is one feature that would really help their manual process which wouldn’t even be needed if you had the feature set that they really need. By responding rapidly to customer requests as though they were well thought out requirements, you run the risk of creating Frankenstein’s monster: lots of bits and pieces that don’t really work well together and don’t form a very intelligent solution.
Also consider that unless you have a very big team or a very small stream of requests from users, it is unlikely that your development organization has the bandwidth to keep up with all of the requests from users. And of course, the more you provide, the wider your market appeal will be and the more customers you’ll have and the more requests you’ll get.
Each of the requests that you implement has both a cost and a benefit associated with it. If there is not enough benefit to justify the cost, it is debatable if you should even consider fulfilling the request. Remember though that the benefit may come in the form of customer satisfaction which can lead to more customers. In any case, you should do at least a rudimentary cost/benefit analysis to at least rank a particular request among all of the other requests you could do. Those with the best ROI should bubble to the top.
Even doing an ROI analysis is not really enough. What you really want to do is to add new capabilities to your product or new products to your product line with a good ROI while maintaining the integrity of those products. That is, you want to maintain the quality, usability, and performance of your products.
Next: The Role of Defect Management in Agile Development
4 comments:
Good post. I was in meeting today about the prioritization of work requests and I've been thinking that maybe we should add a Bang-for-the-Buck or ROI score to each request. Maybe on a scale from 1-10. Not completely scientific but possibly a good way to prioritize the work. Always do the highest BftB work first. Kinda like paying off you credit cards get the small one out of the way and use the resources on the next smallest balance.
Mike
I can't tell how this is different from any other brand of Product Management. Distinguishing what customers need/want from what they ask for and choosing high ROI features are key skills for any product manager.
If this is really going to get expanded into book form, it would be useful to compare and contrast agile vs traditional product management practices.
Tom,
Good point, I agree. Thanks for the suggestion.
Cheers,
Damon
Nice Post!!One of the biggest fears is losing control over the progress of the project.
To show the project tracking capability of an agile process, we can create some model status reports entirely based on fictional data. The reports can show a fictional project cycle of two to four weeks.For more, Please Visit: https://www.scrumstudy.com/blog/concerns-of-the-management-while-introducing-the-agilescrum/
Post a Comment