Ask A Good Product Manager

Your product management questions answered

How do you choose between major and minor product releases?

Posted on April 27, 2008 · 4 Comments

Question: When should a product have a “major release” vs. a “dot release”?

Are there any general rules for when to move to a major (.0 release)? My experience has been that if there is a major functionality change or a new interface or product overhaul, it is good to move to a “.0” release. Customers plan differently for a major release ,and if we slip a 3.4 release in on them when it is a major change, they will be frustrated, so calling it a 4.0 would be better.

Plus, there is the entire marketing side of things. Can you offer some advice or point me to somewhere to read up on this? Specifically, we just came out with 3.0 of my product back in January — and have released 3.1, and soon 3.2 — and we are overhauling the interface in Q3. I really want to call it 4.0. What do you think?

Answer from Nick Coster of brainmates: I would suggest not to get tangled up on a product’s version number when communicating it to the market. These are useful for support and software development versioning control. In isolation, however, they are irrelevant to a customer.

What is relevant to a customer is what new problems can be solved with the updated product. You can see a trend developing with many software providers like Symantec, Microsoft and Apple who use dates (2003, 2007) as the version number — or, in Apple’s case, types of big cats (leopard, tiger, etc). This breaks away from the successive versioning and the hassle of tracking point releases of software in the product name.

For a new and significant release you should be looking for one or two key new customer benefits that will differentiate the product from other offerings. If your case, ask yourself: “Does the interface improvement solve any new customer problems?” This should not include problems introduced by the previous interface. 😎

For existing customers, what is the benefit of updating their software from a previous version — stability, simplicity or a new solution? Whatever it is will have to outweigh the customers cost of performing an upgrade.

Consider a version re-name or re-number when you are adding significantly more value to the customers. This is when you will have a product change that is worth talking about. Make it count.

4 other answers so far ↓

  • David Locke // Apr 28, 2008 at 1:26 am

    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.

  • Ivan Chalif // May 1, 2008 at 11:18 pm

    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.

    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.

  • Gopal Shenoy // May 3, 2008 at 3:44 pm

    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.

  • Steve Johnson // Jul 19, 2008 at 6:13 am

    I wrote about this topic in my article (free) posted at