Reduced Value of Consecutive Releases

Ever-Reducing Value of New Functionality

25 October 2013



An item about ever-reducing value of consecutive releases was lingering in my head, but it did not fully come out till I read this. It is a story about Rajen Sheth launching gmail in the enterprise space. He describes how he dealt with road mapping. Road mapping is one of the biggest pains for an Agile mind, since it forces you to plot an exact time line for releasing functionality over at least a year.

And anyone who learned about Agile, Scrum, or Lean start-up knows you are a fool if you try to do this. But the big problem is that the C-level boys and girls, for some reason, want it.

He correctly states that you should let them buy into the vision you have for a market, and show them how that vision is translated to functionality in the upcoming release. Also, all the features he stumbled into during conversations with customers and prospects were nicely identified and ranked. But then he made a mistake that may not hurt a company with unlimited resources but for sure can hurt your company (assuming your resources are limited).

He divided the most-wanted features into releases like:
  • Current quarter
  • Next quarter
  • Next 12 months (e.g., second half 2013)
  • Future (e.g., 2014   and beyond)
The problem of this approach is value.

Reducing value

Which items in general make it into the first current quarter? Exactly, the ones with the highest value. So automatically the important, hot, promising items that have just a little less value go into the "next quarter" release. If you talk to enough customers and prospects and have a creative mind and limited resources, your next quarter release is loaded before you have made your current quarter release. This is exactly how this terror thing called a road map got started!

So the major consequence of this approach is the reduced value of the next release, and the next, and the next, and the next . . . ending in only lame tweaks of existing features.

I would like to suggest (I am mild here since Rajen does have a kind of Guru status) to only commit to functionality in the current release. And make a ranking of the items for the next release without committing to it. Communicate your vision and goals continuously and deliver according to that vision. Keep it transparent and explain why items suddenly go on top.

If you have to commit to things past the current release, make sure you commit to the most limited number of items. Never have a fully planned release before you've even started working on a release. Ideally, you are committed content-wise no more than a few sprints ahead.

Reducing even more value!

Next to that, don't let the customer's wish list own your development. Product management is not about listening to your customer but about understanding your customer, so lists fed by current customers only will never bring you to new markets. This listening to the customer versus understanding your customer also is responsible for another source of reduced value. While you are building up value, your current customer will become more and more satisfied; as a result the items delivered on you feature list will become less and less valuable. You have saturated the needs of your customer. Actually, if you have reached that point it is time for a new vision, new segments, and new goals.

I know that it is very hard to put this in practice. It requires management and customers to buy into the product vision and goals and trust that you can deliver against it. And you have to deal with the C-level promises to this one special customer for that one special feature that is of no use to all your other customers. And that one is, most likely, the hardest. . . .

Article Rating

Current rating: 4.9 (8 ratings)

Comments

Irene Michlin, CSP,CSM, 10/25/2013 7:12:07 AM
Thanks. Hard to explain to management why it's pointless to pack the "one after" release with features upfront. Sometimes it's even hard to stop them from wasting time on current release, estimating every task in the next one down to man-hour. Just to throw it all away as the m market inevitably changes.
Fawn Damitio, CSM, 10/31/2013 3:51:31 PM
Thanks for the article, very informative. I think the key here is communicating vision without getting into the details. Also, the more the C-level folks are educated on Agile and see that they can have complete transparency on the most immediate work in the queue, the more embracing they will be of it.
Andreea TOMOIAGA, CSM, 12/7/2013 7:02:10 AM
Excellent article, I liked the ideas around the general principle of adjusting current capacity towards market demand from the second half of it. More often than not, it is so easy to forget about it and when this happens the goal gets out of sight.

You must Login or Signup to comment.