What do you really need from your Salesforce products?
Salesforce creates products. Customers buy user licenses. Salesforce hosts, updates and maintains their products. Customers get access to the product and new and improved iterations. This is the nutshell that explains why, if you can use the out of the box functions of Salesforce products, you should.
However, as Salesforce consultants and customizers-in-chief, we know that with so many different businesses, operating models and user-groups benefiting from Salesforce, it’s inevitable that customization will happen, and is often a necessity. Particularly at enterprise-scale, this becomes a significant initial and on-going investment. Much of our role, therefore, is to provide guidance on when to invest more heavily by customizing the platform versus when to use those elements that are available or configurable using “clicks not code”. To get the balance right, we need to understand where our customers are willing to compromise. We need to know the difference between things they would like, and things they really need from their Salesforce products.
Much as we’d love to promise to deliver everything, projects are quite sensibly constrained by budget, time and resources. Right from the beginning of any engagement therefore, expectation management is fundamental. A simple starting point is recognizing these project constraints and setting out the specific aims of the project. What outcomes would make this project a success? What does this mean for the different departments and stakeholders involved in the project? And have these objectives been communicated beyond the project leadership team to colleagues who will ultimately be our end-users?
It also helps to break-down the project timeline; while “8 weeks” might sound like a long time, a project will typically include discovery sessions, onboarding, requirements gathering and refinement and sign-off, construct, integration and end-user testing, as well as multiple deployments. These project activities will not be familiar to everyone involved, so it makes sense to set out these time constraints and deadlines alongside the project objectives.
Everyone involved in the project should also understand how it fits in with the overall approach to managing the Salesforce product in your organization. What will happen after this project to any requirements in the backlog? Will there be a second phase of the project and how will that progress from this one? Sharing the product roadmap can help everyone stick to objectives for stage one, knowing there’ll be more opportunities to build upon an agreed baseline at a later stage.
Agreeing and communicating these basics to all project stakeholders from the get-go, helps to create some guide rails which are particularly helpful when starting to talk about specific requirements. It gets users thinking about what requirements should be brought to the table as a priority versus a nice-to-have. When discussing requirements, it allows a valuable sense-check – does that requirement fit within the project objectives? Given our timeframes, should we go into that more complex process for 10% of customers, or should we focus on the 90% right now?
The answer might very well be “‘yes – those are our high-value customers”, but by using the project objectives to steer the discussion, we know we’re investing our collective project resource in the right way. And, when it comes to the technical solution, we have a good idea of where customization is needed to make things work in just the right way.