1) Do not let your roadmap serve as a means to alert your competition!
One of the common sources of competitive information is the presentations made by product / engineering teams to the external world. This includes your customers, and you need to be particularly careful if you are not the only vendor for your service, which is quite commonly the case. Often, the sales team may ask you to present your roadmap to help close that deal that your organization is so close to winning. Or, you may have to present a roadmap to keep high levels of customer engagement going. So while you cannot avoid these situations altogether, and you may not be able to always get your audience to sign an NDA to listen to your sales pitch, the only option  that you have is to consider what you want to reveal.

Suggested rule of the thumb is to restrict disclosure to those features on which you already have a first-mover lead so you know that competition cannot beat you in terms of speed of hitting the market. It is a safe to assume that if any feature really excites the customer, they will check out if the same in the market. And if you are not sure when you are going to deliver it, chances are high that your customer could get it from your competition.

2) Do not let your roadmap close your mind to a customer request!
Do you feel that you could have achieved a closer relationship with your customer, but for the fact that you have to refuse features because as per the engineering team the requests are “not-aligned-with-the-product-framework”? If you believe that this is indeed the case, then your organization is not getting the true worth from the roadmap exercise. Customer’s are increasingly showing reduced tolerance for technology constraints, and are willing to go to competition for requests that cannot be serviced by their existing partners. Competition is typically too happy to play along in terms of servicing requests, which your team believes ‘unreasonable’ allows them entry into your business. I have seen cases where business was lost due to disagreements on roadmap alignment, even though the effort involved was relatively insignificant.

Suggestion: Try to use roadmaps to demonstrate what you can do, as opposed to defining limits of what can’t be done. In many cases, this may be more of a mindset issue, than a genuine blocker.

3) Can you deliver on your roadmaps?
This one would be familiar to many, and typically hits you a few months after you had made that last perfect presentation. Customers tend to forget that (a) roadmaps can change due to changing business priorities, and (b) the farther out you go, the lower is the chance of getting the feature.

Suggestion – In general, if you see a high level of interest demonstrated by a customer on a feature that exists on your roadmap, but you have no immediate intention of building, then it is better to inform that the same is still in the planning stage and you would be happy to engage more with them in terms of understanding the requirements in detail, before slotting this in a release. In case this is a prospect, then of course, you can consider adding this as a carrot for them to close the deal!

4) Know your competitor’s roadmap!
Before you present your road-map externally, try and see if you can get some information on what the competition has. While this is not easy to get, chances are that they may be slipping on many of the hygiene practices.  You should check out with your sales team, and quarterly business review meeting are a good time to do this.

5) Continuous follow-up
Last but not the least – please keep in mind that your customers will remember your roadmap. Not the entire presentation, but that one feature that they so liked. It is important to note what they liked and keep them engaged on that point. The one thing that you really do want to avoid is that when you (or the next person from your organization who meets them) forgets to talk about this altogther. Don’t let it happen to you.

I believe that this is a warning sign for OPD companies and they need to evolve their offerings or risk losing their identity with the more generic software OSD vendors

Before I go further, as per commonly used terminology, Offshore Product Development (OPD) refers to transferring design, development, testing and other related services of the product development life cycle to a third-party service provider. Some companies make a part of a product, some do re-engineering, while a few develop an entire product.  Offshore Software Development (OSD), on the other hand,  is customized application development or services for a company’s own usage and is usually non-distributive in nature—this could be customized application development, application migration, software functionality testing, packaged software implementation, etc.

Common industry understanding is that OPD needs teams that are more skilled (and are paid higher) than those that work on vanilla OSD. In terms of development, OPD is considered more difficult. Usually, in the case of OPD, your customer is the open market so the product has to be flexible enough to be used across user-base. In case of OSD, you know your users well and can interact with them, this makes the job a lot easier for the developers involved.

At first indication, it would seem natural that companies with a niche (and more complex) offering would have a higher price & higher margin business than that of a plain vanilla offering. The flip side would be niche players would probably have a smaller size as they are not attacking the entire market. However, while the latter part (about smaller size) appears to be true, when it comes to profitability it appears to me that most OPD companies have lesser profitability compared to their OSD counterparts.

Lower OPD profitability: Possible reasons

What could the reasons be? I think this could mean one of the following:

1) The actual work being performed does not command higher value, in the eyes of the customers

This could be the case in case there are projects in which a large part of the product specifications are being provided by the client. In such cases, the clients may genuinely feel that the value add of the OPD is not much higher as compared to the other OSD vendors. While the client may still be willing to give business to OPD vendors due to other reasons e.g., the development tools & automation processes that products need, but may not be willing to pay much higher in terms of billing rates. Should this be the case, then the way out for OPD vendors would be to move up the value chain and be able to get work that can actually justify higher billing rates and higher margins. However, this is exactly what OSD companies have also been working on, so that question is if the OPD companies would be able to grow fast enough to maintain their separate identity.

2) The value addition is not significant enough, and is being offset by higher employee costs

The other reason could be that there is some value addition and higher costs being charged by OPD players, but it is not significant enough and is offset by higher employee costs. I don’t have the data to make a conclusion on this, but from a pure financial perspective it probably means that the industry needs to reduce costs.

3) The OPD players have not learnt to manage the operating costs as effectively as the established larger players:

As per this hypothesis, OPD companies are actually doing higher end work, and are getting higher billing, but their operating costs are too high. This could be because of lack of scale, ineffective business practices (e.g., administrative costs, building lease costs, sales & marketing, etc.). For example, most of the larger OSD companies operate out of their own campuses and their operating costs are spread over a larger base.

Many possible reasons, One likely outcome

Irrespective of which is true, should the trend continue, these businesses runs an imminent risk that investors would soon push the OPD businesses to match the operational practices (and hence, the profitability) of the OSD players. This would allow the investors to achieve higher valuation of the business, at a low risk, as the OSD model is a relatively proven model in terms of margins and scale.

The investor push can be along one of the 2 paths

a) Dilute the OPD offerings and move to OSD model: This could also include a possible sell out to existing OSD players, who can then use their operating practices to bring down the costs to achieve higher profit margins. The  expectation would be that “cloning” the OSD practices would allow OPD companies to earn at least a similar (if not higher) valuation than what they would get by being alone.

b) Create new product offerings to support higher margins: As I see it, this requires some out-of-the-box thinking. I have put some of my thoughts into this. The last section of this blog captures my thoughts on how OPD companies can create new offerings to boost sales and margins.

OPD: New approach, New offerings

It is probably fair to say that currently, the OPD industry is a slightly modified version of OSD.  Except for size - where the largest OPD player is a fraction of the size as compared to the large OSD players. 

Otherwise, both have the same (engineering-centric) roots. Both have largely similar sales differentiators – revolving around development processes

Culturally too, most product teams at OPD companies comprise essentially of engineers, who have little idea about the business of the product they develop e.g., in which geographies their product gets sold in, the profile of the customer who buys them, pricing options, nearest competitor offerings & their strengths and weaknesses, the maintenance and support costs, etc.

This is not how a product company should be. Walk into any “true” product organization, and you will notice that irrespective of job functions e.g., engineering, QA, support, even finance and accounts would know about enough about their products. Further, this difference is highlighted in each interaction with the OPD organization, which validates the customer’s impression that they are dealing with a bunch of techies. Once you are positioned at that level, that moment is not far away when you end-up negotiating on the per hour billing rates of your resources. You are now in the commodity business. You have already lost the chance to position yourself as an OPD. You are now competing with OSD players, without the benefit of their size, scale, business practices, etc.

The question that OPD companies are probably not asking themselves hard enough: What is it that we do as an OPD player, than non-OPD software development companies don’t or can’t do? As of now, the answer probably is very little. And this is one of the risks for most OPD companies who do not change their positioning carry.

OSD companies are also entering the OPD domain. They don’t seem to be encountering too much of an entry barrier, and are already providing competition to established OPD companies.

OPD differentiators: Shift focus from client’s top-line to bottom-line

So, how can OPD companies differentiate themselves? Is there life as a separate OPD companies, or is OPD going to merge with OSD?

For starters, I think that the biggest change that Indian OPD companies – who want to break out of the mold – need to do is to stop pitching their engineering skills. For most Indian companies, this is now almost taken for granted.

Instead, the mantra now needs to be on improve the bottom-line (profits) as opposed to the top-line / costs.

How to do this? Lets consider a few scenarios to see how this may be possible:

a) You see a product company doing well in US markets. Do you think you can strike a deal to profitably sell this in APAC on a revenue sharing arrangement? The company would be more than willing to invest in you. In course of time, this will also reaffirm that you understand the domain. You can package your engineering services at that stage.

b) Are you willing to sign-up as a re-seller for the product company in the areas where you have local offices? Many product companies do not have an office in APAC, but are looking to enter the market. Benefits:

• Your team gets trained by the product company
• Your organization is now ideally positioned to hold the Product Manager role for the development team. This person not only provides inputs to the development team, but also engages with the client on product requirements, feature requests, roadmap etc.
• You contribute to the new release. You can start contributing to the testing of the product d. In due time, you start taking ownership of the engineering deliverables

c) Can you provide product implementation / consulting services for new sales? Again, product companies should love to talk to you, as this helps them sell better. It provides you with a natural entry door into these organizations. They know that you are an OPD company, and the fact that you also help them generate revenue, means that your interests are naturally aligned in terms of understanding their business as they do.

d) Can you provide sales support with a revenue sharing model? Again, another way to start discussions. OPD companies should move forward with a complete services offerings. In terms of costs, I don’t think this adds to much, as a lot of roles are either common or shared across products. I am noticing that large OSD companies e.g., Wipro have a lot of reseller relationships with their software vendors, and I think that it is a good strategy to start building relationships with the product companies too.

Ideally the product team should be able to perform the following roles: -

• Product Sales – the OPD company should be the local reseller of the product across geographies
• Product Customer support
• Product Marketing & Branding – the OPD company should be able to provide product branding / marketing support
• Product Documentation
• Product Management
• Product Engineering
• Product Implementation

Once OPD companies start interacting with their partners on a more holistic, 360-degree, engagement model, their relationship will naturally extend to the next level of depth. This will help them improve not only the value of the relationship, but also the quality of service that they would be able to deliver

Coming back to the OPD industry. I had all along assumed that since the OPD industry operates relatively higher up the value chain – as compared to the generic IT maintenance projects – this industry would command relatively premium pricing and higher margins. 

 Product development typically requires a more considered and generalized approach to problem solving and product organizations are relatively more particular about their hiring.  Average compensation structure in product companies is also typically higher than those offered by IT services companies. On the other hand, most product organizations have a smaller team sizes and are more sensitive to attrition.

 So, I was a little surprised when I searched the web for financial results of the players in the OPD segment (e.g., GlobalLogic, Persistent, Aztec, R-Systems, etc.) vs. Generic IT Services (e.g., Infosys, Wipro, TCS, etc.).

Net profit margin for select OPD players:

8 % (R-Systems), 16% (Aztec), 17% (Persistent) 

Net profit margin (Generic IT Services, for 2009 ):

18.6 % (TCS),  19.5% (Wipro), 28% (Infosys)

The verdict: Generic IT Services companies beat the OPD companies comfortably, despite significanty higher business volume (at least an order of magnitude more than OPD companies). If you factor in the conventional wisdom – as size grows, you start hiting the lower end of the market, adversely affecting profit margins - then the effective difference in profit margin is probably even higher!

How do you explain this difference? I can think of the following reasons:

1) Current OPD players are not really operating as high up the value chain as is perceived – This suggests that a large part of the product development is basically around implementation of product specifications, which may be fundamentally not very different from other IT services. I don’t know if that is indeed the case, and would probably require project-specific data to identify which category of projects are more profitable than others.

2) Lack of economies of scale – All OPD players are relatively much smaller in size - about USD 100 million or so. Does size play an important role in increasing profit margins? Does it help spread the costs of key resources over different projects. That could be a reason. Not having an expensive resource fully billable could directly affect the top-line. Having scale probably allows companies to ensure higher utilization of key resources.

3) Inefficient business practices – This relates to things like (a) managing internal costs (b) resource allocation practices (c) alignment of sales with delivery etc. These can also quickly add up to the costs without driving up business.

Looking at the difference in profit margins within the Generic IT Services industry, Infosys for example, has by far the highest profit margins are compared to TCS and Wipro. To me, this is an example of how companies in the same business – that too in reasonably mature industry domains – can still differentiate themselves. So, could it be simply be point (c)?

Also, it follows that if the reasons for lower profitability is either of points (b) or (c), then OPD companies could soon be an acquisition target for the other Generic IT Services companies. These companies can potentially squeeze out more from the same OPD business, by applying their best practices from the Generic IT Service domain?

I had prepared this presentation for a group of well performing & experienced project managers – who were currently managing engineering product development projects.

The purpose was to introduce them to the domain of Product Management with an objective of (a) providing information as an alternative career growth option (b) improving awareness on the domain and how this can help them manage projects better, and (c) from an organization’s perspective help in enabling higher level of product ownership across the team to help sustain higher customer satisfaction and business growth

I’ll start this article by sharing a couple of rather interesting facts (related to hospital information system (HIS):

 1) There are significant changes happening in HIS lanscape - in the way technology is enabling end-user’s (read patient’s) participation in terms of managing their information. Large scale healthcare IT initiatives are underway – led by organizations like Google Health (www.google.com/health), Microsoft’s Health Vault (www.healthvault.com) and Open Source initiative – Indivo (www.indivohealth.org). 

The key trend to note is the change is who controls the patient data. The patient’s medical record, which has so far been managed by hospitals, now seems to be moving out to the patient. The technology being developed for this is clearly “disruptive” and as the definition goes, has the potential to change the business in the way that the market does not expect

2) Existing & established healthcare IT players have largely missed out on these changes.  

A quick look at some of the top healthcare IT companies -  Meditech, McKesson, Cerner, Siemens, iSOFT – shows that these businesses continue to focus, almost exclusively, at B2B level i.e., hospitals/healthcare professionals. A look at the Home Pages of any of these companies substantiates the point. These companies continue to highlight their latest hospital acquisition or the new features in their next release.

If there is any product strategy that is being developed to target the patient directly with new product offerings, it is well hidden. 

The annual report of Meditech for example, does not mention this as a risk factor, and instead talks about rather routine issues of changing healthcare regulations, patents, etc. Personally, I doubt if the risks section in the report has been updated in the last few years. As a mild exception, I understand that IBA-iSOFT – a non-US based company, which has typically tried to be ahead in this industry – has recently taken the first steps by created a Consumer division to look at this area. However, it appears behind in terms of actually executing a planned strategy.

Now, isn’t that surprising that the next generation of healthcare IT software is being led by virtual outsiders to this industry? Why do Google and Microsoft continue to invest large amounts in an area that continues to be ignored by existing players?

HIS industry Low on competitiveness; High on margins

As I see it, there are some very good reasons by cash rich companies like Microsoft and Google are interested in this domain. At the risk of over-simplification this industry can be summarized in two phrases – low on competitiveness, high on margins

How the changes may affect the business model for existing HIS players

a) Hosted SaaS application. Moving to pay per transaction vs. upfront license fee

The basic ‘existential’ assumption for the current HIS players all along has been that the hospitals will control & manage the patient data. And that hospitals will pay for the same.

Not any more!

The new developments that are happening are basically around building a hosted, SaaS based, healthcare platform – on which 3^rd party vendors may build their own “value-added” applications. The platform allows any user to upload and maintain his/her personal health records and use this as the central data repository. Microsoft is developing hardware device drivers that will allow hospitals to directly connect their medical equipments to upload patient data into these platforms.

The race is on to ensure that as many patients as possible, sign up to these platforms. The valuation of the platforms would be driven by the number of users who choose to sign-up

b) Increased competition, no vendor lock-in

The platform allows 3^rd party vendors to build applications on the platform and offer to hospitals. That’s great news for hospital, as they can easily move across applications without having to move the underlying patient data.

Existing players may evenutally be forced to develop plug-in applications on the platform. Slowly, I believe that they will be marginalized out of that space too, as the lucrative applications would probably soon become as an embedded offering on the platform itself.

c) Reducing healthcare costs

Overall, the average spend per patient per hospital would drop significantly. This is expected to help increase the user base and more and more hospitals sign-up for the service. While this may be good news to all of us, the point is that the existing players do not seem to be responding to the writing on the wall.

Impact on revenue stream for existing HIS players

The platforms are already signing up on hospitals and users. Assuming status quo, the impact on existing HIS players would be quite significant – almost a triple whammy in terms of:

- Reduced license fee

- Reduced maintenance fee

- Higher R&D / transition costs

For many players who have not invested upfront in new technologies, it may already be too late. For others, I think that there is still time to respond with a viable product strategy.

Is all lost for the current HIS players?

As I said above, probably not. Or so I think. Assuming existing players respond fast with a well thought out product strategy. The leader in this space would command a significant market valuation and would also be in a strong position to negotiate a possible acquisition with one of the biggies, should it come to that.

My current assessment:

i)      Functionally, the platforms are still in an early stage.

ii)     One of the biggest challenges for even Google and Microsoft (inspite of their vast resources)would be in adding patient data. Manual entry is probably not the best way. And uploading scanned documents means that the contents cannot be intelligently interpreted by the software. This is where current players, who already have patient data in electronic format may have an edge, should they choose to compete

iii)   US-centric. The platforms are largely US centric and may not have sufficient local knowledge of other markets. This means that non-US companies may have relatively more response time than US companies