So many are striving for the "perfect database," but what does "perfect" actually mean? A database shouldn't be judged by its perfection - it should be judged by its impact on your velocity, by throughput optimization, and by successfully achieving your revenue objectives. Getting to that database is half the battle, which is why we're resharing this episode. Over the next six weeks, we'll be sharing the Best of RevOps Show. Doug and Jess have selected their favorite episodes and can't wait to share them with you.
Here's what Jess has to say on this episode: The pursuit or the perfect database is something that I really believed in for a long time. As I have worked in a myriad of databases over the better part of a decade, I have realized that the "perfect" database is a myth. I chose this episode because Doug really challenged me on this idea in this episode and we had an interesting discussion that might just change the way you look at your database, what to focus on and what a "perfect" or clean database really means.
Audio:
Video:
Additional Resources:
- [Webinar] How to Successfully Launch & Integrate RevOps
- [Blog] Want Growth? Be Like House.
- [RevOps Show] Episode 26: What (Almost) Everyone is Getting Wrong with Data & Metrics
- [RevOps Show] Episode 60: Why Data Architecture & Structure is the Key to CRM Success (And Why it Goes Wrong)
- [RevOps Show] Episode 65: The Power of Data Integration: Building a Reliable System of Record for Efficient Decision-Making
Show Notes:
Doug has his cup of coffee and is ready to take on whatever Jess has planned for this episode which happens to be centered around the goal people have of a perfect CRM. And to confirm we’re talking about the perfect CRM/database. While they are two different things, they’re being used interchangeably. The unique aspect about this episode in particular is you’ll get to see a peek behind the curtain into how Imagine operates as roles reverse today and Doug is the one doing the question asking.
What’s the perfect database?
To Doug, a myth. And this is exactly what Jess wants to talk about. As you can see Jess is clearly having database management issues with clients based on the previous few episodes. This topic is no different. It’s actually something she’s wrestled with herself for a while too is having a perfect database. As she’s worked through the whole thing, she’s realized that it’s never going to happen. It would only happen if you didn’t have any data in your database and it’s not necessarily the right path to go.
By this, she means that you shouldn’t focus on having a perfect database. You should be asking questions like “What information do you need from it? Is it actionable?”
Jess goes on to say that there tends to be this want with a new implementation to have the data be perfect and clean and right. But asking for perfect data isn’t the right question because if you’re focused on everything, you’re not focused on anything. The first question you have to ask yourself is what is the data you’re going to use? That’s where you should focus on cleansing because if you’re trying to cleanse the whole thing, that’s a mountain you have to climb. If you aren’t going to touch every single record in every way it also doesn’t make sense to have every data point on every single record 100% accurate. You should be focused on what you’re using the database for and what data needs to be accurate.
We’ve talked about databases before on the show, so what is the plot of the focus today?
It’s a couple of things. One piece in particular that prompted this is we have a couple of clients who are dealing in integrations and they want the data completely accurate in both systems. And Jess thinks that’s the wrong way to look at it. One of the clients needs their phone numbers formatted in a particular way, so we should be focusing on that piece. We don’t need the whole contact record to be necessarily clean, but we do need that piece to be 100% clean.
Why do you think this is a problem?
Jess thinks this is a problem because if everything is a priority, then nothing is a priority.
We can’t argue with the fact that our data should be accurate, can you?
Jess can argue that if you’re not paying attention to half of your database, then you don’t need that data to be accurate.
But what if you’re not using the data now, but want to in the future?
To Jess that should be a focus when you use it in the future, but to focus on it right now when you’ve got other things that need to be focused on, doesn’t really make sense.
Why do you think this problem exists?
It’s a worry or a paranoia. Doug would challenge there because just because you’re paranoid doesn’t mean they’re not after you. He believes the data should be accurate in reality while Jess believes that in theory, it’s a nice concept.
It’s not a worry or a paranoia that causes this problem, it’s a fear of the unknown.
What’s the key to having a priority?
Understanding. You have to answer the important questions of what is it you’re trying to do with the data? What are your goals? You have to know what the problems are to prioritize.
How do you know what the problems are? Where should you start in the journey if you want to be successful?
The end. When Jess went to Disney she had no problems with the trip because she planned ahead. She looked into her future of what she wanted out of the trip. So, to address the fear of the unknown you have to define what success looks like and you have to outline the path to get there. You have to have waypoints to know if you’re on the right path. And when things change, it’s okay to change the waypoints with it. The distance of those waypoints will always depend on how smooth or rocky the journey is.
Here at Lift, we recommend a default waypoint of 90 days. There are times when you’ll want it to be shorter and times you want it to be longer. The companies that have a better, clearer process, tend to have fewer worries about database issues. Does it mean that their database is cleaner? No. It’s because they have a clear picture of where they’re going, where things are, and what matters.
It all comes down to making a trade-off. Should data be accurate? Doug believes it should, but at what cost? If clients are still looking to go down the path of having all of their data clean, it’s possible, but they wouldn’t be allowed to touch the database for the next six months. That’s not feasible.
The prime directive at Lift is that the business process must drive the technology. Technology never drives the business process. The clean database is a means, not the end. People make the mistake of making it the means for the end because it’s easier to define the process over defining the outcomes. This is why you need to be maniacally focused and insanely flexible.
Doug goes out on a limb to say that the underlying cause of this desire for the perfect database is a lack of clarity about the structure and approach because it’s a lot easier to debate about a database than it is to debate about the structure and approach.
A perfect database does exist. It’s one that enables us to increase velocity, optimize throughput and reduce the effort to solve for the customer and achieve revenue objectives. Another word for perfect here is getting a little better every day. Which in turn means getting a little less worse. The principle for cleaning a database is to measure by the improved data, never measure by the missing data.
The lesson to us is we have to reinforce the context and the why. An excellent job for people that are listening/reading this is to define what are the real jobs that your database is doing. This shouldn’t be a lengthy list. When you know the elements of the business that the database is supporting, then you can connect the dots to that.
Next Steps:
-
Follow Jess, Doug & Imagine on socials for updates on the show or other insights:
-
Doug Davidoff: Twitter - @dougdavidoff | LinkedIn
-
Jess Cardenas: Twitter - @JessDCardenas | LinkedIn
-
Imagine Business Development: Twitter - @DemandCreator | LinkedIn
-
-
Subscribe to the show on Spotify & Apple Podcasts
-
Check out Let's Play RevOps on Twitch for more commentary on this topic