Our Thought Leader for the month is Pallavi Agarwal (@PalluAgs), founder and CEO of Kander, a Salesforce consulting firm in Washington DC. She is passionate about helping clients connect with their customers by developing business processes and solutions focused on easing customer challenges. Pallavi has over 15 years of management consulting experience. She is also driven by the Ohana spirit of giving back and is actively involved in mentoring women in the community for personal and career growth and leads the DC Admin Salesforce group. Watch the video or read on for great pointers especially for Salesforce women in tech – carving out your niche – and the importance of business requirements gathering to create true customer value.
Teresa: Hi Pallavi, great to have you on board.
Pallavi: Hello. Thank you for having me. I’m excited to be here.
Salesforce Requirements Gathering: Pitfalls to Avoid
Teresa: You’ve spoken extensively on the importance of Salesforce requirements gathering. And it is true that the discovery phase can make or break a project. What are some of the common pitfalls that lead to incomplete or inaccurate requirements gathering?
There are a couple of pitfalls. When the customer comes to us saying, “Hey, I need problem X to be solved”, we start gathering the requirements and we only focus on X. We don’t dig deeper because we’re so focused on delivering scope and getting the customer what they need. Thus, it becomes more short-term thinking or short-sighted thinking versus long-term and foundational. Some of the pitfalls can emerge in that scenario where we’re only focused on X. We end up delivering X and then the customer asks, “But now we need Y”. Had we known about Y, maybe our solution and the foundation we would’ve put would have been different. Now we may have to redo or rejig things, and it might add to technical debt and to the scope. To avoid that, one of the big things is to not only ask about the X, but also dig in deeper. Ask the customer, “But what is it that you’re really trying to get from the solution?”, and make sure you’ve exhausted asking questions.
The second part is asking the right questions. You can ask many questions to get the information you want, but asking the right questions is really the key. What I mean is, that a lot of times as solution experts, we focus on building the solution. So, we’re asking our questions from a solution perspective – what can the solution do? We’re already designing the solution versus asking about the business. Keeping our questions more focused on the business and the outcomes of what customers are trying to achieve with their business helps maintain the integrity of the blueprint design as a foundational basis. This reduces rework and helps tighten timelines and scope as well as technical debt.
Teresa: Be more tech-agnostic and focused on business.
Pallavi: Exactly.
Applying XD Principles to Business Requirements Gathering and Architecture
Teresa: I’ve heard a great podcast of yours where you provided insights on applying XD principles to better design and architect a solution. What pointers would you give Salesforce architects to apply XD insights and techniques to better design and architect the solution from the get-go?
Pallavi: I am not an architect, and I’m not going to pretend to be one and be in their mindset, but the architects I’ve interacted with are phenomenal. They are experts in what they do, and they enjoy it. They enjoy problem-solving and the complexity of how to build a solution. But sometimes they’re enjoying building the solution so much that they forget about the business and who is actually going to be using it. They may not necessarily completely forget about the business, but sometimes when trying to solve the business problem and build a solution, we may not always keep the end user in mind. One of the things to think about is who is really utilizing the tools that we’re building. How are they utilizing the tool? Are we building it in a flexible way? Is it multidimensional in the sense that, say, I, as an end user might be doing data entry and use it one way, and I, as a manager who needs to analyze the data, may be using it another way, and I, in the C-suite am really thinking about the data analytics in a strategic planning way? How are we building the solution? How is it user-friendly from that perspective and how intuitive is it? I can design a beautiful mansion, but if no one wants to live in it, then what’s the point?
Business Requirements Gathering – Key to Customer Delight + Business Value
Teresa: That is true. Digging a bit deeper into this topic. “I still haven’t found what I’m looking for!” – that’s not Bono, but a customer with a solid list of requirements who are perpetually dissatisfied with the outcome of the solution offered. How do you tread the ice to get the customer to objectively introspect the “Why” of their business requirements to build a solution that adds tangible business value?
Pallavi: Yeah, so it, it really depends. Some customers come to the table who have a baseline knowledge of what the application can do and what it can provide. They already have a mindset that says, “Okay, I’m investing in this product because I expect to gain all of these things.” And then some customers have a concept of what the product can do, and they’ve heard the buzzwords, but they don’t really know about it. They usually are the ones who say, “These are my requirements. This is what I want”. And then when you try to build a solution based on it, they’re dissatisfied. Some ways to curtail that is by keeping the customer involved in the design piece and the discovery part, and also by building out some of the wireframes. Show the prototype to your customer, even if only a portion, using wireframes without actually building inside the system. Visually give them an idea of what they can expect, and then talk about why they should expect this and how it correlates back to their business. After that, if they’re like, “No, I want a yellow apple”, you can guide them that what they’re really asking for is a banana, this is why they’re asking for a banana, and this is what the banana can give them. Kind of helping them in that journey and guiding them as they’re looking at you as the trusted advisors. You know the product, but they’re the experts in their business. Bring the environment together to support it.
Finding your Niche: Salesforce Women in Tech
Teresa: As a trailblazing Woman in Tech and an experienced Salesforce mentor, what career-defining advice would you give women entering the Salesforce world? How can they find their niche and their voice?
Pallavi: A lot of the women that I’ve mentored in the past were experienced women before entering the Salesforce world. But a lot of the time, because they are not familiar with Salesforce, they retreat back to saying, “I’m entry-level.” Yes, you might be entry-level as far as the product goes, but you have a lot of skills from your previous careers that automatically translate into the career that you’re getting into in Salesforce. That’s one of the things that I always like to remind them, “You were managing teams before. You were leading many efforts. You got this! The product might be new and you’re learning the product and you need that foundational knowledge. But keep that in mind.” Another tip is to find mentors. Find others with whom you can relate and ask them to be your mentors. Seek them out. A lot of people are happy to give back; they were in your shoes at one point too, so they’ll help and guide you. Another tip is reading – follow some of the popular blogs and check in on the stuff that’s happening. Salesforce publishes a lot of great stuff as well. Then there are so many community members who volunteer their time to put information out there, especially for those who are entering the ecosystem. Another pointer is to find peers who are on the same journey. Having mentors is one thing, but then having a support group, who are doing similar things as you are, also helps a lot. All of which will help Salesforce women in tech to find their niche.
Starting your Salesforce Ohana Journey and Finding your Salesforce Mentor
Teresa: Connected with what you just said, can you share some tips for a Salesforce newbie to start their Salesforce Ohana journey? Ohana is so welcoming, but from the get-go, it may seem a bit tough to navigate your way through it. And particularly, as you said, to be able to identify and connect with a Salesforce mentor.
Pallavi: It is very daunting. I remember when I joined the ecosystem, I was like a deer caught in the headlights because there was so much happening. You see everyone else, they kind of know each other and you step into a room and you’re like, “Oh, they already know each other, I don’t know how to say hi!” But really that is it, that’s the secret password – to say hi! Muster up some courage. Attend user groups, there are so many user groups happening, especially now that we’re back and itching to be more in-person. There’s lots of activity happening with the Trailblazer community and with the user groups. People have found people on Twitter. If you see someone posting stuff that interests you, send them a DM and just let them know what you’re looking for. Or if you admire something about them, let them know, and they might be able to help you get there. Then there are so many beautiful community events. That’s exactly why they’re happening – the Salesforce Dreamin events – they are led by the community, and they happen locally for a reason. Yes. I personally have been to a lot of them. There are community events happening hopefully close enough as they’re spread out regionally that you can at least drive to. If you can attend those, those are really great ways to connect as well.
Salesforce Meetups
Teresa: You have attended a lot of Dreamforce and Dreamin events, and Trailblazer meetups. Let’s end with your quirkiest anecdote from a Salesforce meetup.
Pallavi: I don’t know if it’s an anecdote, but it’s something that surprises me in pretty much every meetup. Everyone thinks you need so many certifications to be successful in the ecosystem. And I do think certifications are important and we encourage certifications even in our company, but certs and experience have to go together. And experience trumps your certs. If you have the experience, that matters. I don’t have a quirky anecdote, but I think what always makes me laugh is that every time I go into one of these meetups, people are so nervous about studying and getting their certs. And some people show up with a multitude of certs, but they still don’t have that hands-on experience to plug it in.
Teresa: That will surely help our listeners to not be daunted about going ahead and attending these meetups. Domain expertise does matter.
Pallavi: Right. Exactly.
Teresa: Lovely talking with you, Pallavi. Thank you!
We hope you enjoyed Pallavi’s practical advice for Salesforce women in tech and the importance of asking the all-important “Why?” for business-driven Salesforce requirements gathering that create true customer value.
Watch other Thought Leader Talks. Get practical Salesforce pointers and helpful tips from Salesforce Ben and Lucy Mazalon, Francis Pindar, Gemma Blezard, Heather Black, Cyril Louis, Meighan Brodkey, and Enrico Murru.
