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.
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
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!
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.
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!
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!
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
We are happy to announce that ProductNation community gets a special discount of 20% on the conference tickets (registration link / use the code PRODUCTNATION).