Analogy - Vehicle and Software Product

How do you want your product to be?

A question not only for a Product Director or an Owner or a Manager. Of course, they should do their part of the research and draw a picture of how they envision the product. This picture should then be passed on to the Tech folks. Some may argue that tech people can be involved right from the start. Let’s keep that point aside for now. I am not against or for it.

I will be discussing the second part; the tech folks’ version of the story.

Let me put a few names here: Royal Enfield aka Bullet, Pulsar, KTM Duke, Yamaha R16, Unicorn, Activa, Splendor

Considering the traffic situation, most of us prefer to use 2-wheelers to commute to the office or nearby places. I am being practical and putting the names of some of the popular two-wheelers which most of us use or have used at some point in time. It will be easier to follow the article

These products, existing in the current market do reveal a lot of things if we look carefully. They all have a good market. Essentially meaning, none of them is a failure.

Let’s see how we can correlate things. What comes to your mind with the mention of each product? Let’s go over them, one at a time

Royal Enfield - Bulky, low mileage, high maintenance, low top speed, low acceleration, high cost, and robust, stability, aesthetic design, durability

KTM Duke - Fast, light, low mileage, lower relative stability, high cost

Splendor - good on mileage, low maintenance, durability, OK on looks, just average with speed and acceleration

Activa - Family vehicle. That should be enough.

When we “design” a product, we should envision how it would be. Excluding the implementation details or the branding details for various tools/technologies. Let’s take a moment and accept, that one product cannot exhibit all the above behaviors. Once we accept that, things start rolling.  The next steps start appearing in front of us. Foremost, identify few things that would stay with the product for long. The features may change over time but the non-functional needs are very important here.

Let’s look at some. Fast response, High traffic support, High Availability, Real-time data updates OR Eventual consistency of data, Is Reactive application a need, etc

We can go on and on. The important part is to know how the product should look like. Is Availability of utmost importance, is real-time data an absolute necessity, do we have to support extremely high traffic, or is the USP of the product the speed of response.

It depends on several factors; one major is the domain where the product is to be launched and used. Is it live air flight support, is it in critical life-support systems, is it banking software or a social networking site. Each domain and where the product fits into the domain’s ecosystem defines the purpose of the product. The traits like high availability or real-time data consistency, etc that the product must exhibit should be driven by these factors.

The point is knowing the latest trends in tools & technologies and applying those to the product may not serve the purpose. Know whether the domain needs a Bullet or a Splendor or an Activa. Then start the design and architect your way through.

This will help in not missing critical traits to be considered. This may also help on saving costs and efforts; since the latest and greatest tools or technologies may not be necessary to build the product. The features they help build may be very low on importance in the domain and ecosystem where the product will be launched.

I am sure most of us already do this, maybe passively. The purpose of this article is not to educate anybody. It’s about sharing thoughts; to pass on and gain knowledge in the process. The purpose is important!

Happy Producting!