IT Services vs. Product Companies

IT Services vs. Product Companies

Having worked in the IT service industry people have different experiences. Lots of the differences are obvious but the more I get to understand the rhythm of a product company the more I see the similarities too. Just to get us on the same page, here’s my definition of each type of company.

Service companies (SC) build software at the request of their clients - typically at an hourly rate or on a fixed price contract. The client drives the requirements and time constraints and ultimately owns the output of the engagement.

Product companies (PC), on the other hand, build software too but sell the software itself, rather than their time, to their clients. While clients do influence the features that are delivered and the definition of the requirements the ultimate decisions lie with the software company.

Some of the differences include,

Freedom to change - a PC has a lot more freedom to change the scope and timeframe of software features. Ultimately they run the show and decide what to implement and when to deliver it. Interestingly a lot of what has been written about agile software processes originated from PCs where the freedom to redefine and delay scope are critical. Success with agile practices in SCs is limited.

Solution Longevity – a successful PC invests in a product and reaps the rewards, through sales, over the life of the product. The product will evolve to meet new demands and include new features but the longer it stays around the better. SCs often build solutions to solve specific business problems at a given point in time. There is rarely enough scope to design the solution to last. It’s almost expected that in a few years it will be cheaper to build it again – from scratch – to meet the inevitable difference business requirements and processes. How many solutions built by a SC have lasted 30 years like Microsoft Word!

Incremental Improvement – a SC typically has one chance to get it right. They sign a contract to say they’ll deliver a working solution in 6 months, they deliver it and and may never get to see it again other than supporting bug fixes and small enhancements. A PC's product will go through multiple production releases, each time there is an opportunity to incrementally improve the solution - its architecture and implementation.

SC Earning Potential - the earnings of a SC is limited to the number of productive staff they have – it is not possible to earn more than when all productive staff are charging all their time to a client.

PC Earning Potential - the earnings of a PC is limited to the number of clients that buy their software – this can range from nothing, if your product sucks, to heaps, if it doesn’t.

Great Ideas – implementing great ideas (that attract/impress clients) in your software could dramatically increase a PC’s potential revenue – for a SC it will simply mean the client pays you or at best asks you to do some more work for them.

Some of the similarities are also interesting though.

Pressure to Deliver – both types of companies are under pressure to deliver. Whether it’s because a client is freaking out it’s taking too long or your sales team are screaming at you for the next killer feature to sell – building software has its tough side.

Compromise – pressure to deliver, limited resources, staff skill levels… all these things conspire to ensure you will always have to compromise, take shortcuts, repeat code, etc. that’s just software. There is no perfect solution and you could always of done it better.

People are Important – it’s true that for any company people are a crucial part of their success. Motivated, valued and supported staff will be way more likely to be productive, responsible and happy.

Supporting Your Code - PCs and (most) SCs both have to support the code they write. This means that code quality is an important factor.

Specialisation – as any company increases in size there is a tendency towards specialisation. At Intergen it happened across the different Microsoft products – we had specialists in ASP.NET, SharePoint, CRM and NAV and once you became associated with a particular product it was hard to move on. This is symptom of the increasing complexity in software – no one person can know everything and as any company gets bigger the only way to scale is for people to become experts in a given area.

Some things that might be differences or could just be from my experience only.

Testing - PCs take testing more seriously. At Xerox, testers are involved from very early on in the process and throughout the process. If a tester says it’s not ready to go live it doesn’t go. At SCs I’ve worked at testing is either pushed on to the client or internal testers are asked to stand at the software train station and check everything’s OK as the express races past (but it’s OK since the developers have already tested their code! Yeah, right.).

Work Units - since the earning potential of a SC is directly related to the number of staff they have (unlike PCs) it is tempting for SCs to depersonalise their staff and treat them as “work units” – ordering in more when they have the work and getting rid of some when the work dries up. I’m not saying this doesn’t happen at PCs but there is more chance (especially in the early stages of a PC’s growth) that employees, regardless of their position within the company will feel a sense of common purpose.

Personally, I've always found PC work far more satisfying. 
Not without its stresses, at times, but that feeling that you're part of a greater good, and empowered to innovate, and actually make a difference has always felt stronger with PC projects I've worked on.

Differences are so not simple. Take the longevity for example. If you work on big projects maintenance phase is usually very long and often very intensive. Actually many systems which have many of so-called change requests. Sometimes these are minor changes but sometimes they could be easily compared to original development.

I look at it a bit differently - at the development level working on custom software is more like working on a series of smaller products. The biggest difference is of course in product management. If you work on products it is located inside the organization, if you work on custom software it is outside.

Experience with the solution longevity may be skewed by working too long in Govt. - the number of times Millions spent on a project to then drop it and do something different is scary. This is rarely an option for a PC - once you've committed, pulling out could be a death sentence. At the Govt still get to spend our taxes on the next project! But I get your point - there are always exceptions.
In this particular case our problem was the app was really crappy so every change cost us a lot in terms of paying technical debt off. That's why we wanted to terminate maintenance of the system. Client's answer was "We don't make money on this app really, but our competitors still maintain theirs so we can't witch off this one."
But I agree that on average software products have longer time span than custom application.