6 Steps to prevent your Product from becoming multiple Applications! All in Cartoons!

Somewhere along my long software engineering career, I sat one more time rolling my eyes and clucking mentally that one more product is about to become a series of applications! We are about to create multiple code line monsters that will be demanding and expensive to maintain! Yet, this is what happens in reality in most “Product Companies” that start out with the greatest of intentions but devolve quickly into a morass of effort and expense! Do not mistake me! This is a great problem to have and solve! If you have that many clients wanting your product you are in terrific shape to begin with! You just need to manage it carefully. How do you prevent this from happening? Here are six steps to make sure that this does not happen! All in cartoons! After all, a picture is worth a 1000 words!

1. Nothing can substitute for a proper Product Management Function

All features needed for a client need to go through Product Management. Engineering should not be setting the priorities! Product management can always balance Sales’ priorities with Engineering capacity. Not impossible! Somewhere in the past we have used the rule “If one client requests it, it goes into the Wish List. If two clients request it, it goes into the next release. If three clients request it, it goes into the next build”. But nothing is worse than promises like these. And a proper product management function, run well, can prevent it.

pm1

2. Always separate the Product piece from the Consulting piece

If only one client requests something, it is always good to separate the product from the consulting piece. And make sure that the product has callable features that accommodate the consulting piece separately. Like through an Application Programming Interface (API) or through Service Oriented Architecture (SOA) to make it even more robust. Otherwise your whole product ends up like this

pm-3

3. Create new features out of useful Consulting Pieces

This is the challenge for Product Management. They should always be on the lookout for generalizing client consulting requirements and make them new but customizable features. Consulting requirements that work for client A hardly work for client B. However with some thought and ingenuity, you can generalize the requirements so that it is not only useful for A and B but also other future clients. It will be more code than you usually write as an application, but once done properly, can be reused for many, many clients in the future!

pm-5

4. Minimize Custom Code and Maximize Product features

Over a period of time, one of the worthwhile goals a software product company should have is to minimize custom code and maximize product features! No one really knows the exact requirements for a product unless you roll it out to at least 3 or 4 clients. You realize that you don’t need 50% of the features you thought were hot and you don’t have 50% of the features that clients truly need. This is the process of finding those out! Nothing wrong, but it is just part of the process! However, you need to formalize that process and work that in to your product release schedule. If you think this is crucial for On-premise software, you should try Software as a Service (SaaS) offerings! Even more of a challenge to get features generalized into a bunch of admin settings for a SaaS offering! One more reason to minimize custom code and maximize product features! Like here.

pm-4

5. Find and groom Consulting Partners to do the customization

Writing custom code for clients 1 through 5 may be fine but you need to get out of the custom code business. For startup companies it is always tempting to take on as much consulting revenues as possible, especially when it helps greatly with cash flow. It will smother and kill you, as I have seen it in too many companies myself! It’s a honey trap! Find and groom consulting partners that will do the custom code development as early as possible and get out from the applications business. Requires diligent testing, documentation and training. The sooner you do this, you will come up for air and get on with your future major version releases of your product. Also, from a fund raising perspective, if you look more and more like a consulting company, you have less of a story with investors, especially VCs. Consulting companies do not fit their investment profile too much!

pm-6

6. Re-Architect the Product every few years! It’s inevitable, especially if you are successful

Software products become like the cartoon in point #2 above. It is inevitable! You have a preliminary architecture, you keep adding features, pretty much with duct tape and baling wire. It is then and only then you realize how you should have designed the architecture in the first place. Plus, every five years or so, you have a whole new set of advances in software engineering methodologies, languages and tools. It pays to completely re-architect your product from the ground up! It also goes with the observation that your product has a whole lot of features you need additionally and a whole lot of features that go unused by your clients, anyway. Step #5 buys you this breathing time to go off, have a few off-site meetings and re-think how your product is structured. Plus never forget that you need to migrate all your old clients to this new one, too! Crucial!

pm-7

Successful products evolve! But not without a lot of thought into the process of getting there! Without careful, considered forethought and planning, they can come back as a whole set of applications that can smother and choke a product company!

Software is a great combination between artistry and engineering – Bill Gates

About the author

Nari Kannan
  • KritikaP

    Thanks for sharing this. I especially find the 2nd point popping up too often. Even when the engineering means good, it takes a conscious effort to avoid it.

  • White Horse

    Nice article, well written, finely and concisely told. Thanks for sharing.

  • Srinivasan Gopal

    It is tricky to balance between a platform approach for product(generic) and make your product as multiple applications(specific). I want to add a variant of point 6 ” Refactor the code on regular basis and push developers to write modular code.”

  • techzip

    Well, in a world that is increasingly going towards zero marginal cost of ownership, does it make sense to build products on your own by reinventing the wheel. Besides, understanding market problems and converting to features is a challenge for smaller companies. What is wrong with revenues on product as a service) than licence models.

    • narikannan

      The above advice applies *EVEN MORE* for Product as a service than license models! Please give it a read with this in mind and you will see what I mean!

  • Lakshman Pillai

    Nari, Good point. There are many business models. For those who want scalable product model your advise will be very valuable.

    What do you think about plug-and-play or configurable customization?

    • narikannan

      Plug-and-Play and Configurable Customizations are easier to say than do them! This is one of the biggest software engineering challenges there is! Something people who are experienced in Consulting completely suck at! Their instincts are always to start coding something custom and deliver it! It is neither good for the company since you don’t have a product nor good for the client since it sets them back when a new version of your product comes along! They will have to do the customizations all over again costing money, time and effort!