Skip to main content

Maintaining multiple versions of a product

A product team , when it has more than one client, faces a challenge when it has to maintain multiple versions of the product.

Typically the implementation team would have made some customizations for every installation for the product. However, when they release a new update, they struggle to make it work for all the products since there are customizations and the new update might not be compatible.

There are several considerations that a product manager needs to take while deciding on the product strategy.

Saas versus Installation

Having a saas product makes it easier for the engineering team to push updates. If it is a installer distribution, There are the team will face challenges with distribution. Compatibility is also an issue.

The biggest issue however, from the user perspective, is data migration from the previous version to current version. The best way out of this is to make it a service as well. You can decide whether you want the customer to pay for that or not

Update versus Upgrade

There is no one correct definition for either of these 2 terms.

For the current product team that I am working, we have decided the following:

Upgrade: Any introduction of a major functional feature. This would involve significant changes in the product and there typically would be a need for the users to be retrained. Further there would be a need for data migration from earlier versions to current versions.

Update: This is a minor update that would be addressing smaller sets of feedback or any defects in the product. This would typically be handed out free. There would be no need for data migration and all the data that used to work in the previous version should work in the current version as well.

When we release an upgrade, we have to be careful on how many users are ready to switch to the latest version

Support for older versions

When we release new versions, we also need to understand how much concurrent versions can be supported. Sometimes this could be a cost in itself.

To handle this issue, our product team has decided on the following:
  • We will always handle only 2-3 versions old
  • If a version has less than 5% users we will stop supporting it actively
  • In case there are users that are still in older versions, we will allow them to upgrade freely.
Why would we allow them to upgrade freely?

This is so because we have found that the cost of support is far more than the cost of the upgrade. Hence, we reduce the cost of support by allowing for free upgrade.

Frequency of Updates and Upgrades

The updates can be as frequent as possible. Right here we are thinking of around 4-6 weeks between updates.

Upgrades , however, need more time. We have currently not reached a stage of maturity to release an upgrade yet. Based on our initial plan, we plan to release an upgrade every 12-14 months.

Why is this important?

The upgrade frequency is important for the users for the following reasons:
  • It gives them a visibility of what is going to come and when
  • It ties well with their business calendar and the new upgrade satisfies their new business needs
With all these considerations, the product manager needs to be able to handle support for multiple versions of a product.

Comments

Popular posts from this blog

The right business model for your product

How would you decide what is the best business model for your product? Deciding on the right business model is very important for the product. It does not necessarily mean what is the price of your product. There could be no price for your product - though that is a myth. For example, we think google or Facebook is free. However, we are never the customers for Google or Facebook. It is the advertisers that are its customers. What we need to figure out when we decide on a business model are as follows: Who is my target audience? Who is my customer What is the price. How is the support model going to work Who are my partners While we do not absolutely need to price a product, we need to understand how we would make money. For example Open ERP does not price its product. However, its product is not the ERP software but really the hosting, service and training that it offers. While pricing is an important part, what is more important is in realising who is you...

Finding your target audience

The biggest task of the product manager is to find your target audience. Typically it is a very tight rope walk. You define it too narrowly and you would struggle to generalize the product later. You define it too broad and you would struggle to satisfy a lot of people and the product might not take off at all. There is this awesome post by Dave Mcclure on why Niche target segment works. Blog link here . What he says is mostly right and that is what we did as well. We did it mostly by accident. We had to define our niche because we could only talk to those kind of retailers and get data from them to start developing the data. It did have its upside. We were very clear on what we wanted to develop and we are slowly talking to retailers and adding more scenarios. As we are doing this, we are also talking to a slightly different set of retailers. This helps us incrementally build our product while also generalizing the existing features. In our case, we did not fin...

Constructing the Product Roadmap

When I started out in the team, I was tasked out with coming out with a plan so that we can demonstrate the product with real data. The idea was to demonstrate it to our prospect with their own data and win them over. However, when I started working, I found out that what we lacked was not a plan but a vision. I quickly put together a one day workshop with our team and our product owner. When we started talking, we talked about several things and figured out that we needed a plan of various proportions. We needed a plan that could help us one the following: Provide a focus for the long term with near term focus on just one thing Help us talk to prospects on what we are going to do Help us decide on when we would need to focus shift on which function - Engineering , sales etc We also did a quick “Product in a box” exercise so that all of us in a team can practice and imbibe the elevator pitch. We needed this since we had to do this pitch at several levels - Inter...