
What Should You Do with Your Crappy Little Services Business? - jedwhite
http://techcrunch.com/2011/04/24/what-should-you-do-with-your-crappy-little-services-business/
======
thaumaturgy
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.

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

------
jedwhite
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]

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

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

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

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

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

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

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

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

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

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

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

~~~
petervandijck
(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.

~~~
abalashov
_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. :-)

------
wslh
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...](http://ebusiness.mit.edu/research/papers/197_Cusumano_ProdSrvcsBusMod.pdf)

~~~
wolfhumble
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...](http://ebusiness.mit.edu/research/papers/197_Cusumano_ProdSrvcsBusMod.pdf)
1) Page 3 in the pdf, 2) and 3) Page 4 in the pdf.

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

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

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

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

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

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

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

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

