Oil and Water? (Software and Services)

Scott Francis
Next Post
Previous Post
Giff Constable’s article addresses this age-old divide from the point of view of a software vendor.  In fact, I’ve previously written on this topic from another perspective, advising services companies to reconsider getting into the software business unless they can:
  • Attract outside investment.  This acts as a proof point that your product effort has merit outside the four walls of your office.
  • Separate the financial risks and incentives (form a new corporate entity).  This protects your successful consulting business from being stripped bare by the software development effort (and later, the software sales effort). And…
  • Enter a market that doesn’t already have a good software solution.  In such a market, the product has time to mature through iterations and customers feedback (assuming you are mostly bootstrapping it)
  • (alternately, get behind an open source project, which is a good strategy for reducing the cost of your complements)
Giff puts forward some really good advice, but it is all from the software perspective.  I’ll give my reactions to each bit of advice here, as well as my take from a “services perspective”: “Keep it separate” – this is great advice, and mirrors my advice to services companies who want to build software products – keep it separate.  Giff doesn’t go into great detail about why, but if you keep it separate it leaves your financials a lot simpler, and makes it more clear how much capital your start-up has required to get lift-off. In fact, if you do form a services arm within your firm, you should look at the profit they generate as investment capital and reward them with equity accordingly.  Instead, product companies often resent their services counterparts and treat them as second-class members of the company. “Focus” – If you get pulled into consulting work this will detract from your ability to deliver product.  I agree.  You need to have “someone else” deliver the consulting – this can be an employee of your separate Consulting LLC, or it can be an existing firm, or an independent contractor.  But if possible, best to avoid it being your development team.  And I mean that, sincerely, as a services guy – we want those product guys focused on making the product better. “It is hard to turn down money” – Giff’s argument here is that the consulting revenue is tempting, but misleading – leading your firm away from its product software roots and into the world of becoming a consulting firm.  If you don’t find really good help, Giff’s imagery will be correct – subcontracting only works if you have really GOOD subcontractors.  Probably better to let them work directly for the client and get a royalty or finder’s fee.  But I disagree that if you take on consulting work that you also have to pick up a sales staff and project managers-  just stick to a small number of experienced industry veterans who can sell themselves based on their own credibility, and who can execute projects with little oversight. “Conflicting Team Goals” – If you didn’t turn down that work (because you needed the cash) then you’ve hired people… now what?  Giff writes:
When you start talking about the glorious future of the business (i.e. the product), these hires start to question, “wait a minute, am I irrelevant to this future?”  That doesn’t help morale.
Great insight actually – this is exactly what can happen if you don’t understand how to lead a services team.  If there is an obvious services business alongside the product that you are building, then it should be obvious what the role of that services team will be in the future:  to enable partners and the channel to be successful using the product- a small number of experts to grease the wheels.  The next point he makes is a good one:
Further, you have a problem in your incentive structure.  Your business is structured like a product company, with a focus on equity, but you now have a business unit which should be structured like a services company, i.e. focused on cash flow.
Consulting doesn’t have to be cash-incentive based if you are willing to share software-company-equity with them.  The problem is that the software guys often don’t want to do this.  There are certainly consultants out there who would prefer cash over equity – put those guys on a contract, don’t hire them. Giff’s final point on this one is that you have acquired a morale problem: your products folks are now stuck working with clients and hate it, and the client staff is jealous of the product team.  To the first part, keep your product team focused on product.  To the second part, client staff are “jealous” of product staff at software companies because software companies constantly make it clear who they care about most: the product guys – jealousy derives from being undervalued. Distraction to Death – yes, if you keep the consulting in-house, inevitably a fire-drill will distract your product team unless you firewall things appropriately.  And, as Giff says, “Client services work is difficult.”  I think most folks on the product side of the house fail to understand just how difficult client services work is.  Often difficulty is judged by the complexity of the code.  But in fact the difficulty is in managing human expectations, emotions, and politics. And rarely does anyone take into account the sacrifices services teams make to travel to client sites and leave behind friends and family. The wrong investors – Giff’s point here is that VCs and experienced Angel investors will typically not want to invest in companies with substantial services revenue.  “They want a scalable business, not one that requires an hour of work to get an hour of pay.”  This is a bit of a pet peeve of mine, that services businesses are considered to be “not scalable.”  There are multi-billion dollar businesses that would argue that services revenue is pretty scalable… and profitable.  But to Giff’s point- it is true that services companies get an hour of pay for an hour of work (or close to it).  Unfortunately for software companies, they often get much less than an hour of pay for an hour of work (lose money)… There’s a dirty little secret in software – very few software companies are profitable on their software business.  I believe that most enterprise software companies now make most of their money on services rather than software.  Sadly, those services folks are not looked at as investors in the business, but as a drain on the business (in fact, Giff’s article makes that point: a drain on focus, morale, and priorities). The real issue is that if you’re running a services business “right” – you don’t need outside investment.  The company organically funds its own growth.  From another post on Giff’s blog:
“the running joke [on raising VC] is that as a first-timer, if you don’t have a prototype don’t bother, then if you don’t have traction, don’t bother, then if you don’t have revenue don’t bother, and once you do have revenue – why bother?  ” — adityac, in comments of my last post
Exactly the issue with a good services company.  So investors can’t get good terms from services companies, and the services companies would be crazy to take the terms investors would want (to make their investment worthwhile).  As a result, services companies make for pretty unattractive investments unless the investor is looking for more mundane returns.  Services companies also won’t “pop” the way a service like Twitter can pop – because you *are* constrained by the number of work-hours you can deliver, and the number of skilled consultants you can bring into your firm. Giff concludes with this:
So a consulting business can’t create a product? That is indeed my argument: a consulting business has the wrong structure, processes, priorities and people involved to pull off a great new product.  However, a consulting business can be fertile ground for good *ideas*, because you are exposed to lots of client pain points.  If you want to be effective at creating that idea (or whatever it pivots into) and bringing it to market , you are better off spinning out a new company with a small, dedicated, product-experienced team right at the start.
Which matches well with my thoughts on the subject – in fact, at BP3 we’ve been exposed to quite a few good ideas for product.  But I’ll add another angle to this – it isn’t just about giving your product the best chance it can have of getting to market successfully – it is also about protecting your services business from being gutted by loss-leading spending on the product side of the house. I’ve seen more than one successful, profitable services company fold because they raided the cash cow to build and market a product – unsuccessfully.  And in the few cases where they raised outside capital from VC’s, the dilution to the services team was extreme. Better to keep these two organizations separate and let the investors have a bigger stake in a separate firm. Really good, thoughtful post by Giff, and after reading it a second time, I’m even more impressed at the insights. At BP3, we’ve often been pressed by outsiders and our own team members to consider making product development investments – but so far we’re focusing on building the scale we need in our services business.  If we do something product-oriented we want to make sure it plays to our strengths and can be carved out as its own entity. Mostly, I like to think we’re mature enough to recognize that we aren’t ready for the distraction of splitting our focus on building a great services company focused on business process.
  • Pingback: When it comes to startups, products and services don't mix — giffconstable.com()

  • Thanks for writing this up Scott. A lot of wisdom here. I probably could have boiled down my entire post to the message “please just keep it separate!” — and of course I'm talking about the early startup stage. If you have a product with traction, and then create a services arm to support and fuel that product, that's completely different.

    Also agree with you that an experienced team can be both rainmaker and execution, rather than needing a separate sales staff. Good point missing in my original piece.

  • sfrancis

    Ah well, just saying “keep it separate” wouldn't have generated all the discussion! I did think it was interesting that I you wrote the whole thing from the software perspective, but at the end came back to “So a consulting business can’t create a product?” – Which, if you start with that question, puts a different spin on your article.

    I think even when companies have a product with traction, they still have trouble managing that services arm – the morale issues, the distraction, the differences (potentially) in compensation. There's a way to run these services arms successfully and without that friction, but I've found that the folks running sales and product generally don't want to play it that way – to everyone's detriment. I think if you can't treat services as a valued component of your team that you're really glad to have around, then you should not have a services team. Interestingly, BazaarVoice in Austin is one company that has the proper mindset/outlook on services within a software company – perhaps because they're in an ASP/SaaS model.

  • Pingback: Love Mark Suster’s Blog on Crappy Little Services Companies » Process for the Enterprise()