I recently spoke at a Salesforce career day in London about my journey in the Salesforce world. The audience were mostly junior Salesforce professionals looking to get some tips from people who had held roles in the Salesforce ecosystem for a number of years. Trying to tempt people over to a career in Salesforce is something I love doing, I’ve done it to my friends, and even my family. The reason? A career in Salesforce has taken me from an individual that didn’t really know what I wanted to do with my life, to someone who can safely say they have a purpose, and deliver value in the world.
My background is fairly unremarkable, I was never really inclined to the academic side of life, performing below average at school and failing my A-Levels. I did manage to pursue a passion in IT by getting through University with a degree in Information systems, but only to land a cold calling job when I reached the professional world. It was through sheer luck that I managed to get a job in the Salesforce world after furiously applying to as many graduate schemes as I could to eventually utilize my University degree. But since joining the world of Salesforce, everything fell into place. Although it’s by no means been an easy ride, I believe that If I can achieve things, anyone can!
In my presentation, I walked through 5 tips that have helped me throughout my professional career. In this post series, I’d like to dig a bit deeper into what these are, and how they can help you.
Start Consulting Now
Back when I was a naive Admin, I used to get so excited at the prospect of building Apps to save my fellow employees’ time. I loved listening to people’s problems and then trying to instantly connect the dots to what I could build in Salesforce to accommodate them. Although this approach was very fun, listening then building, it had its downsides. I remember spearheading an initiative to build a custom Email-to-Case function on a custom object using an Email Service. I listened to what the users needed, and went away and build everything they asked for. When it came to testing however, the users were complaining that this doesn’t solve the issues they wanted. I was pretty annoyed and many meetings ensued with a lot of finger-pointing.
It was hard to have played out that scenario any differently as I was only an Admin with 1 year’s experience, however, it did teach me that everyone is a Consultant. A consultant would be brought in to analyse a problem, create a solution, and then complete the project. To a large extent, this is exactly the role of a Salesforce Admin or any other position working for an end-user.
It took me a couple of bad experiences to realize this, that I should be doing a lot more for the users of my Org to properly understand what their pain points, document their requirements, and then map out the end-to-end solution. So if you are an Admin, Business Analyst or Developer working for an end-user, start consulting now!
To help you in the right direction, let’s look into a basic template that you can start using to help you on your way. Whenever I have an initial call with a client, or run a workshop to gather requirements, this is the way I do it…
Explore – Firstly you need to explore exactly what role and function you are going to be assisting. If you are working in a very small company, this might not be necessary, but my guess is that you don’t understand everyone’s job function in detail. If you are speaking to a customer service manager, understand what their role is, what does their team do, what kind of tickets do they solve, how do they use Salesforce? If you are speaking to a sales manager, understand how they sell, what kind of customers do they sell to? These questions are vital to be able to provide a comprehensive solution.
Pain Points – After you understand a bit about the user’s role in the business, you need to understand how you can help them. This is done by learning their pain points. What don’t they like about the system? What is too time-consuming? What is a manual that should be automated? What is causing a lot of errors? What can’t they report on?
Requirements – Once you’ve learned their Pain Points, it’s time to dig into requirements. I find that requirements come in two different ways, either by the user telling you their requirements or by you uncovering them through their pain points. You will usually find requirements surface themselves in both ways, as it’s unlikely that the user has thought of everything. These requirements should be set in user stories in order to properly capture them, see some examples here.
Solution – Once the requirements have been captured, now it’s time for the fun bit. How do you solve your user’s pain points and requirements through the power of Salesforce? Solutions can be documented in a number of ways, but one of the best ways is using visual tools like process maps or swimlane diagrams. This way, the user can visualize how a process is going to work before it’s implemented. It gives them a chance to spot potential issues before implementation begins. It’s very hard for a user to spot issues is the solution is written out using Salesforce jargon and terminology.
I hope this post has been helpful to help you get into the consulting mind-frame early on. Stayed tuned for more Quick Tips over the coming weeks, and if you have any questions or further comments, don’t hesitate to reach out below!