Salesforce and the art of minimalism — part 1
Be the MVP, make the MVP
What am I talking about!? Well, I like the way that the acronyms collide; to be the most valuable player you must start by building the minimum viable product.
Ah ok… eh? To set the background on this article, in my 5 years as a Salesforce administrator I have spent the majority of my time working around technical debt and limitations imposed by functionality that had already been partially or fully implemented by someone else. I can count on one hand the number of times I’ve had creative freedom to build a solution that didn’t involve fixing, working around or compensating for existing customisations.
This isn’t a criticism of the acquisition of technical debt (though I’ve seen my fair share of inept, short-sighted or down right bizarre customisations) so much as an acknowledgement of its inevitability. It is the nature and very strength of Salesforce that it can be so deeply customised and automated to the needs of the business. It’s why we love the Salesforce ecosystem and why Salesforce is the world’s number one CRM.
So if you’ve ever been in the privileged position of re-working a whole Salesforce object, or perhaps even a whole Org then you’ll probably appreciate what it’s like to reverse engineer other people’s work. You’ll appreciate all the challenges of identifying key data points and mapping out the flow of data (shout out to Salto as a great free data discovery tool) and the ongoing battle of trying to not to break production with every update.
We accept that an amount of technical debt is to be expected in a system that’s been running for a few years. But what is a reasonable amount of technical debt? What is a reasonable time frame to accrue this debt?
I don’t have answers to any of these questions.
That would require research, and I prefer to draw on a modest amount of experience and some common sense instead. At any rate, I think you’d struggle to argue that technical debt is a good thing. So what I want to focus on in this article are strategies to avoid unnecessary technical debt and strategies for creating the minimum viable product.
Time is of the essence
But first, I want to sell the concept a little more. Let’s look at a few reasons why you might not create the MVP.
- You haven’t defined your goals
- You aren’t clear on what metrics you need to achieve
- You haven’t documented your customer journey
- You haven’t mapped your business processes to your customer journey
- You haven’t mapped your business processed to your system processes
- You don’t have the available resources to action points 1 to 5
- You don’t have available the expertise required to execute on points 1 to 5
- You’re under pressure to get up and running quickly, to produce results and provide value from your investment
- You haven’t read my article
This isn’t an exhaustive list and many of the points I’ve listed could have articles of their own. It’s fair to say that there are lots of challenges to creating the minimum viable product. However, point 8 is the most compelling and it is the view that I want to challenge.
The greatest enemy of the minimum viable product is working at pace. It’s almost ironic.
We all have deadlines. Deadlines are necessary. They help us prioritise and focus. However, deadlines need to be realistic and they need to be beneficial. Whatever the reason and nature of the deadline, prioritising the work required to create the MVP will not only help you hit that deadline but will help you hit subsequent deadlines and create a sustainable infrastructure.
This will ultimately save the business time and money. It will improve your ROI and decrease the time to get there.
I’ll say this again, putting in the time and effort up front to sufficiently plan and execute the minimum viable product (herein referred to as the MVP) will save your business time and money, not just in the long-term but the short and medium terms too. It will make you the most valuable player.
Like where this is going? Continue reading in part 2 — Planning, planning, planning…
Not sure where this is going? Continue in part 2 and find out!
…or leave me a comment to let me know why you don’t want to carry on reading.
