Comments on: How do you choose between major and minor product releases? http://ask.goodproductmanager.com/2008/04/27/how-do-you-choose-between-major-and-minor-product-releases/ Your product management questions answered Tue, 13 Dec 2011 18:48:32 +0000 hourly 1 By: Steve Johnson http://ask.goodproductmanager.com/2008/04/27/how-do-you-choose-between-major-and-minor-product-releases/comment-page-1/#comment-266 Steve Johnson Sat, 19 Jul 2008 12:13:28 +0000 http://ask.goodproductmanager.com/2008/04/27/how-do-you-choose-between-major-and-minor-product-releases/#comment-266 I wrote about this topic in my article (free) posted at http://www.pragmaticmarketing.com/publications/topics/03/0301sj I wrote about this topic in my article (free) posted at http://www.pragmaticmarketing.com/publications/topics/03/0301sj

]]> By: Gopal Shenoy http://ask.goodproductmanager.com/2008/04/27/how-do-you-choose-between-major-and-minor-product-releases/comment-page-1/#comment-117 Gopal Shenoy Sat, 03 May 2008 21:44:20 +0000 http://ask.goodproductmanager.com/2008/04/27/how-do-you-choose-between-major-and-minor-product-releases/#comment-117 We used major releases to indicate data was not backward compatible because of database schema changes. Data saved in the newer version could not reopened in the older version - 3D solid modeling was that kind of a beast. The point releases were nothing but service packs to fix bugs - but the database schema could not be changed - data was compatible between all the point releases of a major release - forward and backward. You can call this an internal limitation, but this helped us determine where a new feature could go - it was very rare for us to introduce a new feature in a point release because this required us to put in any required schema changes needed to support the new feature before the major release went out. We used major releases to indicate data was not backward compatible because of database schema changes. Data saved in the newer version could not reopened in the older version – 3D solid modeling was that kind of a beast.

The point releases were nothing but service packs to fix bugs – but the database schema could not be changed – data was compatible between all the point releases of a major release – forward and backward.

You can call this an internal limitation, but this helped us determine where a new feature could go – it was very rare for us to introduce a new feature in a point release because this required us to put in any required schema changes needed to support the new feature before the major release went out.

]]> By: Ivan Chalif http://ask.goodproductmanager.com/2008/04/27/how-do-you-choose-between-major-and-minor-product-releases/comment-page-1/#comment-116 Ivan Chalif Fri, 02 May 2008 05:18:06 +0000 http://ask.goodproductmanager.com/2008/04/27/how-do-you-choose-between-major-and-minor-product-releases/#comment-116 Almost all of our releases, whether X.0 or X.y.z, have new features in them. That's just where we are as a company. What determines the level of the release (maintenance, minor, or major) has mostly to do with the scope of the release. Major releases typically happen 1-2x per year and have significant new capabilities and features, as well as large-scale defect fixes. Minor releases slim down on new features and defects, but tend to be more feature-laden than bug-fix-laden. Maintenance releases shift more toward the defect side of the spectrum, but inevitably still have a new feature or two in them. There are bound to be some customer expectations based on the release type and number, but if you communicate clearly and early about what is in each release, your customers will be better able to determine which releases are best for them, regardless of the number. @David I disagree that changing the view does not add value. A change to the UI could be resolving defects in the previous UI or could be used to improve the work flow. It might also allow you to mimic UI conventions that have become more mainstream so that less training is required to use the product. It's important not to just put "lipstick on a pig," but there is inherent value in making changes to the UI that enhance the user experience. Almost all of our releases, whether X.0 or X.y.z, have new features in them. That’s just where we are as a company. What determines the level of the release (maintenance, minor, or major) has mostly to do with the scope of the release.

Major releases typically happen 1-2x per year and have significant new capabilities and features, as well as large-scale defect fixes. Minor releases slim down on new features and defects, but tend to be more feature-laden than bug-fix-laden. Maintenance releases shift more toward the defect side of the spectrum, but inevitably still have a new feature or two in them.

There are bound to be some customer expectations based on the release type and number, but if you communicate clearly and early about what is in each release, your customers will be better able to determine which releases are best for them, regardless of the number.

@David
I disagree that changing the view does not add value. A change to the UI could be resolving defects in the previous UI or could be used to improve the work flow. It might also allow you to mimic UI conventions that have become more mainstream so that less training is required to use the product. It’s important not to just put “lipstick on a pig,” but there is inherent value in making changes to the UI that enhance the user experience.

]]> By: David Locke http://ask.goodproductmanager.com/2008/04/27/how-do-you-choose-between-major-and-minor-product-releases/comment-page-1/#comment-111 David Locke Mon, 28 Apr 2008 07:26:05 +0000 http://ask.goodproductmanager.com/2008/04/27/how-do-you-choose-between-major-and-minor-product-releases/#comment-111 You might ask how much value is being added in each release. That value is determined by the customer, not you. If you put your past releases in a time series relative to the value provided, you should see which ones were minor, and which ones were major releases. Why are you changing the interface? What are the marketing drivers for doing so? If you are moving from early mainstream to late mainstream a revision is critical to the point of releasing an entirely new product with a different name. Feature bloat has to go away. Task have to be sublimated. And, you have to say goodbye to the geeks. In no other market transition is an interface change necessary. Changing a view does not add value. Another consideration, if you are adding new functionality, is to ask yourself is you are changing the theory of operation that drove requirements elicitation up to now. Frankly, you shouldn't be changing the theory, because you end up wa totally new product if you do. Changing interfaces can confuse your retained customers. They are not going to want to invest in learning a new interface if the reasons for doing so are not immediately obvious to them. You might ask how much value is being added in each release. That value is determined by the customer, not you. If you put your past releases in a time series relative to the value provided, you should see which ones were minor, and which ones were major releases.

Why are you changing the interface? What are the marketing drivers for doing so? If you are moving from early mainstream to late mainstream a revision is critical to the point of releasing an entirely new product with a different name. Feature bloat has to go away. Task have to be sublimated. And, you have to say goodbye to the geeks.

In no other market transition is an interface change necessary. Changing a view does not add value.

Another consideration, if you are adding new functionality, is to ask yourself is you are changing the theory of operation that drove requirements elicitation up to now. Frankly, you shouldn’t be changing the theory, because you end up wa totally new product if you do.

Changing interfaces can confuse your retained customers. They are not going to want to invest in learning a new interface if the reasons for doing so are not immediately obvious to them.

]]>