How to structure your Implementation Team

Note from Jeff: 
I would love your feedback on this one as I move this into book format. I can’t add all of the possible permeations into this post, but this should give you a good glimpse into the types of organizations needed based on the type of product

One of the first questions that I am asked to answer for many startups is how they should structure their group. It is tough to give this answer without giving the typical CS "It Depends. " No product is the same (although there are patterns), and the complexity of the solution, combined with the maturity of the product, makes this very situational. Add to this budget intricacies, and many new leaders are left scratching their heads.

What do most companies do? They hire a CSM to do everything. And this might be the right approach based on how much work there is to do. There might simply not be enough CSM, Implementation, Support, Training, and PS work to do that merits separate roles. However, that is not scalable. Most CSM skill sets are in Account Management and not in Project Management.

Stage 1 Complex

Company Stage: Series A -- D??

Diagrams:

Typical involve: Enterprise B2B, Data Cleansing, API's, Integrations, Portal Creation, Custom Experiences

Resources: Project Manager (TPM), Solution Architect, Implementation (Configuration- sometimes blended with TPM)

This is not as prevalent as it was 1-15 years ago, but there are still headless solutions, ERP, and other complex solutions that take a handful of resources over a several-month period to get to launch. These solutions are deemed "sticky", but the sale and solution are complex and longer. This solution looks very much like a "Professional Services" team, but I prefer not to give it that name at early-stage companies.

If you are at this stage of the company, you can almost be guaranteed that many features still need to be built by the product team, and you will need a project manager on your team to make sure that the product releases features in sync with when the customer is expecting them. Customers are ok paying for Services if it will accelerate their success. They are not usually happy if the tolls needed to go live are a "black box" and only the vendor resources can build the solution.

At Endeca, we had Solution Architects, Back end dev (multiple), front-end Devs, and PM. Projects such as Professional Services were scoped up front and could last 3 months to a year. Some projects had post-launch phases that went 2 or more years as we expanded users and functionality. Once you have defined a working "pod" structure, you replicate that team based on workload and forecast.

With a solution this complex, it would behoove you to make sure that there is adequate training and documentation in place. Documentation "should" belong to Product at this time, but I have had to hire this role in the past when the Product team had not made it a focus.

Final note- I listed this with some question marks. Many SaaS companies are moving to more of a Partner model these days. What typically happens is that you will start out with a large team. As the product matures and is at Product/Market fit, there will be more self-service and administration components that customers will not need for large, complex projects. Even if you still need large teams, it is better to leverage Partner teams instead of having to grow out massive implementation/services teams.

A model that works well is what we did at Endeca and Brightcove. At both companies, we started using a Partner network to deliver the "standard" and defined solutions. These could typically be productized and delivered via external partners. The teams that we had left were working on either the big new shiny logo or the big new shiny complex solution that the product has just built. In these scenarios, the teams working with the customers will still need a tight lifeline to the product team to iron out issues that are found. As soon as these kinks are ironed out, you can start training partners on how to deliver, and your team moves along to the next complex solution.

Stage 1 Moderate:

Company Stage: Series A - >

Looks like this at First:

Moves to this:

Typical involve: Some integrations and data load. White Label configuration

Resources: Implementation Manager, TPM, CS Engineer

It is my belief that this is where many Enterprise B2B companies should live comfortably. The product is not too complex to launch, yet still has

Most likely, this role started with all CSMs, and eventually, this is split from generalists into more of a specialist team. It is generally unfair to CSMs as they are more focused on the areas of Account Management and not deep project management.

What do these Implementation Managers look like? I am looking for the following types of roles: Technical Project Manager, Configuration Specialist, Business Analyst, and Support Engineer (make sure these last 2 roles are comfortable talking with customers). Also, when you make the split from Generalists (everyone is a CSM that does everything) to Specialists, you will most likely have 1 or 2 CSMs say that they prefer the Implementation part of the role vs the Relationship Management.

What type of work will they be doing? Kicking off projects, confirming success criteria, managing the project, hunting down files, light configurations (no coding), training, and launching and transitioning the project (there is a whole chapter on the project lifecycle). You need to be making sure that you are screening and hiring candidates with the skillsets to do these activities.

It is critical to measure how long projects take and how many concurrent projects an IM can handle. This is typically 5-6, but that can vary based on the complexity and duration of projects. Most IMs usually have a few projects starting, a few in the heart of it, and a few (hopefully not too many) that are in transition.

Another important topic that often arises is if you do lots of custom configuration, who supports them after they go live? Do you train the support team? Do you pull the Implementation out of new customer launches when a customer is having issues based on the configuration that they did? This is a difficult problem to solve. In the early stages, you most likely will have to use that Implementation resource unless the Support team has been trained to do that work.

At later stages, this is where roles like "CS Engineer/Implementation Engineer" can help, as they can do the configuration work during implementation and support for issues as they arise. When you make this shift, you may find that your hiring profile for Implementation Managers changes to be slightly less technical.

Series A PLG: Sign up, ready to go. Insert Credit card coin-op

Resources: CSM (until self-service onboarding is created)

At the time of writing, the hot topic in CS circles is "Do More with Less", with a big focus on the digital journey. The big question is, "Is your product ready to support a digital framework"? If so, you may have minimal resources on the implementation side. The typical resource will make sure that customers have someone to reach out to and guide them if they have any problems with the self-service. Many at this stage are using CSMs only.

Obviously, this means that you need to have self-service training. A very helpful tool for your team is Office hours. This is where your Implementation team has a weekly "Ask me anything" session for customers. They can either have a focus area, or it can be wide open for any questions- the latter works better when you have customers in a variety of stages in their implementation journey.

That being said, I do love the concept of cohorts. Imagine that you have each Implementation customer start a cohort every month or bi-weekly. You can then have focused training and office hours for any customers in that cohort. Sales likes the idea of cohorts as it can give them a carrot to get customers to sign up faster. "Sign by the 28th so you can start the next months cohort, or else we have to wait until next month."

Extra roles - Impl Engineer, CS Specialists, Configuration Engineer, Business Analyst, SME. There are a variety of specialist roles that you may have to hire based on the complexity of your product, the support teams level of technical proficiency

As you can see, there are more than 1 or 2 ways to set up and structure your team. Level of complexity, product maturity, and availability of resources can tip you very far in either direction. Do your research- see what works and what doesn't, and adjust.