Large SaaS companies have a dozen dedicated functions to run their core business. Like in traditional manufacturing, large SaaS companies have a highly mature product and an established customer base. In such scenarios, new client implementations function like a well oiled assembly line and the risk of something going wrong in a new implementation is minimal. In most cases, actual implementations are not in the scope of work of the SaaS and are outsourced to large System Integrators (SIs). 

On the other hand, SaaS startups' success (and more importantly, their survival) hinges on the success of their first few implementations, feedback from those first set of customers and the ability of the product to evolve based on that feedback and truly hit the PMF sweet spot. Not just the product, the whole company has embarked on a learning curve - how to sell the product, how to ensure timely implementations, what are the challenges we didn't foresee, how to ensure customer success, who are the typical stakeholders who are making the decisions, which stakeholders are we talking to on the ground, are renewals a big challenge for us, and so on. At the same time while trying to answer all these questions, the product has to be delivered to those first few customers who have trusted you, and then the product has to deliver for them. 

Sounds like too many problems to solve for a single team? Yes

Should you then must hire separate teams for each of these problems? Yes, you would love to.

Unfortunately though, SaaS startups may not have the resources to do so.

But worry not, for this constraint is a blessing in disguise.

Not having separate teams for different customer facing roles such as account management, sales / business development, customer success and implementation is the best thing a SaaS startup can do.

What SaaS startups need is a team which can build and maintain a strong relationship with the first few customers, program manage the heck out of the first few implementations and also develop a deep enough understanding of the platform that they can pass on genuine feedback to internal product teams.

But why a single team?

1. Creating Cohesive Playbooks: symphonies are not composed based on individual notes submitted by the pianist, cellist, violinist, etc. They are created by 1 Beethoven or Bach and then the conductor coordinates the performance by various players. A SaaS startup is composing the symphony, and it has to bring the whole organization together. Having fragmented teams with a fragmented knowledge base early on in the journey will not help in defining playbooks which take into consideration the whole machinery from product ideation, development to customer onboarding, implementation, success and account management

2. Knowledge compounds: fragmented teams will restrict to their respective mandates, whereas a single unit will be aware of all facets of the product and customer nuances - a more concentrated knowledge base leads to a much higher organizational ability to connect the seemingly disparate dots

3. Faster Feedback loop: Time taken for customer feedback to travel to the core platform is greatly reduced and the roadmap evolves much faster. This in turn means a much quicker path to PMF

4. Simpler monitoring for leadership: Founders have a goto place to get all updates and track progress. The head of such a unit can serve as the single POC for the founders  

What are the roles and responsibilities for this team?

• Act as Voice of the Customer: In startups where the SaaS product or platform is itself being shaped, front-facing teams can act as the VoC within the company and get mission critical requirements prioritized

• Professional Services: Organizations require extensive handholding with new SaaS products, CS teams have to be very hands-on and double up into a professional services org. It is highly unlikely that you would be able to partner with a marquee system integrator consulting company for implementing your product 

• Account Management: Being closest to the customer, CS teams need to be able to make deep inroads into the client orgs and have the ear of the most important stakeholders. No account manager in the traditional sense of the term can match the level of context and network within the client which CS teams have

• Sales: The same context can be leveraged to sell more to the same client (if the orgs roadmap is aligned)

• Program Management: CS teams have to work closely with internal product and client orgs to ensure that timely and high quality deliveries, risk management and governance around key milestones

• Financials / P&L: CS teams need to have an in-depth understanding of both sides PnL in order to be able to demonstrate impact for both orgs

How do you hire for this team?

The expectations listed above are fairly broad and you'll need to evaluate on a case to case basis.

It is not reasonable to expect even a single individual who has experience in doing all of the above, let alone the whole team. Hiring for the right leaders therefore is crucial so that they can build an org which can cater to all the above demands. Generalists with demonstrated success in the following 3 areas can quickly come up the curve and build an org which can deliver the above.

A combination of these 3 is also may be somewhat hard to find, so if you find any 2 of the below accompanied with a strong work ethic and demonstrated ability to learn, you should strongly consider

• • Domain knowledge / experience

  • Client facing roles (consulting, sales)

  • Program management skills

So what do you call this team?

Giving the right name to the team is important as there are multiple connotations attached to it - individuals' titles and henceforth their aspirations will depend on what you call this team. Given the wide variety of expectations from this team, it might seem unfair to bucket them into any one of the traditional SaaS functions. However it might be the best approach. While it may not justify the scope of the role, it reinforces your vision of what you would want this group to do in the end state. People from within this team who would seek other roles will anyway be okay with a role or title change, so that can be accommodated. You will also not have to "dismantle" the team at a later stage, just carve out new teams from this one. If you keep it generic on the other hand, once the organization matures there will always be a set of people who don't see themselves fitting into any of the core functions, potentially leading to conflict.