What the Non-Technical Need to Know to Sell AI to Large Companies
When I started working at a data science start-up, I had no real background in machine learning or artificial intelligence. I’d read articles here or there, but that was it.
This was a problem because we were selling a highly technical product to data scientists, and were an early stage venture. There wasn’t messaging that I could draw from, nor an absolute understanding of our value proposition. We had to carve that out through conversation with clients.
I began by sitting down with our engineering team, who had experience spanning JP Morgan, Bell, and scaling Pokemon Go. I also began writing down the questions I could not answer. Here’s what I learned along the way to a few million in opportunities, and conversations with some of the largest companies in the world.
To be able to converse with data scientists, you can’t just memorize terms. You have to understand the architecture of an enterprise data science environment.
So first — what is data, and what does it look like?
Data comes in different forms. It can be structured, or unstructured. It can be clean (correctly labeled and placed), or it can be unclean. And it can come in assorted forms: text, image, video, sound, geospatial, or even temperature-based.
When thinking of data it helps me to visualize it as a properly organized spreadsheet. Think Microsoft Excel.
This is usually the optimal form your data can be stored. The data is in a table, with column headers (also known as meta-data) clearly identifying what are found in the rows below. The table itself is consistent; all the data points are in the right place.
This is referred to as structured and clean data. The data is tabular, and does not need to be corrected.
Data in this form is ready to be pulled into your data science model. A model is just an equation (of varying complexity) that ultimately spits out a result that you want.
Unstructured data, on the other hand, is not tabular. That does not mean it is unclean, necessarily — but it is harder to work with.
Take a call-center telephone conversation, for example. If you were to transcribe this conversation, which holds valuable information, that would be considered unstructured data.
Let’s say your model needs to understand at what time a customer made a specific purchase, and with what account number. In this case, the data is not structured to readily supply that information.
The vast majority of data is held in this state: PDFs, emails, receipts.
Any document where the relevant information is not easily placed for a computer to read is a piece of unstructured data. Natural Language Processing, or NLP, has emerged as a growing field of artificial intelligence due to its ability to read and use that data for data science.
Data is initially collected and stored in a primary source, or a system of record— your local retail banking branch performs a transaction, and records that information, for example. From here an ETL (essentially, a transfer of data) takes place that moves this data to a central location, so it can be available for wider use. This central location is usually a data lake. A data lake is an aggregate pool of data sets of any kind, and can be mined across the enterprise for analytics-purposes.
Data is stored in servers on corporate premises (aka ‘on prem’), or in the cloud. On prem means the company owns physical servers which stores their data. They will usually have multiple locations, which leads to difficulty centralizing the data to make it commonly available. This challenge is overcome by a cloud environment.
A cloud can be seen as a data lake that is online, and therefore universally accessible. The processing is facilitated by other companies, like Amazon or Google. You may hear the names AWS (Amazon’s cloud service), GCP (Google’s cloud service), or BigQuery (which is part of the GCP offering). Companies today are increasingly moving to cloud environments due to their advantages, while some sources of doubt (ie. security concerns, fear of revealing IP sensitive information) have been mitigated. As such, it is of increasing importance that your product can integrate with these services. Those that can’t are usually written off before the conversation has even begun.
Data exists, and needs to be used. To do so, you use languages, and tools. This is called ‘querying’. The language most commonly used for querying is SQL. In addition, data scientists use languages like python, and tools like jupyter notebooks (a python workbench to conduct data science from), or Spark, to do their work. Again your product must be able to integrate with these items if they are relevant to its use. Otherwise, you’ve ran into a non-starter.
The movement and use of data requires processing power, and is a key concern companies have about using start-up products — can they handle our load?
Processing can be thought of as powering up a battery.
As data comes in, it takes up storage space, or in our analogy, uses up battery power. Servers are stored in a server rack, where they are stacked on top of each other. As one server reaches capacity, data must be moved on to the next one. Eventually, the entire rack reaches full load, at which point it is connected to another rack through the network — which are just wires (the fastest being fiber optic). The difficulty comes into play when you try and ensure all the data is stored on all the different servers equally, without disrupting service. Think again of the battery. As you reach maximum on one, you want to be able to connect it to the other, without disrupting service. At the same time you want to ensure your batteries are balanced; one isn’t being spent more than the other, which results in inefficiency.
This is a difficult and manual process which relies on hardware, and individuals who can act fast to do what is needed correctly, without interrupting service. At the enterprise level, data comes in massive sizes. If you’re trying to work with enterprises, processing is a concern that you need to be able to meet.
I’ve included what I have above, because alongside a deep understanding of our value proposition, this is what I needed to know to make sales. There is a lot more that can be said about this topic, and I’ve tried to balance that here against not saying too much. In future installments, I will go into more detail, and share more lessons I’ve learned.
Everyone knows you need to ask questions to learn. The problem is that if you are new to something, you often don’t know which to ask. When you’re moving at a start-up pace, the best thing you can do is track everything. Track your actions, your work, your mistakes, and your questions, because you will forget them, and you will fail to see patterns that can make you more efficient. In my next post in this series, I will dive into a few more questions I had.
If you have any questions yourself, please leave them in the comments below.
