Gathering Salesforce Requirements & Running Discovery Workshops

After so much good feedback on my original Gathering Salesforce Requirements & Running Discovery Workshops article, and because the world is changing so fast (four years feels like it could have been a decade ago), I have decided to do a refresher with some new inputs.

I’ve put together some of my own learnings after ten years as a consultant. There is plenty of information available on the topic of requirements gathering that can be helpful for those who want to invest in this area, but here, you will find my life experience. 

For those who want to invest further, I strongly recommend preparing for the Business Analyst certification, which will allow you to understand different angles of how to dominate the ancient art of Requirement Gathering.

Years have passed, but the questions remain: how can we drive the most efficient discovery session? What should we do, and not do?

4 Stages of the Requirements Gathering Workshop

I’ve decided to structure the requirements gathering workshop into four core stages:

• Pre-Game: Preparation time where you should prepare the information you have available to you in a structured format to ensure you make the best of the discovery session.
• Game Day: The day of the Salesforce discovery workshop, where you will meet and chat with the different users and stakeholders in the business to gather all the requirements.
• Half Time: Time to breathe, and strategize!
• Post-Game: The day after the discovery session, digest the information and compile all the identified Salesforce requirements to turn these discussions into action.

Common Challenges

Let’s start by addressing the common challenges with some scenarios that can take place while gathering requirements, and some tips on how to work around them.

1. Questioning the Status Quo: One of the most common things is that during the session, we only ask questions to understand how the customer works, and we forget that we are there as consultants and not technicians. It’s okay to challenge the current status quo of how you work and suggest improvements. For example, I always ask: “Could this process be more efficient? Does this process make sense?”.
2. Losing Control of the Room: This one is probably the most difficult. Sometimes, there are so many people in the room that a negative discussion can start and drama suddenly commences, which can be hard to diffuse. How can you make sure that this doesn’t happen?
   • Select a small group for discussion.
   • Share an agenda to discuss.
   • Park ideas when they are going on different topics than the one you want to tackle – use expressions like, “I will take note of that thought to discuss it after we conclude this process”.
   • Confidently and politely raise the tone of your voice to take control of discussions.
   • If the discussion leads nowhere, try to stop it, suggest a break, and bring someone from outside who can make decisions. 
   • Be creative, but remember that you are the captain; if you lose your crew, you risk the boat sinking.
3. Identifying Negative Stakeholders: In Portugal, my home country, we have a saying “O Velho do Restelo” which translates as the Old Person from Restelo. It’s used for those people that are always complaining and argue everything, no matter what! You will find this type of person often in projects – and that’s okay. You just need to identify them and ensure you make them feel involved without spreading negative thoughts to the group. For example, maybe involve them in one discovery session, and then invite them to the testing phase.
4. Setting Expectations: I cannot speak for every Salesforce salesperson, but everything isn’t drag and drop. If your client is under that impression, manage this expectation from the beginning. Do this by showing the power of Salesforce while making it clear that without tailoring it to a business, it would be like owning a Ferrari, but having no petrol to make it run! 
5. Remote Sessions: Or, as I call it: “the dance of mute and unmute”. I understand that remote opens many doors and flexibility, but I believe the ‘juice’ you take in is not the same. So, my tip is to make it presential.
6. Getting Lost: It’s widespread for users to start getting lost, so always have tools that allow you to draw the process. I use a lot of whiteboards or Miro.

Typically, clients will send an RFP (request for a proposal) to multiple vendors. I have heard it expressed so many times that it will be enough as requirements. The importance of this discovery session must be underlined. 

I love the saying – we are experts in Salesforce, and you (the customer) are experts in your area. Now, we need to switch seats and make magic happen, and for that to happen, we need to understand your business and we know how Salesforce works.

Important Considerations

All projects are different, and it’s crucial to adapt your strategy to the reality you are dealing with. It is vital to consider:

• Technology: Marketing Cloud and MuleSoft are different technologies with different sponsors and use cases.
• Industry: Different industries can operate and react differently; the speech you have when talking with the banking industry needs to be different to the one you’d deliver to a small startup.
• Business Size: Small operations have different challenges and complexities than larger ones.
• Goals: The end goal of the project should always drive the requirements. If it’s a project to improve efficiency, it will be different from a project to onboard new sales teams.

The main message is that general questions can apply to all projects, but nothing should be written in stone. Make sure you do the homework and adapt to your use case.

For this example, we will use Frank Wallets, a premium wallet seller that wants to implement Sales and Service. The roles typically involved in a project/session like this would be the CEO, IT manager, sales manager, and project sponsor.

• Champions or SMEs (subject matter experts): Like Frank’s sales manager, sales team (typically experienced users), Frank’s customer support team, and their manager.
• CEO or Top Management: CRM projects typically have a high impact and bring much visibility, so it’s always important to align with them to understand their goals, vision, and challenges.
• IT: Spend time with IT. They are the ones who understand the landscape and will be a strong arm in the process. 
• Others: If there are areas that will impact part of the process, you should also involve them, like the financial team for approvals or quality teams to give support on cases.

Pre-Game: Preparing For Your Discovery Workshop

Before the game day, you should run through a checklist to ensure you are fully prepared for the session.

• Review the project scope and clearly understand the initial reasons why this project came about. Is it needed for Salesforce? Or is it needed for reporting visibility? Remember this when discussing the original reasons for Salesforce investment with the different teams.
• Read the notes from the pre-sales conversation, ask for inputs from the Salesforce discovery session (typically, Salesforce makes its session), and try to ensure you know everything that happens before you and your team enter the field.
• Study the company and the industry. Be prepared to understand or use their terminology to show them you did your homework. Use the company’s website, white papers, LinkedIn, and other sources.
• Check who is attending the workshop beforehand (LinkedIn is the best way to see who will be there). Make sure to source out the company CEO; it’s important to know who he is.
• Review previous projects or Salesforce demos for similar use cases to the one you will start. 
• Prepare a set of questions (use them as a guideline, not as examination questions).

Following this, arrange a small call with the Frank project sponsor (or the person who will be your counterpart on the client side) to prepare the discovery session. You can focus on the following things:

• Understanding the company hierarchy.
• Identifying potential champions in the team.
• Cross-checking agendas to book the discovery session.
• Asking for any relevant documentation (worksheets, PDFs with processes, or any other relevant information).
• Trying to understand who/what your blockers will be as if there is a parallel project happening on ERP that can affect the dates. 

Lastly, take this opportunity to start building a relationship and get to know your counterparts. Remember you will work together for a long time and you will benefit from a good relationship with them.

After having all your information, it’s time to prepare the agenda for who and when you want to talk and the main topics you would like to tackle. 

Additional key tips:

• Ensure the project sponsor sends all the invites and shares the agenda’s goals. Always book additional slots as a backup if needed.
• The person leading the workshop shouldn’t be the one making important notes during the meeting. Have another person who is ready to take notes.
• Send an email that promotes your agenda.

Game Day: Gathering Salesforce Requirements

It’s match day, and you’re playing in Frank’s stadium – it’s time to shine! Relax and enjoy the day, you have done the hard part with your deep and thorough preparation. It’s now time to get to business… 

• Be punctual.
• Always look to build a relationship with the stakeholders.
• Show your value. You are the Salesforce specialist, and this is ultimately a Salesforce discovery session. You should lead the conversation.
• Stick with your schedule and agenda to ensure you cover all bases.
• Question everything – you can only find out all you need to know if you ask questions. Ensure you ask questions until you find out the whole process.
• Be critical and disruptive; this company has hired you to ensure they have the best processes and systems.
• Make sure you draw the process (use a whiteboard or large paper).
• Start drawing parallels between Salesforce terminology and their terminology (it will help later on).

Helpful Questions For Gathering Salesforce Requirements 

Here are some ideas for topics and questions you must ask each stakeholder group.

Project Sponsor

• Company: Let them introduce the company.
• Structure: Understand how the organization is structured.
• Goals: Understand what the overall project goals are.
• Achievements: What is the project trying to achieve, and how will they measure success?
• Pains: Understand the pain points that drive the project.
• Way of working: How does the team currently work?
• Limitations: See if there are any limitations, technical or non-technical. For example, they may depend on an external partner for the integration or they have a specific critical person who is on paternity leave.
• Timings: Understand when the peak season of the business is or any other dates that could affect their availability.
• Data migration quantity: How much data needs to be migrated?
• Data migration quality: How clean is the current data?
• Users: How many users are expected on Salesforce?
• Salesforce: Validate the exact license they bought.

Make sure you align with the project sponsor on a way of working – weekly project status, steering commitment, and creating an open line with them! They will be your biggest ally. Typically, I will exchange contact details and be readily available.

Sales Manager/Sales Teams

• Team: How is their team structured?
• Accounts: Who are their customers, and what relationship do they have with them?
• Process: Ask them to describe the current sales process, from the lead to the actual sale. Where do they find the most difficulties with the current process or platforms?
• Products: What do they sell, and who is their target market?
• Tools: Which tools (Excel/online platform/internal tools) are they currently using to perform the sales activity?
• Interaction: How would their customers like to interact with them today?
• Activities: How often should the sales team interact with customers?”
• Data: Which fields are relevant to keep information regarding the different sales process stages (Lead, Account, Contact, Opportunity)?
• Privacy and Visibility: Are there any visibility restriction between teams?
• Reporting/Metrics: What metrics do they use to measure your business?
• Pain Points: Find out the difficulties they have with the current processes and technology.

Service Manager/Service Teams

• Team: How are their support teams organized?
• Accounts: Who are their customers, and what relationship do they have with them?
• Channels: Which channels do they currently have to support customers?
• Types: Ask them to describe the types of cases/issues that your teams get (e.g. invoicing, technical, complaints…).
• Process: Understand the current service process, from the beginning of the contract until it is closed. Ask where they find the most difficulties with the current processes or platforms.
• Routing: How is work distributed among agents?
• Escalation: Is there an escalation process? If so, how many levels of escalation are there?
• Close: What is the closure process of a case/issue?
• Knowledge Base: Are agents supported by any documentation to support their answer.

Service Cloud is very powerful, so the reader should go over the main functionalities of the Service Cloud and turn them into questions for discovery. For example, Salesforce has escalation rules, so try to understand them; Salesforce supports multi-channel, so try to understand the different channels in which they operate.

CEO/Top Management

• Pains: Where do they feel the difficulties with the current process?
• Vision: What are the executive team’s goals with this project?
• Metrics: Which metrics do they want to see come out of this project?
• Success KPI: Which KPI will make this implementation successful?
• Timings: Is there any times which could conflict with the project? For example, peak season, end-of-year review, or just critical dates for the CEO like the turn off of the previous program.
• Strategic Impact: Is there any goal from the top management that should be addressed only for these teams? For example, sometimes top management has strategies they don’t want to share with the operational teams but need to see. They would like to understand what’s the daily CSAT of the customer service team per user.

IT

• Databases: Where is the current information stored?
• Dimension and Quality: What is the size of the current database, and how is the quality (duplicates, incorrect data)?
• Integrations (if they have them): What other systems need to integrate into Salesforce? Are there any current integrations that we need to be aware of? Make sure you check the systems and understand how they might interact with Salesforce.
• Timings: When will be the IT team available for the project?
• Partners: If there are integrations that need an external partner involved, it’s important to connect with them and consider their availability.

If users need help understanding what you are trying to explain (like the concept of Leads), open Salesforce and show some use cases to guide them. A good example is standard Leads to Opportunity process. This way, you can influence them to use Salesforce practically and start getting in touch with the tool.

Break Time

Breathe, have a coffee, reset, and go again!

It’s a known fact that most people can only focus for a certain period of time, so make sure you respect the breaks and give yourself time to relax. Take breaks occasionally and use this as an opportunity to create a relationship with the teams you are interviewing more informally. Don’t only talk about work!

You could ask them how long they have worked at their company? Or, you could even try to find personal linkage and connect through children, sports, philosophy, etc. Try to be creative in your approach.

If there is an opportunity, try to have lunch with your customer and engage. It’s all about connections and understanding who they are – they are more than just an employee.

Post-Game: Debriefing on the Findings of the Discovery Workshop

You’ve made it! That wasn’t so bad, was it? 

Now, the easy part. After the discovery session, there are some steps you should take and try to do it immediately; if not, information will get lost.

• Send an email where you list items you might have missed, let them know their time was appreciated, explain the next steps, and record the necessary documentation you are expecting to receive.
• Ensure all your notes are kept well; everyone can access them later.
• Store your notes logically and group them by department or process (such as sales process, integrations, metrics, goals, etc.). You should do additional discovery sessions to make the best out of your project.
• Debrief and exchange ideas with your peers while they are fresh, and try to draw out everything.
• If you have the time, start cleaning the notes to the official documentation.
• Don’t end the session too late. It’s preferable to save some time during the day to summarize and prepare the subsequent discovery. I always try to complete it two hours before the end of the working day.

Summary

The post simplifies the work that discovery can bring, but I’ve tried to get the essentials for you to create your strategy. Now, adapt to your reality and use this as a loose guideline.

Also, as mentioned throughout, remember to use your soft skills and build good relationships with the team. Why? Because when we can establish a relationship and break the bridge between customer and client, amazing things happen.