Succeeding with Your Next-Gen AWS MSP Sales, Solutions Architecture, and Marketing Teams

By Adrian SanMiguel, Principal Partner Solutions Architect at AWS

Editor’s note: This is the final post of a popular series for AWS MSP Partners. Read Part 1 >> Part 2 >> Part 3

I have worked with managed service providers for about 16 years, and I have seen partners of all sizes and across every vertical implement a variety of practices into their offerings. In almost every situation, each iteration or implementation of a practice was designed to help customers and prospects solve for the challenges they faced.

This four-part series for AWS Partner Network (APN) Partners pulls from my experience and can help you build a next-generation AWS Managed Service Provider. The AWS MSP Partner Program recognizes leading APN Consulting Partners that are highly skilled at providing full lifecycle solutions to customers.

To this point in the series, we have discussed the foundational tenets of next-gen MSPs and how to shape your teams so you can deliver a successful MSP offering on Amazon Web Services (AWS).

In this final post, I will focus on your MSP’s sales and alliance, solutions architecture, and marketing teams. These are the folks that make the first impression of your MSP on customers and prospects.

Building Your AWS Sales and Alliance Teams

Your MSP’s sales team is typically the first opportunity to make a great impression on customers and prospects. Equally important to your practice’s ongoing success is an alliance lead.

AWS Sales

For many AWS MSPs, the general AWS sales team likely comprises 100-200 trained individuals who can speak to the value proposition of the AWS Cloud at a fundamental level.

The core responsibility of your AWS sales team is to educate customers about the AWS platform and how it can help them solve their most challenging business problems.

As covered previously in my post about building you engineering, support, and relationship management teams, many AWS MSP Partners have their sellers align with an AWS Relationship Manager. This is invaluable to have because your AWS Relationship Manager is your biggest champion inside of AWS when it comes to field sales and partner sales alignment and advocacy.

Your AWS sellers should be closely aligned with one or more partner-side AWS alliance leaders for joint customer pursuits, and work through the AWS alliance lead function to build relationships with AWS field sellers.

It’s vital your AWS sellers don’t cut off access or communication with their AWS counterparts. Your sellers can’t grow the account long-term without this relationship, which is almost as important as the relationship between MSP seller and customer.

At the end of the day, the AWS sales team is the key customer contact for the sales relationship and the owner of the account from the customer’s purview. This is whom they call when they want to buy something or are curious about the latest thing AWS launched.

AWS Alliance Leads

Your MSP practice should consider the role of an AWS alliance lead as the liaison between the organization and AWS for all sales efforts. This includes the act of mapping opportunities back to an AWS seller for joint customers. This individual’s core responsibilities are creating, establishing, and maintaining deep relationships with the AWS field and AWS Partner Sales Managers (PSMs).

Alliance leads at many of our top-performing MSP Partners make at least bi-annual visits to AWS offices to keep and foster relationships with the AWS field sales and PSM teams. For example, if you have a territory focus, you should spend time in San Francisco or New York with PSMs.

Actions speak louder than words in these types of sessions, so have your alliance lead come equipped with battle cards, win wires, case studies, and customer references.

I strongly recommend your alliance lead complete the AWS Cloud Practitioner certification, enabling them to speak about AWS at much a deeper level. The certification itself is not overly challenging and gives you a strong foundation for understanding the AWS Cloud.

AWS Solutions Architecture and Build Teams

Solutions-Architecture-1 Once you have a prospect or customer engaged, you will need to call upon two expert units in your organization: the AWS solutions architecture (SA) and build teams.

It’s paramount the core area of focus for these teams is to solve customer business problems and remove undifferentiated lifting. Your SA and build teams are key resources to have readily available. Each has unique strengths that are different enough to require a separation of duties, unless this is not possible for your organization.

Solutions Architecture

Your AWS Solutions Architecture team should be a group of 200-300 level individuals who are experienced in solutioning for customers, regardless of AWS experience. Your SAs will work alongside your AWS Partner Solutions Architects (PSA) and leverage them for technical escalations.

I highly recommend an annual performance goal of your SAs to ensure they are creating thoughtful architectures using the latest AWS best practices. For many customers, there’s a professed desire to not bring existing issues or challenges with them from on-premises to AWS. Your SAs can help ensure each customer’s legacy problems are left behind.

Equally important as technical acumen, your SAs should have a strong set of soft skills to overcome objections with customers. Education and evangelism of the AWS Cloud is very important to the SA role, granting you opportunities to teach customers something new. Seize these moments, as they are the hallmark of a next-generation AWS MSP.

AWS Build Team

Your AWS build team is responsible for vetting SA requirements and business objectives before building out a customer deployment. First and foremost, their charge is to ensure that what has been pitched will indeed work.

Orchestration is also a hallmark of this team. For example, if your customer has a 100-instance environment to build out, this team is charged to do so via a 100 percent automated mechanism, such as AWS CloudFormation or Terraform. They will also have the 300+ level knowledge to understand the architecture and services in use.

For this team, there is no such thing as one-off manual builds or snowflakes in deployment; if it’s not automated or a template, it doesn’t get deployed. Why? One word—drift.

Many AWS MSPs have reported that accidental, and at times, intentional drift off a baseline has shown to cause problems with customer environments. Maybe it’s a new Atlassian stack that was created for an experiment, and then deleted. If the stack goes away, or otherwise has no relationship with the rest of the environment, that’s an orphaned resource at best, or a one-off that now has to be dealt with.

Your build team’s resources are, aside from professional services, individuals that are among the deepest in knowledge in your entire MSP practice.

You should aim to staff your build team with well-rounded, deeply technical individuals who can tell at a glance whether a solution will work as advertised. They should be empowered and have the authority to override an SA’s recommendations if it’s best for the customer.

Another key function of your build team is the onboarding and indoctrination of your customers to AWS MSP offering. They are responsible for creating and owning account management guidelines, runbooks, playbooks, and other documents outlining how the customer’s account should be managed.

The build team also owns the business and technical escalations for the customer until a formal handoff to the relationship manager and support team on the go-live date.

Delivering a Meaningful Message to the Market

Cloud Anything-7 It is the responsibility of your AWS marketing team to advocate for your MSP practice to the customer and to the field. Sounds really easy, doesn’t it? Trust me, it’s not.

Marketing is an unusually tough gig and frequently does not get the respect it deserves.

It all starts with education. Your marketing team controls your messaging, so they need to know what’s going on and why. Your marketing team should be included in every meaningful discussion on product iteration as a default. If they can’t answer a “You can do this, but what about that?” type of question for a customer, then no one is going to buy into your message.

Your marketing team will spend the bulk of their time focusing on driving your MSP’s message to the market and researching your key differentiators. In previous talks at AWS re:Invent, the AWS MSP Program team has referred to these capabilities as your superpowers. Your Product Marketing Manager (PMM) can help crystalize this message to the market with you.

What makes an MSP superpower? Doing something exceptionally well, as reported by your customers and continuing to improve on it. How do I know if I have a superpower? For example, if you have more than 20,000 customers running SAP applications in your practice but it’s just a thing that you do—this isn’t a superpower.

To iterate on this, you can start by helping customers tune SAP to the best degree possible, further increasing satisfaction. Then, as a next step, your practice works to save them a tangible amount of money, and offer them the ability to run their end-to-end management of the front end (Hybris), application (SAP), and database (HANA). In this scenario, I’d say this is now an SAP superpower, but only if you continue improving.

Conclusion

I hope this series on how to build your Managed Service Provider (MSP) teams has been insightful and helps your company grow as a successful next-generation AWS MSP Partner.

Each of the posts explored what successful partners in the AWS MSP Partner Program are doing to grow and scale their teams out.

Even though this marks the end of our series, the AWS MSP Program team will continue to provide guidance, advice, and recommendations on how we are seeing successful partners grow, so that your organization may continue to evolve.

Learn more about the AWS MSP Partner Program >>

Next Steps

As always, please do not hesitate to reach out to the AWS MSP Partner Program at aws-msp@amazon.com.

Check out these other stories in my series for AWS MSP Partners:

Part 1: What Exactly is a Next-Gen AWS Managed Service Provider?
Part 2: 3 Things You Need to Shape Your Teams into a Next-Gen AWS MSP
Part 3: Building an MSP’s Engineering, Support, and Relationship Management Teams

Additional resources for MSPs:

AWS Partner Network (APN) Blog