Paul Graham has written a terrific blog post to startups about doing "things that don't scale".? Its a great post partly because it addresses a blind spot many people in both VC and startup communities have been afflicted with - the idea of "scaling" every activity they're involved with.
Scale, Recruiting, and Consulting
This relentless focus on scale doesn't always work.? At the beginning you need traction, not scale.? You may even need revenue, not scale.? Graham points out that
Actually startups take off because the founders make them take off. There may be a handful that just grew by themselves, but usually it takes some sort of push to get them going. A good metaphor would be the cranks that car engines had before they got electric starters. Once the engine was going, it would keep going, but there was a separate and laborious process to get it going.
He gives a great example:? recruiting.? Not just people, but users:
The most common unscalable thing founders have to do at the start is to recruit users manually. Nearly all startups have to. You can't wait for users to come to you. You have to go out and get them.
And the reasons he gives for why founders don't do this are spot-on:
One is a combination of shyness and laziness. [...] The other reason founders ignore this path is that the absolute numbers seem so small at first. This can't be how the big, famous startups got started, they think. The mistake they make is to underestimate the power of compound growth. We encourage every startup to measure their progress by weekly growth rate. If you have 100 users, you need to get 10 more next week to grow 10% a week. And while 110 may not seem much better than 100, if you keep growing at 10% a week you'll be surprised how big the numbers get. After a year you'll have 14,000 users, and after 2 years you'll have 2 million.
So how does this relate to the world of services firms?? The key thing is to realize that instead of recruiting users, we're recruiting customers.? And it isn't scalable (at first). The services firm founders have to embark on one of only a handful of tactics:
- Do the sales yourself (recruit your customers).? Don't hire a sales person, do it yourself. Learn how to sell if you don't already know how.
- Teach everyone you hire how to recruit customers, or how to support selling behavior, so that they can support acquiring new customers or new projects with current customers.
- Recruit a channel partner (or two).? Be the delivery partner of a firm that has already built a sales channel. Leverage their ability to sell to bootstrap your business.
If you follow door number 3, be prepared to give up significant margin to make it work.? That other firm has invested in sales staff, in growing relationships with customers, in recruiting those customers.? You're "recruitment" was of a channel.? You give up points of revenue to your channel.? Don't begrudge it, they are doing you a valuable service.? But don't be complacent - if a channel partner changes management teams or focus, or runs into economic difficulty in other parts of their business, it can hurt you quickly.
Graham describes the fact that you'll have to do things differently when you have more users joining - thousands a week instead of 10s.? On a smaller scale, recruiting customers changes as you scale your operation:
- First, managing major accounts. These customers are your bread and butter, keeping you alive, and you need to make sure you're taking their needs and requirements for your firm seriously.
- Second, Separate new customer acquisition from managing current clients.
- Third, hiring someone truly focused on new customer sales.
- Fourth, actually managing a pipeline
- Fifth, maturing to the point of having marketing campaigns, lead gen, and managing the funnel earlier in the pipeline to figure out which customers are the most likely to be recruited.
A similar approach can (and often is) applied to BPM projects.? Don't obsess over automating and scaling every process improvement from day 1.? Get the process right, even if you have to do "systems integration" manually with a human, instead of with an API.? Work out the process, then look to capture it or improve it with software - so that it can scale to the rest of your business or the full scope of the project.
Scaling the company.
A big criticism of services firms by the startup community is that they "don't scale."? Of course, what they really mean is, they are more people intensive businesses (per dollar of revenue), and that they aren't "good investments" by the definition of their investing model.? But obviously services companies can scale - ask IBM, Accenture, Infosys, Tata Consulting, or Cap Gemini.? One of the things I find really interesting about Graham's post is his take on early stage startups:
The question to ask about an early stage startup is not "is this company taking over the world?" but "how big could this company get if the founders did the right things?"
Indeed.? A services firm with the right investments of profit and talent can get quite large.? So I don't worry about "how big" BP3 can get.? I just worry about the next subject of Paul Graham's post:? Delighting Customers (Users).
Paul Graham writes (emphasis added):
You should take extraordinary measures not just to acquire users, but also to make them happy. [...] Another reason founders don't focus enough on individual customers is that they worry it won't scale. But when founders of larval startups worry about this, I point out that in their current state they have nothing to lose. Maybe if they go out of their way to make existing users super happy, they'll one day have too many to do so much for. That would be a great problem to have. See if you can make it happen. ?And incidentally, when it does, you'll find that delighting customers scales better than you expected.
This is the mantra any services firm should live by, and reading this post is going to cause our team to go back to the drawing board and really think about whether we're doing everything we can to achieve more.? I'm confident we're not doing everything we can do, despite the glowing references we get from our customers.
Paul Graham also gives advice on consulting - or rather, when to consult - how you can learn from early users by helping them use your product. And confirmation of the VC/startup anti-services bias comes out as well: "Consulting is the canonical example of work that doesn't scale."? But he advises that it is okay "so long as you're not being paid to."? Meaning, you won't be tempted or distracted by the revenue stream of consulting - and here is where his advice diverges from the advice you would give a services firm.
First, if you're bootstrapping your company, you need the revenue.? You try to manage the distraction rather than eliminate it.? If you're building a services firm, consulting *is* your business, so you're just fine taking on the consulting work.? But keep in mind, there's consulting you do that you get paid for, and there's consulting you do "for free" that helps your customers get the most value out of your core services product.
This blog is an example of "free consulting" (Paul Graham's blog is a better example!), but so is the advice we routinely give customers about their BPM initiatives, how to prep for project start, how to engage the business in playbacks, which project management software to use, what our experience with various software vendors has been, etc.? This is also good advice for BPM Centers of Excellence- to offer to consult with other parts of their business to cross-pollinate ideas and build reputation and goodwill with the rest of the organization, rather than requiring every interaction to be transactional in nature.
Paul Graham also gives good advice regarding doing things manually, that *look* like software to their customers.? A classic example of this from the 90's was Dell's direct order model - where orders from the website were famously printed out on the factory floor, for the factory to produce and configure (not an automated process, but the customer would never know).? At BP3 we provide a number of services that feel like "SAAS" to our customer but could be done manually, partially automated, or fully automated.? All part of our effort to make BPM as simple as it should be for our customers.? Even if the work is manual, it should feel like a smooth machine for our customers.
The whole piece is fantastic for startup companies, and though it intentionally doesn't offer advice for consulting firms, there's still a lot to learn from Paul Graham's writing, and a lot that can be applied to improve your consulting business.