How a Salesforce Solutions Architect Conducts Discovery Calls

Below, we have a discussion with Pulkit (Salesforce Solutions Architect) about how he conducts discovery calls with customers.

What is the Discovery process in solutions architecture?

Pulkit: The discovery call is one of the most important steps in any sales process, especially enterprise sales.

The reason Discovery is so important is it helps to evaluate the product fit with the problem the organization has. You're checking that what you're selling is in alignment with what your prospect is trying to buy.

Discovery is also a really good way to get more information about the client.

What kind of cloud platform do they use? What kind of problems does their business face every day? How do they think about GDPR? Security?

All of this information can help you make a good case for your product within the IT constraints of that particular business.

What do you do as an SA before a Discovery Call?

Pulkit: Typically, the account executive has already had a few calls already with the client—calls with business stakeholders. So in talking with them, I usually have a fair idea of what the client is looking for. I'm able to get more information about the company and what they're trying to solve.

For example, if they're a financial company or a bank, they probably have data-related regulations. That means they can store only a certain type of data in the cloud.

With this information, I can start to think about customers in the same verticals and how they're solving similar problems.

Because testimonials are one of the best ways to sell a product, sometimes we see that our prospects also want to talk to some of our existing customers in the same vertical. That conversation can be really important in helping them convert into a customer.

Thirdly, you can look at the general news of a company. For example, if they recently had a data breach, then data security is probably top of mind for them as they search for new solutions.

Don't be afraid to look people up on LinkedIn before a call. If anything, that shows that you're interested and engaged.

When they see that notification on their LinkedIn profile that someone from Dropbox or AWS is looking at their profile, they can tell you're doing your due dilligence. It might shave off time in an initial call too to not have to spend much time on the basics. The SA is already up to speed.

Another tool I use is builtwith.com — it shows you the internal tools used by different companies and sites.

You'll immediatley get an idea if they're a Microsoft-based business, or maybe they only use Google products. Maybe they're hosted on AWS.

Sites like this help you get a fuller picture of how the organization operates.

What would you say is important to focus on during the Discovery Call?

Pulkit: Quite a lot of solutions architects jump straight into the technical details. But often times it can be more important to focus on the strategic side of things first.

Let's say that I am selling a data management product.

Some of the things that are really important to get clear strategically are for example what is happening internally within the company.

Is the company evaluating Databricks because there is a company-wide strategy of digital transofmration? That might mean they have a bigger budget for a project like this.

Or is it just a single manager or team with access to a smaller budget to implement Databricks internally.

Attaching your product to a wider initiative within the company or team improves the chances of success at the enterprise level.

Secondly, I want to understand why the product is needed at a strategic level.

The company might have had a great few quarters. But now that they're facing a recession, they may be losing market share.

That means that the data they have right now, historical data, may not be the best way to derive insights about the future.

Because of this "loss of data," the company is suffering a measurable loss. It's important to try and quantify what the financial cost and opportunity costs are by not having access to clean and actionable data.

The company might be losing anywhere from a few hundred thousand to tens of millions of dollars per year. Compared to the price of Databricks, the software pales in comparison to the value being lost by not implementing this solution.

This is what we call value selling.

Finally, ask why the company is interested in Databricks.

Is another division already using it? If so, you can leverage the successes of those other teams of your product.

At the end of the day, we're salespeople. No matter if we're technical or not, our primary goal is to make the sale.

To do that, it's important to really understand the strategic direction of the company, not just their technical requirements.

What are the steps after a Discovery call?

Pulkit: It depends on the answers you find out, right?

Ideally, while you're on the call, you're also able to talk to the Director of IT or CTO—someone who knows at a high level what the IT direction of the company is.

Here, you can get a sense of what's possible and how your solutions can fit into their existing tech stack.

For larger businesses, the followup call might be doing another deeper discovery dive. In it, I'd spend time learning more about their business landscape and vision for the next few years as a brand and as a business. Do they have infrastructure concerns like customer privacy or cloud storage?

But for a small or medium-sized business, the next steps might be providing pricing. Smaller businesses may be using your free version for months or years and when they finally get on a call, they're ready to make a purchasing decision.

In that case, they don't need another demo of the product but just want to tie up some loose ends or compare your product to a competitor.

A common mistake I see solutions architects make is that they present their solutions as, "Hey, what you're currently using for data management is crap. Rip it out and replace it with our software instead."

That'll never happen, right? You want to make your solutions integrate nicely and work alongside the other tools and technologies the business already has, whether it's AWS, Azure, Snowflake, etc.

Over time, you can show off your other products and services that may be able to replace other parts of their tech stack. But for initial calls, making big changes is hard. Don't try to sell the entire product all at once.