Building products to last – Can it increase your valuation?

The inspiration for this article came up from the animated discussion that’s going on at the Product Nation discussion Forum on ‘Customized Product’ – A true Oxymoron.  We all know that customization is bad, and well architected extensions are the way to go. However, I decided to pursue on what ‘well architected’ really means, and what it means for the product business. The answer that came up is that – ‘being built to last’ should logically lead to better valuations. The question is – Does it really?

In the enterprise software world, where one is building large applications, it makes sense to build applications that last. In the consumer app world, it may be better to rewrite when changes occur, but not so in the enterprise world. Some of the best enterprise products out there in the market were built with an underlying framework, with an  aim for extensibility and for lasting for long, through decades of change. The underlying product engineering is often proprietary, but aims for certain business goals. All of these goals point to one thing – built to last. Ravages of market focus changes, technology change, functional changes, version changes, and interface changes can still note disrupt the product capability. When products are engineered for this, it allows the business leadership to change their strategies through time, making the product enduring, lasting and hence multiply. Business goals are not derailed by ‘technical surprises’ but actually allow quick leveraging of new paradigms as they keep coming.

From a valuation perspective can you convince your investor to look at a 10 year horizon of returns because you have a ‘built to last’ product, instead of a 4-5 year horizon that is considered based on current market knowledge? Ideal world? Not really. When they say a product is mature, being ‘built to last’ is what it truly means, and there are great products that do these. It takes some more time, effort, cost and vision to architect such products, but the investment is well worth it, if it’s a long term play in a market.

Is it built for functional extendibility?

Functional extendibility is when the product designers know in advance that certain parts of the product always vary by customer, while the core stays the same, and they architect for the changing areas. Here rule builders, formula builders and tax tables enable customer, industry and country specific variations to be handled through ‘meta data’. Changing leave policies, income tax rules, price rules are some good examples where variation is built into good products

Is it built for technical extendibility?

Often, it is difficult to predict the changes that customers need. With an intent to protect the core, and to easily allow consultants to extend the product, extendibility tools are built into many products. View builders, alert builders, email trigger builders, add on extension screens, add on logic builders, and text label changes are some popular extendibility tools available in good products

Built for version upgrades?

Customers and your market expects upgrades. Upgrades are minor and major. Minor upgrades enable installation without the customer knowing. Major upgrades involve data migration. In the Cloud era, one is continuously migrating customers. How can changes be applied and yet allow versions to keep moving seamlessly?

Built for geographical variation?

The initial product may be built for a country and a language, but as time zones, languages, currencies, decimal place handling and other cultural aspects change, can the product easily adapt?

Built for UI diversity?

This was has become exceptionally critical now. How does one use the same product to handle form factors that keep changing. Responsive design is the current flavor of response to changing form factors, but we can expect many more shocks as interface changes innovations in voice recognition, internet of things and 3D interaction start coming in.

Built for maintainability?

One can build great products with a spaghetti of code, or one can beautifully architect products using techniques like model based development, or well defined objects designed for reuse. The true test comes when a change is required across the board. Well designed code is easy to change and upgrade.

Is it built for technology and deployment changes?

Flavor of the year programming languages, temporarily successful platforms, and nifty user interfaces keep improving, but when it is not possible to rewrite the core system, what do architects do? They usually ‘layer’. They allow a whole layer to be replaced to do new things with new platforms. A very popular product has kept its core intact as it moved from the mainframe, mini, PC LAN, Web and now the Cloud eras. Amazing engineering!

Built for scalability?

Can it work on a laptop for a demo, on the server for a group and also scalable on the Cloud to a very large number of users on a multi-tenant environment? The scalability capability is usually related to the platform the product is built on, where the engineering allows the scalability features of the underlying platform to be leveraged easily.

Yet not over engineered

Somewhere, the engineering has to stop and the economics has to step in. Every layer of abstraction added to handle change also creates a layer of pre-configuration before a product is customer usage ready. Finally it is a question of balancing the engineering to the business goals and budget.

Having been involved in product management and functional architecture decisions in Ramco’s products in the 90’s, and the KServe range of Enterprise products (www.KServeHRMS.comwww.KServeERP.com ) as an entrepreneur during the past 10 years, I’ve seen that  the long range value of being built to last is  often not understood or appreciated fully by stakeholders. With valuations and investment return expectations being short, there is merit in not over engineering, but there definitely a merit  in the ‘right’ level of being built to last. Finally, you are accountable to satisfy and delight your customer and your market, and yet deliver returns to your stakeholders, and being built to last can be your long term ally through ups and downs of the business environment.

Guest Post by George Vettath, Kallos Solutions

About the author

ProductNation Network
  • nitish pandey

    It is a very relevant topic for start ups. This topic can be phrased
    in another manner – “speed matters for long term valuations but which way”. Start ups hire very smart Engineering heads and then tell them not to do engineering – only coding. I will not take stand in this
    comment and let me also add that your article also leaves it in the air.
    Your stand is not clear. It is not enough “somewhere the engineering
    has to stop”. Who decides the “somewhere”? The date of delivery pulled
    out of the hat? . This point can be put like this “Did speed matter in
    deciding the victory between FB and Orkut? Note, orkut had a generation
    lead over FB.”. “Was Groupon Slow? Not sure where it exists at the
    moment”. “Is Path firing it’s slow employees only?”. Is spotify fast or
    rock steady in it’s product upgrades?. I don’t have an answer but a team
    has to take an educated stand and not a wishful one – “we want speed
    AND quality”. If that was so easy no one would ever have to make a
    choice. Right? Good engineering (think, design, review, code, test plan,
    test) comes at a cost and that cost is “time”. Some may say “Well,
    then let’s put in more hours in a day”. Interesting, that’s another
    topic unto itself. As heated if not more.

    • George

      Nitish, you hit the nail on the head when you pointed out that – ‘where should the engineering stop’ is a huge and vital topic on its own. May be it warrants another article like this, or we could use this thread itself to continue. At a broad level I can say that Enterprise products with a very large footprint need to use more of the built to last engineering, while consumer facing applications should be more agile with scalability being the most important engineering item. Looking forward to more thoughts on this.