Home > Uncategorized > Product Development: Frequent Releases vs. Major Releases

Product Development: Frequent Releases vs. Major Releases

January 20th, 2011 Leave a comment Go to comments

Yesterday we had quite a hot discussion about releases schedule in TargetProcess. There are two main options how you can release functionality:

  • Release as soon as something is ready (even a single feature).
  • Release periodically, let’s say 4 releases per year.

fire

Which approach is better? Everyone in agile movement will vote for the first approach. It is clearly a waste to hold a done feature in the backpack without making it public. Every marketer says that release should be a significant event with solid preparation to explain why this release is cool and how it helps to solve real life problems.

In general, it seems  there’s a Development vs. Marketing opposition.

Development wants something quick, off we go, collect feedback and improve.
Marketing wants something big enough and predictable, to prepare all materials and promotion.

I must confess, there is no clear answer to this question. As a developer I want to release feature asap. As a product owner I want to release feature asap, but understand that without major releases customers/leads may have a feeling that there were no significant changes in product over a long period of time. Is this a real problem? I don’t know.

I believe that Marketing should adapt somehow to frequent releases and change strategy to use this as an advantage. How?  This is something we should find out.

Categories: Uncategorized Tags: ,
  • http://twitter.com/alovak alovak

    Is it possible to combine both approaches?

    1. Release as something is ready and inform users about deployed features thought app notifications, blog, etc. Users will see that you continuously improve the system.

    2. Marketing can collect small changes and prepare information releases. Feedback from users can be included in such releases :)

    I think that if you deliver small number of changes than it's easy (it does not require much effort) for users to try and understand this changes. The more features you deliver in one release the less they will be used :)

  • http://twitter.com/slava_t Slava

    From the user point of view I often hate frequent updates. Though they are less painful for web apps than for desktop and mobile apps.

    - I don't like to wait while the update is being downloaded and then restart my app. Often I have to download the whole new app, instead of a small patch. Updates should be unobtrusive.

    - After experiencing any serious bug I start being afraid to update, because the new release can break something which I use often. Updates should be well tested.

    - I feel that it's useful to read what's new and try new features, but I prefer to do it once or twice a year than once a week. I'd like to do real work using the app as a tool most of the time, not to learn or re-learn how to use its features. It's better to release new features in bulk.

    - I suspect many apps are updated without any significant changes, just for some black hat marketing reasons: Android apps are updated to promote themselves in the Market, Firefox extensions are updated just to show me their what's new pages with tons of Adsense, free apps like Download Master are updated to try to make me install their adware “toolbars”. Updates should be significant.

    The solution may be in dividing the releases into the two “channels”: stable – rare and well tested, and beta – frequent and possibly buggy but with many new features.

  • Olga

    that's the best possible comment to this

  • Josh Adell

    I tend to agree with alovak. Here's how I once phrased it to a PO (who is involved with soup kitchen work): think of it this way: we can feed 100 starving children now, and 300 more at the end of the month, or we can wait until the end of the month and feed all 400. Obviously the children would prefer to get fed as quickly as possible, and our end-of-the-month newsletter (marketing) can just include the total.

    Then we got into all sorts of different aspects of that analogy. It takes larger pots and more kitchen/pantry space to feed 400 people at the same time vs. small batches. This can equate to greater testing effort, more complex deployment processes, etc. for larger releases vs. individual feature releases.

  • http://www.andrewfuqua.com Andrew Fuqua

    We've all experienced these issues. In addition, many a company's operations and training organizations can't handle frequent releases.

    But all of these things should be solvable with sufficient product owner and dev team focus (and time).

  • Alex G

    Agile software development methodologies have driven the number of releases radically higher. The increase of release events means increased pressure on release management teams, and further compounding the task of IT Operations to maintain stability while tracking and executing these releases.

    I highly recommend this Blog post: http://www.evolven.com/solutio…