CRM should be a technical solution to a business need

As the Co-founder/ CTO of my last startup, it seemed natural that I would own our full tech stack, top to bottom, left to right. Of course, I would! We chose Salesforce, and we started early; as soon as we had a few people in Sales and spreadsheets were no longer a reasonable way to manage anything. Salesforce is essentially a managed database under the skin, so setting up our environment seemed straightforward.

But if that were true, I wouldn’t be writing this. Here’s a quick breakdown of some lessons learned, and how I’ve done things differently the second time around.

Problem #1: Solving for a technical need

Looking back at my mindset then, I was thinking about our CRM as a technical solution rather than a business solution. A project requiring a technical solution is naturally not intimidating to me; I need requirements for what the product I’m building should do and I can execute from there.

What I ended up building was something that enabled sales to operate and leadership to report, but it only served our needs in the moment. The full picture (which would only come into focus later) - that Salesforce would be our source of truth for finance, billing, and marketing - was not part of my consideration. Again, I was approaching solving for technical needs, not business needs.

Hindsight being 20/20, I had no idea what an ideal state looked like for our CRM system. How do you even define success in that scenario? This lack of information made it impossible to know if the foundation I was laying in Salesforce was the correct one.

It wasn’t, and that’s because I had to make too many educated guesses about data taxonomies, information hierarchy, and user needs. In reality, these things all reflect business processes. And in a fledgling company, you’re still very much figuring out those processes. However, I was the only one at the company who understood Salesforce. So, while I could get input from others around the company, my interpretation of their needs is what guided the foundation that I built.

Here’s an example that will be familiar if you’ve used Salesforce. I made the mistake of using the Account object as a proxy for the customer’s location. This might seem trivial for a software company that wasn’t shipping physical products, but it creates billing and reporting issues. We were selling to SMBs, so eliminating friction for payments is critical. If one customer was using our product across multiple locations, we were left with a mismatch between billing records and CRM. Attribution reporting became nearly impossible because we couldn’t tell if a new account was a marketing + sales success or a delighted customer adding another location.

My mistake here was rigidity. By the time these problems came into focus, we had too many dependencies around the company to change our entire foundation. A full Salesforce rebuild felt too lengthy and expensive but was the only solution that would definitively pull us out of this hole.

Lesson #1 - optimize for flexibility

Problem #2: Subject Matter expertise

Salesforce, or any CRM, provides more value than just shared access to commercial data. There’s an important context in that information that, when surfaced through reporting, should inform decisions of changes that need to be made to acquisition strategy, the sales process, retention efforts, and a host of other vital GTM motions. Understanding the “why” behind what they’re asking to be built is a necessity.

At larger companies, this is the role of Revenue Operations. But, like most young companies, we didn’t have that function yet. Putting my RevOps hat on and understanding the “why” for the CRM requirements would have helped me navigate and manage much of the ambiguity I ended up using discretion on.

And, while that may sound similar to requirements gathering in software development, there’s an important distinction. Only engineers have opinions about writing code; everyone has an opinion about Sales & Marketing. Knowing better our long-term marketing strategy and how we planned to manage success, for instance, would have helped me build a foundation more suited to report on closed deal attribution and in turn better understand our cost of acquisition.

Lesson #2 - understand the “why” behind requirements from your stakeholders.

Doing it the Right Way

Let’s be honest, building the correct processes in your CRM is a process in and of itself. It involves educated guesses, trial and error, and a need for frequent pivots. Our understanding of go-to-market motions evolves over time as well. The truths we assumed when we launched Salesforce fundamentally changed as our business grew and became more complex.

In an evolving business environment, flexibility is a must. Getting bogged down with bad CRM configuration is more than an annoyance. Good leads can be lost because one specific step has one specific qualification error. Reporting can be misleading if the CRM you’re reporting off of doesn’t actually reflect the GTM strategy. Very quickly, a CRM problem can become a company problem.

The trouble is, CRM at most companies is a black box to its most important users. C-level and GTM leaders are typically not Salesforce literate so they simply need to trust that what’s happening in Salesforce is the correct reflection of their strategy- without seeing anything visual that confirms or debunks that trust.

It probably seems logical by now where our idea for Sweep was born. We wanted to create a platform that provides the kind of visibility enabling every stakeholder to understand what’s going on in their CRM. When it’s not correct or could use updating/improvement, we wanted to provide the Salesforce owner means to quickly iterate and get the process right.

Solving a business problem is different than solving a technical problem, and building + managing a CRM is most definitely a business problem. Especially at early stage companies, the business needs are constantly changing and understanding of “best practices” constantly evolving.

If you’re tasked with building or owning your company’s CRM, I recommend:

• Define your customer journey. This represents your GTM strategy (which will evolve and change) and should act as the guiding principle for the processes in your CRM.
• Optimize for flexibility. You’re going to try different things- some will work, some won’t, and you need to be agile to double down on success.
• Know what you want to measure. This also will evolve over time and inform your strategy but it’s important at all times to know which KPIs you’re focusing on so you collect the correct data to make decisions.
• Involve stakeholders from around the business. Salesforce is an incredibly robust tool that can serve many business needs, but you need their input on what those needs are to build something that will scale with you.
• Create visibility. Often the missing piece, visibility is the mechanism to bring your stakeholders together and align that the processes running in Salesforce truly match the GTM strategy and business needs of your company.