Post from: Front-End Book hosted on DreamHost

You know you are doing it wrong when …

Related posts:

• Recession Reality Check for Web Developers

A lot of people will always argue that in order to reach the high set goals you have, you have to take on an revolutionary approach to your product development, and others will say that taking on the revolutionary approach to product development is building a product based on facts and requirements that are not the actual facts and requirements that are present when the revolutionary approach are implemented and put into production.

In this post I will discuss and share my ideas on different strategies and approaches to your product development.

Revolutionary Approach to Product Development

The business owner may say

“The product we have today can’t handle future market needs, we need to build a new product that can do whatever our product can do now and also add the possibility to X, Y and Z”

Sometimes the argument goes

“The current solution is way to expensive to maintain and we really need to make sure that the product is easier to maintain, this way we will free up resources to do X,Y,Z”

or you have possibly hear this argument

“If you want us to build X,Y,Z on top of our current product, it will take x number of man years and the outcome will be that you have to skip this and this feature of X, Y and Z”

Whatever the arguments are, there is always forces within the organization to take on the revolutionary approach when making your product ready for X,Y and Z. Some of these arguments are very valid to start with, from my point of view, but the conclusions may not always be the best. Just because the current product has some kind of built-in disadvantage does not mean that the new product will not has the same kind of problems. I will go in to detail on that later.

On a more philosophical level, the revolutionary approach states that you know the future market needs and even more it suggests that you know how to solve them all by redoing/rebuilding your product. It also suggests that you as an organization thinks that you can manage to actually implement and deliver without actually destroying the current product when it comes to the user experience. You could say that the revolutionary approach is to branch your current product and go of in a different direction with the new product, while the smallest possible team actually makes sure that the original product is working smoothly. The big effort is put into the revolutionary branch, first to match the feature set of the current product, then adding X,Y, Z as requested by business owners. When the new product has all features: original + X,Y,Z you have to halt implementation of the new product and the maintenance of the old product. Now you have to merge maintained changes to the original product to the revolutionary product. During this time you will probably see no or very few changes as a product customer. If you are lucky as a business owner, this is only a small break in the productivity and small cost to actually get the new revolutionary (better?) product in place. If you are unlucky, this halt of productivity is a big cost as you lose possibility to do product development and product management and in the long run maybe even lose money and market shares.

I believe that the revolutionary approach is probably more used within organizations that traditionally work with strict processes, waterfall development, believe that the product they have is inferior to the competitors and really needs to be changed from top to bottom and for organizations that think they have stumbled on an idea that will change the market they act upon by building the next generation product.

Evolutionary Approach to Product Development

How does an evolutionary approach differ from the revolutionary approach? In my world evolutionary product development is a continuous process of gathering data that says something about your customers, your product and how your customers interact, feel about and use your product. Using this data, identifying problems, opportunities and things that needs further investigation in order to better understand the product and the customer. Of course you have to have some kind of product in place in order to actually have an evolutionary approach to product development. The main thing that differs evolutionary from the revolutionary approach is that you do not have a due date on when the product is finished, it never is. It continues to evolve and as any evolutionary process it will create side effects that are wanted, not wanted, expected and unexpected. Some of these side effects can be exploited, solved, used or ignored, the main thing is that the product evolves based on what we know about the world, product and the user NOW, not then.

To be honest, looking at the real world, most of the changes that occur are of the evolutionary kind with revolutions taking place from time to time, but hardly as often as thing changes with small steps, one at a time adapting to reality. Even though this is the case, a lot of product owners still believe that the revolutionary approach is superior to the evolutionary, this can depend on different things:

• Venture Capitalists have high set goals for market shares, and they want those numbers now
• Hybris, the people who run the product think they are on a higher level than the competition and or old business owners, and think that the only way to actually get things going is to do it their way.
• Long term goals need to be met short term. Sometimes the pressure is high to meet very high set goals, this could be to please stock owners, make sure that the product is not sold or even worse taken out of business. This way you can get goals that are valid long term goals, but only short term to meet them, making a revolutionary approach the only valid way to go about solving the problem.
• Product owners do not understand the market
• Underestimating the efforts needed in order to revolutionize the market

Why I am choosing the Evolutionary approach 9 times out of 10

As you may have identified already, I am a fan of the evolutionary approach to product development. I think that for almost any product, the approach of constantly tuning and refining the product evolutionary is the approach that gets the job done most of the time. This way, we as product owners and other stakeholders, know that we build and manage for the user needs that we have now, not thought up features and solutions that we think will serve our users in the future (when the new product is ready for launch). Below I have listed some of the things that is, as I see it, the biggest advantages of taking an evolutionary approach to product development.

• Features will not disappear all of a sudden.
• You do not have to freeze your line work while merging the revolution with features actually built and delivered while the revolutionary product was developed.
• Suits an agile philosophical approach to a product life cycle, where there is no deadline when the product is ready and the idea that we should focus on solving the problem we have now.

But Startups must take the Revolutionary Road?

OK, lets say you are starting up a new company, with new products to offer to your customers, then you are forced to take the revolutionary approach to product development, or are you? In some sense you will build your products from scratch, but there are short cuts that you could take in order to actually start working as an organization that works agile and with an evolving approach towards product development. Below I have listed some of the things you could do to jump start your

• Use Open Source software when applicable. Adapt, contribute and build your brand by being the thought leader in your product area.
• Use existing frameworks (could be software, theories, ideas) in order to be able to quicker get started.
• Buy existing products.
• Join forces with companies that can enable features that you need in your product.

Discussion

In my simplified world, you can choose whether you should go for the evolutionary approach or the revolutionary when it comes to how you manage and develop your product(s). My opinion is clear, I will, when possible, always go for the evolutionary approach as I think that approach is an agile approach to product development, making it easy to actually react to the problems and user needs we are facing when building our product. You could argue that the revolutionary approach could be combined with the evolutionary approach, that is of course true, but I have also showed that sometimes you can avoid building it all by yourself from scratch using external solutions, buying other companies or build on top of a partners solution and that way also make the creation of the product an evolutionary approach to how you manage your product.

Post from: Front-End Book hosted on DreamHost

Evolutionary or Revolutionary Product Development?

Related posts:

• How Twitter learned me to love the user
• Recession Reality Check for Web Developers
• You know you are doing it wrong when …

Post from: Front-End Book hosted on DreamHost

Last Weeks Tweets from FrontendBook – 2009-10-18

Related posts:

• Last Weeks Tweets from FrontendBook – 2009-10-18
• Last Weeks Tweets from FrontendBook – 2009-09-20
• Last Weeks Tweets from FrontendBook – 2009-08-09

Post from: Front-End Book hosted on DreamHost

Last Weeks Tweets from FrontendBook – 2009-10-18

Related posts:

• Last Weeks Tweets from FrontendBook – 2009-10-18
• Last Weeks Tweets from FrontendBook – 2009-09-20
• Last Weeks Tweets from FrontendBook – 2009-08-09

Post from: Front-End Book hosted on DreamHost

Last Weeks Tweets from FrontendBook – 2009-10-11

Related posts:

• Last Weeks Tweets from FrontendBook – 2009-09-06
• Last Weeks Tweets from FrontendBook – 2009-08-30
• Last Weeks Tweets from FrontendBook – 2009-08-16

Post from: Front-End Book hosted on DreamHost

Last Weeks Tweets from FrontendBook – 2009-10-04

Related posts:

• Last Weeks Tweets from FrontendBook – 2009-10-04
• Last Weeks Tweets from FrontendBook – 2009-08-16
• Last Weeks Tweets from FrontendBook – 2009-09-06

Post from: Front-End Book hosted on DreamHost

Last Weeks Tweets from FrontendBook – 2009-10-04

Related posts:

• Last Weeks Tweets from FrontendBook – 2009-10-04
• Last Weeks Tweets from FrontendBook – 2009-08-16
• Last Weeks Tweets from FrontendBook – 2009-09-06

Post from: Front-End Book hosted on DreamHost

Last Weeks Tweets from FrontendBook – 2009-09-27

Related posts:

• Last Weeks Tweets from FrontendBook – 2009-08-16
• Last Weeks Tweets from FrontendBook – 2009-08-23
• Last Weeks Tweets from FrontendBook – 2009-09-13

Post from: Front-End Book hosted on DreamHost

Last Weeks Tweets from FrontendBook – 2009-09-20

Related posts:

• Last Weeks Tweets from FrontendBook – 2009-08-30
• Last Weeks Tweets from FrontendBook – 2009-09-06
• Last Weeks Tweets from FrontendBook – 2009-08-16

Post from: Front-End Book hosted on DreamHost

Last Weeks Tweets from FrontendBook – 2009-09-13

Related posts:

• Last Weeks Tweets from FrontendBook – 2009-09-06
• Last Weeks Tweets from FrontendBook – 2009-10-04
• Last Weeks Tweets from FrontendBook – 2009-10-04