Salesforce and the art of minimalism — part 4
The Big Finale… data governance
The boring bit but please hang on in there, I promise it will be worth it. Safeguarding data is absolutely critical to the success of the MVP and the system as whole. As I mentioned earlier, we’re putting a lot of effort into getting the right data into the system at the right time so we need to keep it there.
Backups
I’m not going into detail here but having a thorough backup solution is vital. There are plenty of backup solutions available in the app store but here are a few features to consider and include on your shopping list:
- Regular incremental backups
- How much data is going into your system on an hourly, daily or weekly basis? How much data can you afford to lose if something goes wrong - Restoration process
- How easy is it to restore data? Can you restore a single record if required? How long does it take to restore that data? - Differential / Snapshot Reporting
- Being able to monitor data changes; who changed which data and when? Aside from security, you can spot trends and set alerts if large amounts of data change unexpectedly
A good quality backup system will pay for itself because it means you can work at pace, taking more risks knowing that you have a fallback.
Minimalism isn’t just about simplicity, it’s about efficiency and agility. We’re putting in the effort up front to create the MVP so we want to protect the results.
Here’s the kicker…
I’m going to delve into some philosophy now. Or, at least, I’m going to go into some of my personal CRM MVP philosophy.
There are 3 types of data; mandatory data, important data and nice to have data.
- Mandatory data is data that is required for the record to be created, saved or fully processed
- It is often tied to the key data points identified in your customer journey - Important data is data that is valuable but isn’t going to break any systems or processes if you don’t have it
- Nice to have data is the kind of information that can be helpful if you can get it but doesn’t make a significant difference if you don’t
I believe that the MVP should involve only mandatory data. I would argue, at least when you start using a system, that the only type of data worth having is mandatory. That is how simple the MVP should be.
Why waste your user’s time asking them to provide data that doesn’t serve a specific purpose? System adoption is difficult enough and I’ve never had experience of end users that enjoy data entry as a pastime. It is, at best, a means to an end so you need to keep it as light as possible and it really needs to have an end. By end, I mean output and we’ve already covered that — that’s the report that we based the MVP on in the first place!
We know as admins that mandatory data can be enforced in different ways. You can make it required on the field itself. It can be required on the page layout only (so not via import or for users on a different page layout). You can make it mandatory on a dynamic form and add logic straight on the page (hint: switch to dynamic forms if you haven’t already). You can make it mandatory via a validation rule to include more complex logic, for example, to make data mandatory at specific times or depending on other data.
Find the most appropriate, user-friendly way to make the field mandatory and ask yourself, if it’s not mandatory, do I really need it?
…the kicker ^
This is my argument, either you need and it’s mandatory or you don’t and therefore, you don’t.
What are the counters to this? What examples are there of data that isn’t needed but should still be requested?
Let’s take this argument to the other talking point I’ve highlighted from this article; to start with the reporting and work backwards. What would the impact be on your report if some data was missing or inaccurate? It’s good enough right? Your forecast is close enough. Your contracted annual recurring revenue is close enough. Your list of active and ex customers is close enough. You’re billing all your active customers with the correct amounts and you definitely don’t still have customers using the system after they churned 6 months ago?
I wish these examples were made up but they’re not. It happens. Was the money you saved by rushing an implementation worth the revenue loss? It’s hard to tell because you don’t know how much revenue you are losing… funny not funny.
OK, we need some balance to this argument (that I’m staging with myself). No system is perfect, bugs occur and so does human error. Fair point. So why make it easier for gaps in the data to occur? Don’t, there is no point.
Lock your fields down so that only the right people can edit them. Make them mandatory at some point in the record’s life cycle or don’t include them in the MVP. Once you’ve got the minimum viable system/product up and running, once you’ve got your reports showing you accurate, reliable results and trends, once your users are enabled in the system and happy with the basics, then you can move on to the important data and the nice to haves. If you get to that point you’ll be doing better than most businesses too. Bold words but honestly, prove me wrong.
An example I’ve used in this article for an MVP app is a competitor tracker app. This app involves 2 mandatory fields; a lookup to the competitor record and an incumbent contract end date. That’s it. The fields appear on Leads and Opportunities and, combined with other (mandatory) fields already used elsewhere in the system, provide some very powerful insights. Article to follow and here’s a placeholder for link to that article.
The one exception
You have to know the rules to break them. If you can’t or don’t want to make a field mandatory for whatever reason then monitor that field instead. Add it to a janitor dashboard and keep an eye on it. I’ll write a(nother) separate article about janitor dashboards. I really have set myself up for more work whilst writing this post huh… It’s enough to say that a janitor dashboard is based on a series of reports that highlight common errors, missing data or incompatible combinations of data, for example. Typically these are issues that are hard to fix systematically i.e. they require human intervention to fix so you know there is a problem but the logic required to fix it is too complex or bespoke to automate.
Edit: here’s the Janitor Dashboard article
It’s a wrap
I’ll finish with these summarised points, a TL DR if you will;
Start at the end, with reporting.
Work backwards, identifying how the product reaches the customer, documenting customer touch points.
Identify who needs the data, what data they need, why they need it, where they need it and when.
Make fields mandatory or monitor them via a janitor report/dashboard. Otherwise, you don’t need the field so get rid of it.
The minimum viable product is the purest, most basic representation of the data that we can get to.
This is the art of CRM minimalism.
This makes an efficient, sustainable system that users will love.
This will save you time and the company money.
This will provide the greatest return on investment.
This will make you the most valuable player.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
So thanks for reading! This is a bit different from articles I’ve posted so far so any feedback would be truly appreciated.
In case you missed them, these are the links to parts 1, 2 and 3:
