Software start-ups almost never build a technical support team when the company starts. The salespeople handle support and training at first.

As the company grows it will become obvious to everyone that the salespeople could sell more if they weren't interrupted so much with support and training duties. That's when the company needs me.

I know the tools and processes for starting technical support and professional services teams. I understand the software product lifecycle, and how customers' services needs change through those lifecycle stages.

The articles on this blog will cover the whole process of building and managing these services teams, over the whole product and customer lifecycle.

I know a lot, but not everything. Ask me your tough questions. Challenge my assumptions. I look forward to learning from you.

I am available for contract work, if you want to talk to someone about the specifics of your situation.

-Randy Miller | william.randy.miller (at) gmail.com

Wednesday, October 27, 2010

When to add a services team

Question: When is the right time to add a services team (either technical support or professional services)?

Answer: The short answer is to wait as long as you can.  That's what most software companies do as an impulse, and that instinct is correct in most cases.  But you will have to build out a services organization in order to reach the mass markets.

Salespeople can do usually level 1 tech support and basic implementation training.  Developers can do level 2 and level 3 technical support.  The founder or product manager or some product visionary can do advanced implementation work and deeper training, if any of your customers even ask for either of these services.

This will work while a company is in start-up mode.  When those people get too bogged down or frustrated with wearing the additional hats, then start hiring service people tactically.

You also need to recognize that the clients you can attract will vary based upon the maturity of your product and service offerings.  The theory here is called 'diffusion of innovations' (this is the root theory behind Geoffrey Moore's 'Crossing the Chasm'.)  This theory states that different types of people and organizations are willing and able to adopt innovations at different rates.  The theory breaks people and organizations into five categories:
* Innovators
* Early Adopters
* Early Majority
* Late Majority
* Laggards
(credit: found at this blog.)

The percentages in those categories are referring to market size.  Those are just rough estimates.  The market size per category will vary greatly from industry to industry and segment to segment.  But every study I have ever seen has come out with a bell curve of basically this shape.

New products only appeal to members of the innovators category.  As the company and product mature it will appeal to each new group in order: early adopters, early majority, late majority, and laggards.

I'll describe each of those 5 categories in separate articles, soon.  For now it should suffice to say that members of each category have certain expectations for the sales process and for post-sale support.  They will look at your website and immediately recognize whether or not your company is ready for them.

If you don't have a technical support team in place then you are only selling to innovators and early adopters.  You might not be selling to early adopters, depending upon how mature your technical support team is, or how talented your salespeople are at technical support.

If you don't have a professional services team you will have a hard time selling to early majority customers.  It is doable if your salespeople are experienced in performing training and helping with implementations.  You will not make serious inroads in to the early majority market without a dedicated professional services team, though.  And you will definitely not sell to late majority or laggards without it.

The bulk of a product's revenue will come from the majority categories.  My experience is in taking a product that only sold to innovators and early adopters, and adding the service components to make it palatable to the early and late majorities.  That is what this blog is all about.

Further Study: Carnegie Mellon's Software Engineering Institute has a practice that studies process and performance improvement.  These are the people who helped establish the original PMP standards.  They do a lot of research on these topics.  Whatever you might think of the detailed processes and systems that they seem to always develop, their research is fascinating.  They developed a Capability Maturity Model Integration (CMMI) for services organizations.  They also have a CMMI for software development. (Hit 'Model Download' on either of those pages.)

No comments:

Post a Comment