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.
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.
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.
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.