What Should You Do with Your Crappy Little Services Business?
techcrunch.com
techcrunch.com
A year ago, I was getting impatient. I wanted to find some funding so that we could more quickly develop the products that we were ready to develop. What I found instead is that businesses like mine are the bastard children among entrepreneurs: it doesn't scale, it probably won't make millions next year, it's not sexy, nobody cares.
So, then I decided that the next best thing would be to talk to a bunch of business advisers, and see if there was a way to ramp the business up more quickly. All of them save one failed to "get" what the business was about, and gave us advice that amounted to, "don't do what you're doing, do it the way everybody else does instead."
I went through a short period of disenchantment and self-doubt, until I started looking at where the business had started and how far it had already come in just a couple of years. I took a second look at things like advertising and realized that, despite throwing a lot of money into marketing and the like, word-of-mouth had continued to be the number one source of new customers by far. So, the advertising and marketing budget got slashed to close to zero, and we doubled-down on what we were good at: taking care of our customers. I picked up another person who brought some more really great talent with him, and things are pretty great all 'round now.
I'm OK with slow growth now, and not getting a piece of the sexy SV action. I think we're growing like a freight train: r-e-a-l-l-y slow to start, but almost unstoppable once we get going.
In a few years, maybe I'll be able to do some seed stage funding of my own. That would be fun, and I'd love to focus on the people that so many others are ignoring: those that are passionate about their business, and want to reach as many customers as possible, without giving up all of the qualities that makes them unique.
The idea was to do enough services work to fund living costs while working on product development.
But the problem is that customers are (understandably) demanding when you do paid work for them, so you spend your entire time doing client work and never get to focus on the product development.
So you hire staff / team members so you can focus on the product development.
But then you have to spend even more time managing a team and running the business. So you still never get to spend any time doing product development. And at this point, it becomes difficult to change course.
Based on my experience, I think it is very difficult to build a product when doing client services work. It takes disproportionate effort to get and stay focused and you have a mountain of distractions. The services work becomes all-consuming.
[edit for clarity]
* Contracting stays at 50% of our hours (or less.)
* Contracting is always hourly. Any overtime or extra hours mean 1:1 extra funded hours for product.
This approach has a lot of nice side effects. The tighter supply of your hours will drive up your hourly rate (if you're good) and will maintain the financial motivation to put out some awesome products.
I have had the same experience and strongly agree with your assessment. Furthermore, this seems to be true even if the customers are more or less directly funding the incremental development of the product. Somehow, their specific needs, slight customisations and tweaks, support thereof, etc. expand to fill up available time.
There's so much for me to say it's difficult to limit the scope. Most of this was dead-on.
For me, I find the services sector to be a huge weight around my neck. Yes, those in the services sector look longingly at the product guys and get easily seduced over there, but the story is a bit deeper than that: if you're in services, you either scale by adding people, increasing rates, or adding something else to the mix. Running large groups of people may be fine for some guys -- I've never been a fan, at least in the services environment. Quality is always an issue, as is divided loyalties. Prices can only go so high, so you're left with either hiring more folks or selling a product. That's the situation whether your Andersen with a huge workforce or Daniel Markham with his mom-and-pop consulting shop.
I know the people running the 50-person shops, the 500-person shops, and larger. It doesn't look like so fun from where I sit. Every person you send out to help somebody is a potential stick of dynamite waiting to go off and ruin your reputation. Clients say they want one thing but actually need something else. Any time you have lots of people, you have lots of headaches: sickness, death, family issues, personality conflicts, life values conflicts, etc. As you grow, either in income or in people -- or worse, in both -- the government gives you more and more hoops to jump through. Meh.
So the allure of products is not limited to the big guys -- there are logical reasons why anybody in the services business needs to augment their income.
But the core of his thesis is correct -- products are a completely different world. What looks like an easy switch is anything but.
These tools are built from what you're already using to address the problems that your customers are experiencing.
Then solidity, test, and package them, and use them to reach other customers in your target business.
Even if the products don't work out profitably (or if you decide not to sell them separately), these products still solve issues you're having, and to deliver your services more efficiently.
He talks about "building meaningful businesses that are both fun and economically rewarding". But the great majority of services businesses are not fun and not that profitable.
And those I know with "product envy" aren't generally motivated by "crazy valuations" and acquisitions. Rather, we have a burning desire to make our own mark and the best of our potential. Pouring our creativity into another person's vision is rewarding to a limited degree.
2 - "Productize" your service, making it so any idiot can run it.
3- Instead of selling the new product, keep charging for the service fees but hire people in house to run the product.
Edit: Now you can charge $200/month instead of $19.99, and one person can probably run 30 accounts.
Examples: ReachLocal and Yodle.
While some service companies have made the transition, I think it is a very different focus and mindset. While some companies like 37signals have made transition, it is not easy for many.
- Service businesses in the tech sector have grown into multibillion-dollar valuations, but often take decades to do so. Infosys and some of the other large Indian outsourcing companies spring to mind.
- There is a well-established pattern of enterprise software product companies turning into services businesses (IBM), or at least deriving a majority of their income from services revenue as margins on software products/licenses decline (Oracle, starting in the late 90s).
1. Sell product to enterprise.
2. Realize there's more money in consulting to them.
3. Continue development of said product, but now motivated not by ease-of-use or effectiveness, but by how much it can add to your consulting business, resulting in the bloated, out-of-the-box unusable enterprise software that we're all familiar with.
For example the product starts out simple but grows in complexity, so suddenly you notice the 1 hour install that your consultant used to start his usually 4 day client customisation work with has turned into a whole day and you're now charging for 5 days of consultant time. This leads to the perverse economics that writing an installer, which costs you money in dev time and impacts the development schedule, will actually lose you money. So the installer never reaches the top of the priority stack until it's a real pita as you can recoup the costs compared to the lost opportunity of not working on a new client module.
Also it's the client themselves that demand the extensibility of software. It's almost impossible to perfectly model someone's unique workflow in any non-trivial system.
Say a client has a risk rating they give every new project. Obviously they want to be able to record that rating in their project management software. And then they want particular directors emailed when that project is moved from tender to won. And then they also want accounts notified. And then they want a team auto-assigned. And then, and then, and then.
Enterprise software has to be flexible and extensible for many businesses. Because virtually every business is different.
We may mock it, but getting it right is very, very difficult. And many of these businesses end up with consultants just to manage extensibility and tailoring because getting it wrong severely impacts the usefulness, and thus ROI, of the new software.
I don't think there's any greed motivation as you seem to paint it, I think a lot of enterprise software started with a good, simple product and then gradually got forced into complexity by client sales requirements, big support contract clients and over promising in sales (quite often by accident).
The directors of the company I worked for were proud of their product and genuinely wanted to deliver value to their customers. They did, growing amounts of consultant time was not caused by greed but because every client ran their company differently and so wanted their software to be slightly different. Maybe the 37signals type approach is better, but don't mistake it for a nefarious desire to constantly grow the billable hours.
It's not necessarily conscious or nefarious, but the pattern is clear. You can say you don't want to do this, and mean it, but actions speak louder than words, and the incentives are compelling.
It only becomes a top priority if you're trying to do more with the same consulting time.
With straight hourly billing multiplied by people involved, as is common in enterprise, that's never an issue--in fact, in many cases quite the opposite.
However, lower down the totem pole of gullibility lie people who feel burned by the enterprise model and insist on fixed-bid projects, which shifts the risk onto the consultancy. Now the incentives are to get the most done with the fewest people in the least time, at least if you have more work than you can handle. In this situation, automation, installers, scripting, etc. become a big win.
There are other business-relevant incentives for this type of automation, of course. The biggest one I can think of is to make the deployment process even "stupider," thus theoretically allowing for the possibility of employing even cheaper people to perform it. The second biggest one is standardisation (removing individual customs and habits out of the install process), consistency, and reduction in human error.
On a less directly economic level, some manual processes are so tedious that if you don't automate them, your employees will grow demoralised from having to do them over and over. Lord knows we've run into that one a lot. :-)
http://ebusiness.mit.edu/research/papers/197_Cusumano_ProdSr...
Even though very interesting, the main article had been even more useful if that had been clearly defined.
The paper uses these definitions:
Products company
"... the majority of a firm's revenues come through sales of standard offerings." 1)
"Product companies ... generally want to sell as many copies as they can of their product as is – that is, without adding special changes such as one-of-a-kind features for individual customers. 2)
Services company
"If firms go in this direction of providing more customized features, services, and maintenance than they do standardized products, then the more people the company is likely to need, the more unique projects or labor-intensive work it will probably undertake, and the more the firm leans toward becoming what I will call, for short, a services company."3)
It is interesting to note that some of the things the paper defines as "products", like products created by Microsoft, Adobe and Intuit, now in many cases can run as a service on the web.
Is it then still a product, or has it changed to a hybrid or a service?
Sources, all from: http://ebusiness.mit.edu/research/papers/197_Cusumano_ProdSr... 1) Page 3 in the pdf, 2) and 3) Page 4 in the pdf.
That's contracting/consulting, not "a service business". A real service business is where you have people working for you who are working for clients a high percentage of their time. Creating and managing that is, IMO, a very different skillset than simply selling your own services.
If you can hack that kind of thing, more power to you, but in some ways, I think a product business is more hacker friendly, in that the service business requires more management and sales skills early on.
This thinking is largely driven by the venture capital industry
The article touched directly on many of the reasons why I find consulting as a steady state much more lucrative and rewarding, but the one about services as a bridge to product strikes me as most salient. The difference is, my preference and strategy is to never fully cross that bridge. We do maintain fairly sophisticated and feature-complete product codebases, not just SDKs or frameworks or scaffoldings, but--critically--I see the sweet spot as addressing a market where they are mostly, but not quite ever deployable in just a stock, as-is configuration. There is always some customisation, tweaking, domain-specific configuration, etc. to be done, but not to the point where it's anything like a one-off; 90% of the fundamental needs have been met and core problems have been solved. I suppose an appropriate analogy would be: do on a small scale what SAP and Oracle do on a large scale, with their ERP/CRM/PRM packages. This commonly goes by the name "consultingware."
The beautiful thing about specialised consulting is that one can bill a lot of things as services that really have a product-like consistency underneath. This achieves a few things that are not compatible with the general trajectory of a product company:
- Wrapped in a service packaging, these "products" are a lot more opaque, thus more resistant to direct price comparisons and direct commensurability with your competition, especially if the service aspect of deployment is an indispensable part of the value proposition. It's an imperfect, but formidable weapon against commoditisation.
- As the author astutely points out, there are considerable margins to be made in customisation/configuration/setup.
- More opportunities for price segmentation, since what every customer pays will inevitably vary with their needs to begin with.
- You can bill more for your "product." Some of that is indebted to specialisation, not just the fact that it's a service company, of course.
- But it's a lot easier to do specialised stuff this way. Building a product--together with all the trimmings of product fabric in which you have to wrap it for mass use--for a very idiosyncratic, small addressable market is not worth it in many instances unless you can charge a lot, and if you're competing on price with vastly larger competitors with more economies of scale and sales muscle, that can lose big. Unless, of course, they charge even more than you do, in which case coming up from the bottom works just fine.
- Recurring revenue is easier to capture than with off-the-shelf products sold one time, since there is always support and maintenance on anything non-trivial. That said, it's not nearly as easy to get as subscription revenue for SaaS stuff, obviously, but when you get it, it tends to be higher-dollar.
- More flexibility & agility in business concept. When you start a company around a specific product, you're pretty much staking everything on that product, that product line, or that concept.
A service business is a lot easier to remake. Sure, that gets harder as it grows bigger and inevitably becomes more foundationally tied to earlier core technology investments, but I would still say a lot easier than Zappos turning around and becoming an industrial machine parts distributorship.
The last point is really important. Higher margins and higher pricing are sustained by resisting direct comparisons to competing options, and thus avoiding competition on price (this is not to say that you are not broadly competing with conceptual alternatives, or that there is no price-level competition; it's just a matter of degree and impact on individual sales cycles).
Staking everything on a product concept links your fate much more to the manoeuvres of your direct competitors, Scrum sessions and Olympic sprints and customer-driven development and continuous integration be damned. Keeping a mostly-product tucked away inside a thick tuft of service and integration allows you to confront changing market dynamics a lot more obliquely on the plane of marketing and politics.
That said, there are definitely some downsides.
- Fundamentally, service business is still a linear proposition. One can combat that linearity with reusable assets of the aforementioned nature, and with business processes surrounding them replicated at decreasing marginal cost.
Still, if it has any kind of non-trivial marginal cost, you're never going to have the kind of multiplier effect or economies of scale that selling a marginal copy of almost "frictionless" off-the-shelf software or hosted service is going to have. You need to make peace with that.
At the worst extreme, it's kind of like a barber shop; if you want to make about twice as much money, you have to cut about twice as much hair. Hopefully you can do a little better than that, but results vary.
- Specialisation is a fairly indispensable ingredient to the formula, mostly as a price support. I can't really see how one can make more money doing something fairly generic as a service than putting out a product in the same space. If you're selling something with a really low price ceiling and no opportunities for substantial upsale or upward price segmentation, more marginal cost vs. less marginal cost is not a hard decision.
- Getting consistent results out of very inconsistent people on a large scale as an integral part of every iteration of your sales cycle is really hard, especially if you're doing something very esoteric.
You may be brilliant, but hiring copies of yourself is neither easy nor cheap. And many of the most qualified people are going to want a pretty big cut of the action, which is why you see so many consultancies structured as very multilateral partnerships, as with law firms, accountants, and other professional services companies.
Unless it makes sense to dilute yourself, in most cases, there will be an unavoidable movement toward mediocrity as part of your efforts to standardise using lower-skilled, lower-paid employees. The good news is that it may not matter once you're entrenched, but it's almost always bad news for your customers. Still, any kind of non-trivial business growth requires some compromises with reality.
Effectively cutting yourself out of the loop and building a process that is more effectively self-sustaining will either work or it won't, depending on just what it is you're doing. Still, this will probably be the biggest problem you'll face: "Yeah, I've got money to hire another somewhat competent guy, but I'm still going to have to do 90% of the heavy lifting unless I want to see everything go to shit." For the control freaks among us (me), some of that is about learning how to let go and delegate, but most of it is just reality.
Joel Spolsky condenses this issue very well here: http://www.joelonsoftware.com/articles/fog0000000024.html
- As the author said, nobody's going to fund consultancies in any serious way. Small investments to bolster cash flow are about the most you can hope for. As a result, your growth path is going to be quite linear and incremental, and certainly much less impressive than that of someone who just got VC afterburners. That may account for a lot of the product envy; "if only we could get funding to hire 20 sales people at once!"
Guest post from a VC giving candid advice to those running services businesses & considering making the transition to a product business in order to attract VC funding.
If you didn't read all the way to the end, do it. There are some great tips on how to use products in a services biz to close sales or boost margin.
Mark, as usual, you're the man.
In a services business, when you give someone $$, you are paying for a person's time.
But if we're talking about what was said in the article, and what others have said in this thread, if you're doing a service company, eventually you want to get the point where your service is automated. In this case, a user is not paying for your time as much as they are paying for the tool you built to encapsulate your service.
I see Amazon as more of a service, then. Everything they currently offer (having your own store, payments processing, order fulfillment, etc.) they are able to offer because they can give to their customers via the web what normally a brick and mortar bookstore would have to do manually, and now their only constraint is scaling.