The Salesforce product portfolio has evolved at lightning pace over the past 24 months. For those whose years using the product have now reached double digits, you’ll no doubt remember the initial strategy – focusing on core (but isolated) functionality pillars, with gaps being filled by third parties and partners.
As Salesforce has grown, how has this approach evolved over the years? And in terms of functionality, who did what in the Salesforce space? It’s important to look back at those early days to understand the current environment, as well as where we’re headed – especially when it comes to specialist roles.
The Original Salesforce Strategy
Historically, what functionality have companies provided?
Sales Cloud was supported by Exact Target. There was MailChimp and Wired for marketing, and Apttus and Oracle for CPQ. Financial Force was pretty much the only billing option, and there was Geopointe and MapAnything for geolocated mapping. Service Cloud saw SurveyMonkey fulfilling CX needs, with NewVoiceMedia as the de facto integrated telephony vendor. And general functionality such as reactive, graphical, and code-free UI development sat strictly in the realms of vendors like Skuid.
To paraphrase what I heard at a regional UK roadshow: “We focus on what we’re good at and let others bring what they’re good at.”
Obviously this strategy has begun to pivot in recent times, with functionality gaps being filled by strategic acquisitions – this has brought Salesforce to a place where they can offer cross-product solutions to business use cases. You’ll have seen this really taking effect when Salesforce started to display the Customer 360 product circle at their conferences. Illustrative sparkles demonstrated when multiple products were harmoniously coming together to provide a single solution.
After becoming a ‘jack of all trades’, Salesforce quickly recognized that they needed to avoid becoming a ‘master of none’. Further product development has seen industry vertical solutions being introduced, rapidly followed by very specific solution-oriented products such as Loyalty Management and IT Service Management.
The traditional platform features have become richer and richer, to the point that the all encompassing Customer 360 circle had to undergo a small extension to house all of the new features arriving in waves. In essence, this is a long-winded way of illustrating how vast the Salesforce platform has become in a short time, and it may well have passed you by.
The Original Salesforce Roles
Dialing back to the earlier days of Salesforce, roles were fairly simply defined (Administrator, Developer, and Architect), with many blending together elements of each in a single job description.
The Salesforce platform was straightforward enough for a sole admin to manage when working on business-as-usual (BAU) requests and rolling out project-driven features. However, as you scale, it’s inevitable that you’ll drop a couple more resources into this blended skillset. This is just about OK for keeping an element of traction, but let’s not avoid the real issue… It will soon become untenable to operate in this fashion.
You’ll see telltale signs that things are becoming stretched when you take a look at your workload. If your development swings from working on a Salesforce product to fending off increasing BAU tickets, before moving on to another Salesforce product, you’ll find that you are doing a lot of work, but with less traction and more plate spinning.
This means that your Salesforce product development halts for extended periods of time, or gets dropped entirely under the misapprehension (or hope) that “it will manage itself”. Your end users will gradually lose engagement and senior stakeholders will begin to look for other platforms to serve isolated needs.
Before long, you’ll have a fragmented ecosystem that causes operational nightmares, and you’ll have found that all Salesforce development has ground to a near standstill. Forget about future “release readiness” – you’ll be having to start from three years in the past!
Scaling Beyond a Sole Admin
It’s important to recognize the point at which you have begun to scale past the needs of a sole admin or small set of administrators (plus the optional developer). Look at bringing in a structure that allows Salesforce product specialization. Ideally, you would be creating a grassroots pathway for new talent to come into your team to help deal with the broad nature of BAU across the platform, with a layer of product specialists to sit above them.
The graphic below illustrates a structure at a company that operates with four big Salesforce products:
As an example, Service Cloud and Sales Cloud specialists can focus on developing streams of work on each product without needing to ‘hit and run’ – leaving a wake of development that moves from a Minimum Loveable Product (MLP) to a frankly unlovable product in a short time.
Those who adopt additional technologies (such as Salesforce Industries or Marketing Cloud) should have resources available to manage these demanding platforms. If the platform is big enough, you shouldn’t have to be ‘plate spinning’ to support it.
However, the market often shows that it isn’t quite matching the ambition of Salesforce’s unrelenting evolution. There is little in terms of grassroots initiatives, with the recruitment drive seemingly for juniors to come pre-equipped with two years of Salesforce industry experience, and the desire for the workhorse Administrator+ (who can aptly turn their hand to Apex or Javascript) still incredibly common.
So what can be done? Apart from clicking a LinkedIn reaction on this post and hoping that it will get traction with the people that follow you in your company, it becomes a case of tracking how you work.
Categorization is key – start tagging your work against the product it is aligned to. Quantify whether the work is BAU, a smaller initiative from consulting with the business or from within the team itself, or a ‘big ticket’ project that cascades down from above. Very quickly you’ll have a picture of whether or not the team is overstretched – you can recognize this as pivoting between BAU and project work, seeing which business/team-driven initiatives are happening, and identifying which products aren’t receiving any love.
Tools to Help You Scale
There are a multitude of organizational tools out there to suit your stage in the journey of scale – there are Trello and Notion, Jira and Azure Boards, right up to the all encompassing Salesforce specialists like Gearset and Copado. These tools will take you on the journey from unmanaged chaos to slick operations. Effectively, you will be on the path of DevOps and Agile methodologies. Developers may be aware of this, however, it is just as important for administrative teams.
Here is an example of a scenario that will help you to build a picture:
You are a Salesforce team beginning to support a company that is scaling aggressively. Life feels frantic as you lurch from fortnights of working on projects to rapidly amassing BAU. The work is getting done but engagement from the company is low and the team feels like they are consistently ‘at the coalface’. While you have a sentiment of what the issue may be, sentiment counts for very little in terms of resourcing arguments. This is where your DevOps structure comes in.
In keeping the choice of tool agnostic, the main thing you need is structure – from structure comes evidence. This is an example derived from a combination of Azure DevOps usage of Agile and Copado Portfolio Management:
- Theme: This top-level categorization should be aligned to a Salesforce product (Sales Cloud, Service Cloud, etc.). Themes are assignable at the User Story level, so you can be quite granular as you break down your work.
- Epics and Features: Your architect and product owner should be looking at the big picture, deciding on what you need to deliver for the business in order to relieve pain points and achieve ambitions. Epics are broad objectives such as “Deliver a CX Initiative for Support”, with Features making up specific deliverables such as “Create NPS Survey” or “Make MI Suite”.
- User Stories and Tasks: Once your direction is set, the product owner can work with the team to refine these into smaller objectives (e.g. “as a customer, I should receive a survey after a tech support case closes”) and tasks (e.g. “create flow to send email”). BAU should also drop in here directly with no parent Feature or Epic.
- Type of Work: Against your stories, classify what the work is. Is it project work, are you tackling technical debt, is this innovation being driven by the team, is it platform feature adoption?
- Size: As standard, assign a size to the work. T-shirt size, Fibonacci scale – take your pick! What we are going to measure here is the indicative capacity of a team at any one time based on how they have historically completed work.
Final Thoughts
This is not the all encompassing ‘right’ way of doing things – you can shape it to fit in with how you work. However, what is important is what you get with your outputs. From this structure, you can determine whether:
- Salesforce products are not receiving development.
- Your team is not being afforded the time to drive streams of work on the platform.
- The team is stacked with far more requests than they can handle.
With this information, you can plan appropriately and begin resourcing initiatives before you reach crisis situations, and give the Salesforce products the resources and attention they need to grow over time. There is no better time to get organized and be strategic than right now!
Comments: