The first time I meet a new client’s team, before I show them anything I’m planning to build, I tell them the CRM is always going to suck. It sucks right now. I’m going to fix it, and it’s still going to suck when I’m done. I say it because it’s true, and because I want them telling me when something’s broken instead of working around it.
Here’s how I put it to a client’s go-to-market team a couple of weeks ago:
“So even once I get done with this little roadmap that I’m working on right here, it will still be broken and terrible. It will always be broken and terrible. So I’m not going to be offended. Send me messages on Slack that say, hey, Kevin, why the hell am I doing this in HubSpot? That’s fine. It’s actually very helpful for me.”
The expectation setting here is important because many companies envision this endpoint of their CRM with perfect data and processes. But that doesn’t reflect the reality of how your business functions.
Why it never gets finished
Your CRM is set up for how your business worked when someone built it. Then the business changes. I said it this way on a coaching call last week:
“we’re going to make it a little better and a little bit more useful. And then something about the business is going to change, or we’re going to learn something about the business that we didn’t know, and then we’re going to have to change it again.”
Sometimes nothing about the business changed at all. You just learned something you didn’t know when you built it, and now the setup doesn’t fit. Either way you’re changing it again, and that’s normal. It’s not a sign the last person did a bad job (and sometimes the last person was yourself).
The three-month rebuild doesn’t work
What I see a lot from people in RevOps leadership, and from CROs and sales leadership, is a hypothesis and huge project to resolve the problem. Here’s what’s wrong, here’s the fix, and we’re going to work on it for three months.
“And I don’t think that’s how this shit works, honestly. I think that’s too… I think it’s too narrow and I think the time frame’s too long.”
There are a lot of small problems in a company at any given time. A three-month project picks one and lets the rest get worse. Not to mention, three months is plenty of time for the business to change and create new problems.
What I do instead is fix smaller things constantly that align with a larger goal for the quarter (improve data quality, improve a particular conversion rate, etc). And when a rep messages me that something in the CRM makes no sense, I fix the small ones that week. I wrote about that in Issue 009 as well.
Tell your team before you change anything
The reason I say all of this at kickoff is that changing the CRM means changing how people work, and they feel the cost before they see any benefit:
“You’re going to be slower and worse at doing it this way for some number of reps, right? And then out on the other side, you’re going to save this much time. … But if you’re honest about it going in instead of just saying we’re going to blow up the whole process and oh, by the way, all of your KPIs and goals and quotas are the same as we’re screwing with this shit, that’s hard. Especially for a salesperson.”
If the team knows it’s going to break, they’ll tell you when it does. If they don’t, they go back to whatever they were doing before. They have a quota or a goal and if the change didn’t make things easier, they’re going to go back to what they know.
This is hard on the ego, and I don’t think enough people in RevOps talk about it.
“you have to break your own stuff constantly and you have to, you have to sit there and just be like, what the fuck was I thinking when I put this together?”
I was at Pearl for five years, and there was stuff I built in my first year that I’d look at later and have no idea what I was thinking. It happens with my customers now too, and a lot faster. I’ll build something, come back to it three weeks later, and wonder who did it. It was me.
The skill that matters most in this work is curiosity, and that includes being curious about whether the stuff you built yourself is still working.
Don’t build it around you
A former coworker told me recently that people always just wanted to get my attention on something, because no one else could touch what I’d built. That sounds nice, but it was the biggest mistake I made there:
“I probably didn’t build things the greatest way if it required my attention all the time, which was the one big mistake that I made… was tying too much to things that needed me to get my hands in on”
If you’re going to be changing the CRM constantly, someone other than you has to be able to change it. Document how it works, and keep the setup simple enough that the next person can follow it.
Switching CRMs won’t fix it
When the CRM sucks, a lot of teams decide the answer is a different CRM. I get it. I’m not a fan of any of them:
“I hate all of the CRM companies. … They’re all terrible, every single one of them are terrible”
I still put most early-stage companies on HubSpot, and usually on a cheaper tier than they’ve been sold. A new CRM gets you the same problem in a new tool, plus a migration. Building your own is worse, because now you’re maintaining software on top of running your business:
“now you’re like a CRM software company in addition to whatever your company was before.”
The same goes for the AI platforms offering to hold all your business logic. I wrote about why that one worries me in Issue 010.
Where I’d start
If you’re about to kick off a big CRM cleanup, don’t plan it as one three-month project. Tell your team up front that it’s going to stay a little broken, ask them to message whoever owns it every time something makes no sense, and ship the small improvements every week. If you want someone to look at it with you first, book a RevOps audit.