All posts by Daphna Rosenthal

Next-Generation products – Evolution? Revolution? Creative destruction?

 Hi-Tech companies need to innovate at all times. Technology is changing constantly, and if you don’t innovate, you stay behind. We all know this is true.

One of the big dilemmas for hi-tech companies who already have a product, is whether they should continuously improve the current product , or innovate with a totally new product. Some call it evolution vs. revolution, while some use the terms “creative destruction” or “cannibalization”. But it’s all the same. In this paper, I will use the terms evolution and revolution.




Product managers should weigh the pros and cons of the two, so different, approaches.


The “Revolution” option:

It sounds great for the developing company. They can develop from scratch, they are not dependent of the current product and therefore don’t have to carry along problems this product might have. For the developers – revolution is heaven: rather than adding to an existing product, they get to develop a brand new product, with whatever tools are available today, as if they work in a startup…

This approach fits with the notion of “creative destruction” – a leading concept in innovation theories. Creative destruction means that one gets rid of the old product in order to replace it with a newer one. It stems from the fact that if you don’t come up with a very up-to-date product, your competition will do so. Therefore, don’t fear to “kill” you own product in order to introduce a new one. One more point in favor of revolution is the product’s perception in the market. – customers might like the idea that the company they are buying from keeps creating products with the latest technology.


The “Evolution” option:

The company has a product, it’s selling well today, there are lots of customers using it around the world. For these customers evolution is a smooth way to get improvements on products that are already being used at their premises. Just imagine a customer who uses a complex software solution for the last 7 years. Now assume the software provider offers a brand new product, to replace the current one. From the customer’s viewpoint – this is extremely risky.

Moreover, it might cause them to examine the competition: If they have to migrate to a new product provided by their own supplier – why not open it for re-evaluaion of the other options in the market. This, in turn, means that revolution is risky for the provider as well, and not just for the customers. The more customers you have – the more likely you will select the evolution option.

So – which is best? There is no clear answer. Like most difficult questions – it depends…


I would suggest that:

  •  If you have many customers, go with the evolution option, but make sure that the evolution brings your product to a top of the line competitor in its market, and not just makes it “stay alive”

  •  If you have few customers, or if the migration from the old to the new product can be relatively easy – consider evolution

  •  If you believe (and can show a solid business case for this) that a new product will be 10 times better than the current one, do it!!! (Now, how do you know what 10 times better is – that’s for a different article)

Product Management and SaaS

Today, more and more products are offered as Software as a Service (SaaS).

Is the product managers’s job the same for SaaS offering, or is it completely different than the product manager’s tasks for the traditional, non-SaaS product?

In short, we can say that the product manager’s “job description” is the same whether the offering is a traditional / on-premise one, or if it’s SaaS. In both cases, product managers are expected to understand the market needs, perform competitive analysis, define the roadmap, provide high- and low-level requirements, and define the positioning, packaging, pricing and messaging of the offering. So, at first sight, there is no difference.




However, the difference lies in the CONTENT of the above tasks, the dilemmas we have to solve, and the way we do it.

Here are some points that can illustrate the above:


1. Product releases –

for on-premise products, we define the roadmap, with major and minor releases. In SaaS there is no reason to discuss major and minor releases – the users do not care whether the changes in the product are part of a major release or not. They don’t pay for it anyway. Once they subscribe to the service – they automatically get whatever is there. This implies that the product manager is “free” from these definitions, and can introduce any changes at any time, if these make sense.


2. How many releases?

How often do we make changes to the product? – For on-premise products, the answer is clear – every release, according to the release policy (normally, one to a few releases per year). For SaaS offerings, the decision is more complex. Think about yourself, as a user of Gmail or Facebook: Do you like the fact that the product changes often? Would you prefer to see less (or more) changes? The answer is tricky.

On one hand, the ability to add/change things in SaaS is great and very tempting. After all, that’s one of the benefits of the SaaS business model. On the other hand – if we change too much, we might irritate the users. Product managers should find the fine balance between the two options – and it’s not an easy job!


3. Pricing –

Pricing for traditional products is based on licenses. In SaaS, we use the subscription model. And on top of it, we normally offer either a free trial and/or the Freemium model. So it’s clear that the product manager’s job in determining the pricing model is very different. Just think of the Freemium model: it is the product manager’s responsibility to decide which parts of the product are provided for free, and what is “the first step” for which users will have to pay. A poor decision here can affect the company’s ability to be profitable! It could be a life and death decision.


4. Product infrastructure –

do product managers have to care which technological infrastructure will be used for the products? In the traditional model – the product manager has a strong say, as the customers will have to support this infrastructure and approve of it. However, for SaaS – product managers should not care. Let the R&D people make these decisions.


5. Simplicity –

the name of the game in SaaS is simplicity. If the product is complex to use – no one will buy or stay with it. So please, no bells and whistles – just make it simple and easy to understand with little or no training.

There are many more differences, but this list shows that even though it’s the same product manager, with the same tasks, there are significant differences in focus within each task. Does it mean that traditional product managers cannot do it for SaaS – absolutely not! They should adapt to the changes in focus, but overall their role is unchanged.