![Salesforce AI Assistant](https://cdn.sanity.io/images/9eu1m6zu/production/144d8c998953b58e8a4f3027743492b43d1974eb-1200x630.jpg?auto=format&dpr=1)
A little over halfway through my tenure in the Salesforce ecosystem (now 13 years and counting), I led the consulting team on a project at a very large company. I don’t like overstating my palmarés—nor do I like to overshare—but this company was a household name. They’re on the Fortune 500 and they have been around a while, because they’re really good at what they do.
They worked for *4 years* to transform their business through Salesforce. Those four years were filled with countless user stories, configurations, and platform customizations. At the end of it, they decided to scrap all that work and go with another system.
What happened? Where did it go wrong?
One of the product owners told one of the teams that a certain feature wouldn’t work out of the box. That team spent two weeks building a custom solution, then *another* two weeks revising it during a QA cycle.
The Product Owner put the new feature in front of the business whose immediate reaction was, “we want something else.”
The worst part? The “something else” they describe was, almost to the letter, how things worked out of the box. The team then had to spend *another* four weeks unwinding all the work they had just done. It’s worth noting that I would share this particular anecdote with my junior consultants all the time. While it may be a little extreme, it’s a great case in point. Across the ecosystem, Salesforce customers are struggling with a platform that is laden with technical debt and under-delivering on the value it promised the business.
As with my example, a lot of the organizations I interact with are struggling with a lack of good business analysis. Business Analysis is, to my mind, the most valuable, underrated, and undersupplied skill in the Salesforce Ecosystem.
Bold claims, perhaps, but I have evidence. The Salesforce certification catalog has exploded since I joined the ecosystem (cue “back in my day!” voice). I got my first certifications the first year Salesforce offered Service Cloud Consultant as something separate from Sales Cloud. That was a big change. Since then, the number of certifications has grown to at least 43. Of those exactly one mentions business analysis. 1 in 43.
I’m not arguing for parity. When I was staffing delivery teams, I would typically look for between a 3:1 and 5:1 ratio of developers to business analysts. It’s not that devs can’t code without a BA. They can, which is part of the problem. When left alone, devs can do a LOT of work. However, without a good business analyst (at this point, I should note, I use that term to include more senior profiles like “Solution Architect” and/or “Product Owner”) the devs have a really hard time building the right thing. A good BA will not only improve first time delivery of a product team, they will reduce the amount of customization your solution accumulates over time.
To sanity check this point, I only ask that you take a look at your Salesforce org. There is a 1 in 10 chance that your org is struggling with *too much* metadata. Too much apex, too many flows, too many fields, too many objects. This is the lay of the land in the ecosystem right now largely because of Salesforce Trailhead. Trailhead is really good at building people who know how to build things. So what happens when they get their hands on a Salesforce org? They build!
I want to be absolutely clear, I’m not criticizing or blaming anyone. I simply want to call out, if you hire developers, they are going to develop. If your goal is to reduce the amount of code you have in a Salesforce org, more development talent will almost certainly not help.
So how do you move in the other direction?
If you’re building a team, hire a good business analyst (or “product owner” or “solution architect”). If you’re on a team and are trying to change its direction—or maybe reposition yourself professionally so you can drive a little more impact—focus on process.
Sit and have a conversation with a business stakeholder about how they do their job. Turn it into a process flow. Make a box for each major step. Next to each box write the logic of how they know this step is done and the things they do to get to “done.” Ask the person across the table from you, “if I can give you this, will it help you do your job better? What will that mean for our company.”
Next, sit with your technical team (or google if you’re a team of one) and translate your process flow into technical elements. If any of those elements add a step to your process flow, check back with the business to make sure that won’t be a problem.
From there, let your team build what you agreed to. When they’re done, use the process flow to validate that it works. That is, if you can get from one end of the process to the other, completing all the steps on the way, it works. If not? It doesn’t.
Finally, put the updated solution in front of the business with the process flow you agreed to. That’s your contract. That’s the thing that says, “If you can get from point A to point B without extra steps, we agreed it would help.”
The first version won’t be perfect, but that’s okay. Now you have something that makes life better for the business and the business has a picture they can use to show you where the rough spots are. You can work together to improve it over time.
There are a million and one things to spend money on in the Salesforce ecosystem. A billion and one if you include the broader CRM/Sales/Service/Marketing universe. My advice: if you spend another dollar on CRM, spend it to improve the business analysis capabilities—of yourself, of your team, and of your company.
Note: I joined Sweep because it is built to support the process I laid out above. If you want to level up your Business Analysis capabilities, schedule a meeting with me today.