The bread and butter of the Indian IT Industry has been IT Services. IT Services, as the terminology implies, is servicing a customer. A customer states his needs, the IT Services organization makes a proposal to develop / maintain / re-engineer / etc., and the deal is done. As offshoring and outsourcing has matured, customers have become savvy and are putting pressure on IT Services Organizations to compete more aggressively, provide more value and make cheaper proposals with no hidden costs to customers.
IT Services Organizations are in turn looking for ways to improve their margins by creating their own Intellectual Property (IP) and some of them have turned to building or investing in software products.
This articles core purpose is to warn leaders in IT Services Organizations – “DON’T BUILD SOFTWARE PRODUCTS”. But success makes one arrogant, so I suspect some leaders will still build their own products, in which case hire somebody who has made these mistakes before and is familiar with the 8 Truths.
TRUTH 1: Trusting your best IT SERVICES Manager to build your Product
When an IT Services Organization decides to do Products, it is one of their significant investments and guess who they put in charge of it – one of their better managers. A manager in an IT Services Organization is an expert at – scope management, cost management, SDLC, resource management, status reporting, financial management, etc.. And of course he is very good at managing other managers.
Building successful products has little to do with the above skills. Building successful software products requires the ability to provide vision for the Product, ability to work with changing customer and market needs, the ability to build and trash architectures, deal with failures, inspire creativity, identify opportunities you had not seen before.
Most importantly, if you decide to build software Products please find a Software Product Head who has a couple of failures under his belt. And if you find one that hasn’t yet failed, guess what – he will fail on your Software Product !!!
TRUTH 2 : IT SERVICES ORGANIZATIONS serve Customers and their Projects
The real expertise of a successful IT Services Organization is Scope Management – negotiating successfully with the customer on agreed scope and what is not in scope. If you are the Program Manager and your team is on the wrong track or if you have made a mistake, you are taught to revisit the scope. Examine the scope document with a fine toothcomb to compare what the customer asked for with what you have delivered.
If the customer says “The system is not easy to use” then examine the scope to say “Yes, but we did not agree on usability guidelines”, so if you now need “Usability”, it’s a change request and please Mr. Customer, do pay for it.
If the customer says “The system is too slow and it takes 45 seconds for my Employee Screen to come up” then examine the scope document for “Performance Requirements” and tell the customer “Oops !! Mr. Customer you seem to have missed defining Performance Requirements” and what you are asking for is a major redesign. Guess who’s gonna shell out big bucks for it?!
Customer: “The database design is bad”. IT Service: “That is not a deliverable as per scope”.
Customer: “The coding guidelines are poor”. IT Services: “We follow our organization standard guidelines, if you need anything different it’s not in scope”.
… and so on.
Importantly, the cost of changes and mistakes is either borne by customers or at least shared by them.
In the Software Product world there is limited Customer defined scope and there is no fallback position to ask a customer to pay for mistakes. If you have got it wrong, bad luck. Do it again and by the way do it better. And please meet “implicit needs of the product” – customers implicitly expect a Software Product to load within 5 seconds and the usability to be impeccable and intuitive.
This is a culture shift for an IT Services Organization.
TRUTH 3: IT SERVICES ORGANIZATIONS don’t know when to say STOP
IT Services thinking: If we got it wrong, lets change the manager, lets change the technical architect, lets change the Business Analyst. Or better still … lets throw more people at it, lets change the location of development, lets get more funding.
How about just stopping and starting again.
IT Services Organizations just don’t know how to stop or setup metrics to stop. IT Software Products have high failure rates – over 80%. The IT Services Organization is used to 80% success rate. It’s a another culture shift.
This is also related to how Software Services Projects and Software Products are funded. A Customer Services Project even if gone bad often continues to be a revenue earner, till the customer decides to stop development. An investor in a Software Product organization often invests in multiple Product companies and has clear criteria to continue or stop.
In Software Products there is little room for carrying baggage and making incremental changes. If you have got your product wrong, throw it away and restart or just stop. Any kind of incremental changes cost a lot and makes the whole team slower. Your technical team also knows they are building an elephant which will not be nimble, flexible, easy to change or responsive. There is no greater demotivator than a technical team that doesn’t believe in the Product.
A Software Product is developing IP for the future – there will be peaks and troughs of investments and returns and these will typically be in separate time-cycles. This is another reason, why an IT Services organization just doesn’t know when to say STOP. They may well invest much more than a pure-play Software Product Organization would and that too for poorer returns.
TRUTH 4: IT SERVICES ORGANIZATIONS have Forgotten how to BUILD SOFTWARE
IT Services Senior leadership is chosen for Customer Engagement skills, for P&L responsibility, and not for Product vision.
If you are in IT Services, when you resource for a Customer Services Project, you pull out your Gross Margin sheet and see what level of senior / junior people you are allowed. You then go to your Resource Management team to help you fill those resources. You could need a team of 20 or a team of 200, depending on the size and complexity. And that is your focus.
When you develop a Software Product, you first review the market of the Product, then you review its features, then you validate it with some customers, then you do prototypes and proof of concepts, then you validate it again with customers. You convince an anchor customer. Your entire focus is on – are the features right, is my customer happy, is my software maintainable, will I get references to other customers? Resources and budgets are just as important but features and benefits to customers come first.
When a Software Product organization scales the problems grow differently – what is the scope of my product, what are the analysts saying about it, how will my licensing model work for small and large customers, how will I support customers, what is their upgrade path, are there core architectural bottlenecks that will prevent the software from scaling?
The priority for an IT Services Organization remains quality of service, size of business, revenue and margins as it should. IT Services Organizations do not know how to build software any more. They knew it once – now they have forgotten.
TRUTH 5: IT SERVICES ORGANIZATIONS’ HR works on scale and size. They cannot focus on the problem of 1 Employee
The HR team of an IT Services organization has a very clear idea of where and how to recruit, what compensation to give, how to give raises, how to be fair across thousands of people. There are employee benefits, training programs, career growth plans, dual shore movement, etc.
Product teams start by being small teams. They often need expertise in small bursts – speed is everything. An IT Services Organization just doesn’t have the flexibility and nimbleness to take care of the needs of a Product team. Can I out price my 1 core architect and 2 functional experts? Can I provide them with ESOP that is way beyond others on the services side? Can a developer in the product space get paid more than a manager?
Can HR deal with the above? More importantly does HR have the mandate to make such exceptions? What happens when a Product person moves to a Services Project – how do the incentives work?
For a services organization with thousands of people – it is not significantly important to solve the problem of at most a few hundred people working on products. For the Product Organization every decision MUST be driven towards getting a great piece of software to the end-customer.
IT SERVICES ORGANIZATIONS don’t know their TOP DEVELOPERS
A developer in a software Product organization is the go to person to solve any problem. It is extremely unlikely that a Services Organization even knows their top developers. Developers of Software Products may often get paid more, and maybe more relevant to a customer implementation than any manager. I have seen situations where One Top Developer has by himself been able to solve a problem that 15 managers, technical leads and developers could not.
The best Product Organizations will identify and nurture these developers. IT Services organization will struggle with salary bands, designations, bonuses, and the best ones will find workarounds to reward these developers. But that’s just what it will be – a workaround at best.
TRUTH 6: IT SERVICES ORGANIZATIONS don’t know IP management
Providing an IT Software Service to a customer and actually being the owner of the Software Product are very different perspectives. When you own the Intellectual Property – here this refers to the Software Product; it comes with a different set of liabilities as well.
The questions an IT Services company may not ask – Did I leave a security hole in my software through negligence? My design is faulty and my code is badly written – did I disclose this to my customers? If one customer is going to sue me for damages, does that mean all my customers will have to be informed? What if one of your developers has copied code that is Open Source – what are the implications? Etc. etc. etc.
Also, to develop IP, requires a certain amount of R&D (loosely used term here to indicate trial and error, waste and true R&D) – which algorithms will be most optimal? Which UI will be a hit with the customer? Which features will be used the most? And anyone who has been in R&D, knows that investment in R&D does not guarantee results and is often considered waste. R&D needs an open mind and the results are often serendipitous.
Services organizations are experts at managing waste and reducing fat. The Product organization actively produces waste and a CFO or an Accountant is often looking at the Product team (within the IT Services Organization) with itchy fingers to take that number off his xls sheet. The Product team needs to experiment, to create and to throw away; to improve things and hone it and make it better. It is an idea generating machine that needs focus to create more value. It is just such a throwaway piece that a product may need to make it standout, to break through the clutter and the noise in its space.
Related to IP is also a host of copyright, trademark and patents related issues. The IT Services Organization needs to come up to speed with all of this if it is to create software products. The last thing you need is for your Product to be successful and then to discover that someone else is using the same name or you have been slapped with a copyright infringement.
IP is the differentiator that can make your Software Product successful.
TRUTH 7: IT SERVICES ORGANIZATIONS grow through SIZE and PERSEVERANCE
IT SERVICES ORGANIZATIONS are all about growth through replication of success. The growth mantra for this replication of success is to scale through resources, infrastructure, deployment on projects, managing bench, engaging with customers, building competencies, delivering software projects successfully time after time after time. There is also a huge push on sales and winning large deals.
An IT Services business is also conservative by nature. Due to its maturity, it is also a predictable business model. Investments are made in people after knowing the size of Customer Projects that will be won. You assign resources on a won Project and then remove them when the Project is over. When you don’t win the projected business and have a large number of unutilized resources (bench) you either cut salary or you ask people to leave after a certain amount of idle time.
In a Software Product Organization, at the first level, the Product should be able to talk for itself. The word of mouth is critical. For Example, for an internet product to grow, the problem is eyeballs and retention of the end customer on your internet site. The primary focus is not on growing the number of people you have to hire and train. In Services deals you may lose out if you are unable to show the customer your ability to scale up and get office space, people, training, rebadging, infrastructure, etc. on time. In Product you will need to do a flawless job of your product implementation and ensuring your product Roadmap is road worthy. You grow through better products, with backward compatibility, with presence on mobile, with analytics – and many other features around the product along with a science to replicate deployment methodologies and customer trainings.
Both IT Services Organization and Product Organizations scale and grow in very different ways. An IT Services Organization doesn’t have the DNA for software products. So, if a Services Organization chooses to go for Software Products be prepared for some gene level surgery.
TRUTH 8: IT SERVICES ORGANIZATIONS are not experts in their Customers’ Business
IT Services have today moved away from being just technology companies. A website of an IT Services organization shows you industry verticals and domain solutions. Full credit to IT Services companies for providing such exemplary service to its customers. However, the customer still doesn’t expect the IT Services organization to know its business better than itself.
IT Services Organizations have honed Customer Service to a fine art. There are processes and sub-processes to be followed. You have frameworks like ITIL that continually reduce cost of maintenance and support. The focus is on reducing cost of Business As Usual (BAU) activities.
With a Software Product it is different. In the domain of a particular Software Product, customers expect you to know everything. You are expected to know the domain, the technology, competing products, integration with other systems, mapping to business processes, etc. You are expected to know how the beginner users and how the expert users will use and misuse your product.
All Customer Service comes from the knowledge of the customers’ business scenarios and not from a support management framework. The ability to anticipate a customers’ problems and to be able to demonstrate thought leadership are critical to the success of a Product Organization.
Conclusion
If you are an IT Services Organization the biggest mistake you can make is to think that a Software Product is just another piece of software, which it is. But that is not ALL what it is. It is a completely new business. So be prepared to reinvent that part of your team or else …
