Hacker News new | past | comments | ask | show | jobs | submit login
What Should You Do with Your Crappy Little Services Business? (techcrunch.com)
174 points by jedwhite on April 24, 2011 | hide | past | favorite | 31 comments



This was heartening to read. It presents exactly the attitude and frame of mind that I've developed over the last year with my service business.

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 way I think about it, you can either take your pain up front or at the end. At some point you have to ask yourself whether your goal is to impress Mike Arrington, or whether your goal is to make money.


It's been amazing how often people have been giving us bad advice about our business. They point out that the obvious customer for us is in category A or category B, but in our own thinking & experience it's become clearer and clearer that actually it's category C and when we check with people who operate in our sector, it makes perfect sense to them.


I tried a slightly different approach - doing services work that turned into a business to try to underwrite doing product development.

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]


We're actually doing well with this model using a couple techniques to reduce the all-consuming tendency of contracting:

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


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.

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.


Agree. Helps to section time to product dev and client work. Say, product dev morning till 10pm, anything after is client work. Also, let the clients know if at all possible that your are working on a project of your own. Some may be interested in testing, providing connections, or even bankrolling the project.


Gosh I've been around this block a bunch of times -- I've over 20 years in the services business, and I've worked like a dog trying to launch a product business. I've worked with the big consulting firms, and I've worked with companies who were selling dynamite products.

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.


Create tools that are useful for your own service delivery and particularly for scaling your particular service business.

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.


There's a lot of wisdom in this article. Some things that really needed to be said. But the perspective from which it's written isn't typical of those he means to advise, I think.

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.


1 - Create a service others are willing to pay for.

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.


Thats not a service business as this article is talking about. We are talking about services that cost $1000 a day and dont scale without good people. $200x30=$6000 a month is not enough to run a really profitable service business either.


I think ReachLocal does this to the tune of 40M/year in revenue.


Service and product companies typically have a different mind-set. Service-based businesses typically do more waterfall-style development. Product-based companies do more agile development. Service-based businesses build what the customer asked for. Product-based businesses build what the customers will ask for.

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.


Two things to add:

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


There's also an established pattern, the cynical might say, that goes a little like this:

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.


I used to work for one of these business and it's nowhere near as nefarious as you make out. In their case at least it happened accidentally and gradually.

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.


(I spent 2 years in the sector, and my employers didn't want to create complex software either. But they did want to make money - optimizing things to take less consulting time, as you say, wasn't always a top priority.)

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.


optimizing things to take less consulting time, as you say, wasn't always a top priority.

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


And as a sidenote, don't get me started on the folly of "modeling workflows". That's one of the things about enterprise software that makes me avoid it like the plague as much as I can.


Somehow the priorities seem to end up this way. Incentives will out. Problem is the competition dont build that stuff in, so you end up sliding down in comparison, being seen as expensive for bad reasons, not for real reasons that add value, like doing manual upgrades... Then its downhill.


I have been reading about this for long time, and one of the good sources are Michael Cusumano works. He assert that a hybrid model is the most strategic approach:

http://ebusiness.mit.edu/research/papers/197_Cusumano_ProdSr...


I like the fact that the paper provided a definition of what is meant by "products company" and "services company".

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.


> it is far easier to persuade a business to pay you for your services (a concept they readily understand) than it is to persuade them to buy a totally new product concept and pay for that product.

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.


Finally, someone says it:

   This thinking is largely driven by the venture capital industry 
Yeah, that's definitely the truth. Aside from the improbable, but magnitudinal valuations and exits, I can't think of another reason why "startup" has come to be synonymous with "product company" in the popular narrative.

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!"


Never thought I'd say this, but, "this TechCrunch article is a must read". Really good advice and useful context to really understand the advice.


tl;dr

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.


I just forwarded this to two friends who are outside the valley and valley-envy is f'ing up their great business. One in particular is spending about 40% of their resources on this exact identity crisis.

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.


According to this article, would Amazon be a product or service?


Amazon is a product: Bezos built a website and logistics tail to be the world's largest bookstore. When you give Amazon $$, you are paying for a book.

In a services business, when you give someone $$, you are paying for a person's time.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: