Discovery Interviews

What Is Discovery? Why Is It Important?

The initial conversation you'll have with clients as an SA is critical. You'll learn about their business, their challenges, and decide what next steps should be. This call is often called "discovery" because both parties are in the process of discovering whether there's a mutual fit.

Your goal as SA is to dive into both functional and non-functional requirements, identify pain points, and understand how your solution leads to success for the client. The insights you learn from discovery will help you plan an effective, customer-specific demo, and prepare upfront for any potential objections.

What Are Discovery Interviews?

In the real world, SAs perform a discovery call before diving into the specifics of what the product can do. In SA interviews, however, you may be asked to perform a discovery session, demo a product, or both.

Typically, the interviewer gives you a vague technical prompt. You're expected to ask questions, progressively refining the defined set of requirements. At the end of the interview, your goal is to have a clear problem statement that the interviewer agrees with.

What Interviewers Look For

• Great listening skills: Do you ask the right questions and really listen to customers? Can you effectively tease out key problems? Can you identify the most important?
• Preparation: Before discovery, researching your prospect’s industry is key, as coming in with knowledge of common industry challenges will help you quickly grasp pain points and requirements. If you can bring up these challenges in the discovery call, and are able to communicate how your product solves these industry-wide challenges, it is a definite plus point.
• General technical skills: No matter what product you are selling, conversations around security, data protection, DevOps, etc. are part of the conversation. During a discovery call, an SA is expected to get a clear understanding of all the constraints of the sale. For example, is the product being sold expected to be deployed on a particular cloud? Does the prospect expect out-of-the-box GDPR compliance? etc.

Demonstrating Discovery Skills

Listening

There are lots of ways to show listening skills. It's good practice to continuously refer back to key requirements you've defined, diving deep into particular requirements as needed, and by summarizing your thoughts occasionally. For example, the interviewer might say:

Interviewer: “All data needs to be secure when stored on Databricks”.

Is this enough information to define a formal requirement?

Likely not. While it's helpful to know this is an important feature, it's always good to dive into details and refinewhat exactly needs to be achieved. For example, you might say:

Candidate: “Since you previously talked about your organization having strict security mandates, is there a particular data security mandate like GDPR that you have to fulfill, or can you store data only in a particular country/region?”

Preparation

You can demonstrate preparation skills by asking relevant questions about the challenges being faced by the industry. Doing so will provide valuable information, while showing you've done your homework. For example:

Candidate: “I understand that you are in the banking industry. A lot of the other banks Databricks works with face problems with “Open Banking” and the security of data in motion and at rest. Do you have guidelines on how to achieve this in your organization?”

Another question could be:

Candidate: “We see a lot of banks leveraging different types of data to generate business insights from Databricks. For example, our customers combine historical data and the click data generated on the bank’s website to generate real-time credit card offers for customers. Are you planning on doing something like that?"

The interviewer might ask:

Interviewer: “what other considerations should we think about when implementing Databricks?”

In this case, you can demonstrate your general technical knowledge by talking about the wider context of the IT landscape in addition to your product. For example:

Interviewer: “When the product is implemented, we need to think about security when communicating to/from the product, for example SSL. We should also think about scalability, availability and fault-tolerance.”

A Framework For Discovery Interviews

Before the Interview

A general question might be provided to you before the interview or during the first few minutes of the interview. If you have been given a question before the call, great things to research include:

• The vertical the company works in. For example, if it is a financial company or a bank, they generally have data-related restrictions regarding storing data in the cloud or the region they can store data in. You should plan to ask questions about data security and legal challenges with data.
• Think about the general problems companies in the same space have, and ask during the call if the prospect also has these problems. For example, banks usually have problems with the existing legacy systems and obtaining data from these legacy systems is always a challenge. How does your product solve such challenges?

During the Interview

A common mistake made by SAs is jumping directly into the technical details during a discovery call. It is important to understand the overall context of how a product would be used before diving into the technical details. Some questions you can ask to set the scene are:

• How would the product help the organization achieve its long-term business goals? Is the program part of a strategic digital transformation project?
• Why has the need for the product emerged now? Is it because the prospect is falling behind competitors and losing a large amount of money? Is it because the prospect wants to streamline the organization by ensuring multiple teams work on a standardized platform, and have the same set of guidelines?

After the overall business context is clear, it is time for some technical questions. These questions would of course differ based on the product you would sell. In this article, we would approach them from the perspective of selling Databricks:

• What tools are you currently using to generate business insights from data? What are you able to successfully do and which use cases are challenging with this tool?
• What other constraints exist around security, infrastructure, etc.? For example, are you limited to a particular cloud, like AWS?

End of Interview

At the end of the interview, it is important to clearly summarize the information you have gotten during the course of the interview. Ensure that you touch upon the business context of the problem, the technical challenges the product would solve and any constraints which we should keep in mind.

Here is an example of one such problem statement:

*“E-commerce company Fbay is currently the biggest ecommerce player in the US market, but its market share has declined from 60% to 40% in the recent months as the current recommendations/loyalty programs are not leading to ideal outcomes, thus leading to a loss of approx. $100 million per year. It needs to derive business insights from its historical data like customer purchases, supplier records, etc. well as streaming data generated real-time on the website through clicks. This would enable the organization to improve its real-time recommendations, as well as create effective loyalty programs. Fbay plans to use AWS for all its workloads going forward, thus the ideal data management solution must be compatible with AWS, and integrate natively with all AWS services for logging, monitoring, etc. As a global company, Fbay must also adhere to privacy regulations like GDPR, etc.”

We should also talk about next steps. Common next steps are setting up a deeper discovery call with an audience like technical architects, or demoing the product to the customer.

Common Mistakes

• Proposing solutions without understanding the business problem: SAs, being technical resources, can have the tendency to jump into technical solutions before understanding the problems. This is a major area being assessed during the interview. Listen, think and then react.

• Proposing a huge change: Some SAs suggest replacing a competitor’s product completely during a discovery call. For example, if a company uses Snowflake, which is a competitor of Databricks, avoid saying anything along the lines of: “Everything Snowflake does, Databricks does better. You should completely replace Snowflake with Databricks”. The prospect has made a huge investment in Snowflake and it would be impossible for them to decide to throw their investment in Snowflake away. Ideally, you should focus on the use cases best solved with Databricks and try to find a way to co-exist with a competitor.