To make money providing services, you do what the customer asks. To make money providing products, you build what the customer needs.
I realize how tempting it is to lump it all under 'writing software' and calling it a day, but the culture at a services company is very different from a product company, in my experience. Plus it's really hard to give your customers a USP when you're essentially saying 'we do everything!' which you don't, unless you're 5k people big.
"From a company and team perspective I see no problem in doing both: services and products."
Yeah I'm going to have to disagree on this one. Sure it's fine in the beginning, but it's just a major pain once you start having regular release cycles and project deadlines that don't match, conflicts when some employees are more 'service providers' and others more 'product builders' (the two require different personalities, imo), cash flow and compensation differences and many more.
There are many companies who were in this position once, and all that I know made a choice of one or the other (usually product, that's where the money is if the product is good; services is a cost plus business). There were a few talks on this topic on the BoS conference in Dublin earlier this year, it's probably a recurring theme - I'm sure there have been more talks on it over the years.
I have to agree, if your customer base for services does not majorly crossover with your products. I've seen many successful models that sell a high priced product and sell services on top of it. For example, Joyent will sell you the whole cloud and then sell you support for implementation all the way down to NodeJS. I've seen this with other successful (often Node) shops, such as Pivotal and Hashicorp (Golang).
This aligns the service with the product, so there's no reason for the product to lag behind. I myself have tried to create a product while also providing separate services, that can work to bootstrap a product company but is hard to maintain past a few clients.
As another commenter mentioned, if the customer base is different the support questions will be very different. I'd see the product needing at least a separate dedicated engineer and support.
Yeah you're right on that boundary condition - SAP 'sells' software but they make the real money on the 'services' they provide to get that software they 'sell' to work. So indeed I do mean product/service where 'service' is something generic and the 'product' is an offshoot of developing the service (or not even that) but where there is little overlap in customers or even customer profile. Which I think is the situation the OP is asking about.
> SAP 'sells' software but they make the real money on the 'services' they provide to get that software they 'sell' to work
SAP makes "real" money on software. Their professional services business is big but nowhere close to their license business (you can see the breakdown in their 10K), which is why they have a massive network of partners and integrators.
Yes, SAP doesn't do all the services themselves. It's debatable whether in the context of this discussion the service revenue of the partners should be included for comparing. Regardless, I don't think the point of the ration services:product in their profit is material; that wasn't what I was going for. My point was: when services and product aren't symbiotic, it's a pain to combine them in one business, in non-intuitive ways.
Thanks! These are really interesting points. And I've to agree, the mix of the two is already a kind of a problem, although not necessarily a big one. But yes, we do give priority to our service clients at the cost of delaying product release cycles, which is not ideal.
I realize how tempting it is to lump it all under 'writing software' and calling it a day, but the culture at a services company is very different from a product company, in my experience. Plus it's really hard to give your customers a USP when you're essentially saying 'we do everything!' which you don't, unless you're 5k people big.
"From a company and team perspective I see no problem in doing both: services and products."
Yeah I'm going to have to disagree on this one. Sure it's fine in the beginning, but it's just a major pain once you start having regular release cycles and project deadlines that don't match, conflicts when some employees are more 'service providers' and others more 'product builders' (the two require different personalities, imo), cash flow and compensation differences and many more.
There are many companies who were in this position once, and all that I know made a choice of one or the other (usually product, that's where the money is if the product is good; services is a cost plus business). There were a few talks on this topic on the BoS conference in Dublin earlier this year, it's probably a recurring theme - I'm sure there have been more talks on it over the years.