Clarifying scope

Has this been built with some key application in mind? – No, it came out of a hobby project from Google search team

Does the freeform text have any restrictions on how it is written? – The API gives accurate results for simple freeform text statements, results may become incorrect if freeform text is complex

Assumption is that the API is fully functional in converting different types of freeform text into SQL statements. There is no change needed in its algorithm – Yes

What is Google’s goal? Is it Revenue or #users or something else? – Primary goal is to get usage/ users

 

About Google

+ History of creating successful products / has high usage

+ Strength is tech – creates new technologies along with using existing ones

+ Focuses on innovation/ solving problems – not short term revenue

– Expectation that Google search will provide most answers is not always met

– Fake content/ information

– Does not provide information beyond what is available – Insights

Possible applications of this API:

Search, Analytics products, word documents (aid via data substantiation)

 

Goal: Make API into service

           Take it to market

           Focus: users

 

Solution:

User types a statement – > Fed into the API -> API create SQL statement(s) -> Queries return data -> Data is presented in freeform / table.

e.g. what is the expected recovery rate of 4thCovid wave?

Expected recovery rate of 4th wave is 99.5% (more data in table)

Strategies

1. Launch with one key Google application like search – This will allow Google to test in a popular use case. Allow the service to really get streamlines with the search use case. However, it could limit the definition of the product early on by confining to one use case.
2. Launch with on few Google products with varied applications – such as Search, documents, Analytics – This will allow the service to be tested in the key use cases. Give access to lot of users and also give feedback to improve the product.
3. Make it open source and let developers build applications – Making it open source is a great way to get usage. However, the focus right now should be to test with few use cases and help the service mature
4. Work with other companies on applying it to their products as pilot – probably as phase 2 if Google is looking to apply in more use cases in a controlled environment. Right now most of the early use cases may be available with Google’s suite of products
5. Start selling it as a services to anyone in the market – good long term approach, but it is early now to start selling it

Evaluation criteria: #users, understand limitations/ potential

Recommendation:

Launch with on few Google products with varied applications – such as Search, documents, Analytics

This will give allow the service to reach high #users

Also assess possibilities/ limitations in multiple use case.

This will really help refine the product and make it full scale in future.

KPIs:

#total requests per month

#responses per month

Application on Search:

%times data is consumed (based on time spent on view port)

%clicks on ‘more data’ with summary response

Application on Documents (to add a data point):

%times data recommendation is accepted

#acceptances/ document

%times data recommendation is removed after acceptance

An API to convert free form text to SQL statements is a powerful API with a plethora of applications.

 

The strategy to take this to market would include: 

• Knowing the product
• Knowing the customer
• Understanding market fit
• Competitive landscape
• Distribution
• Sales

 Before going to market, Id like to understand the product, its features, and limitations better.

•  I’d work with engineering to understand what the driving idea behind the product is?
•  What are the kind of data servers that it can support 
• What is the kind of testing that was done on the product:
• –      Do we have metrics on hit rate of the converted statements
• –      Do we have the comparison of free form query versus optimized query written in SQL to see how efficient the result is?
• –      Does it integrate well with the popular SQL environments
• –      Does it integrate well with popular coding languages
• –      Does it integrate with existent Google services such as analytics, google colab, etc?

• Is this a standalone product or a web-based one?
• If standalone, does it have its own SQL engine?

1.  If web-based, does it have the ability to connect to web datasets, or in both cases we only have an engine to convert free form text to query, and that is the sole output of the product? 
2. If web-based, what kind of SQL tests have been performed on the product, is there a limit on the data size returned by the web servers?

Once we have this data, we can try and understand the audience for this product.

I feel we can segment the audience into four major groups:

 Sophisticated corporate users who already have engineering teams and data infrastructure in place, but would like to free up engineering talent to do things other than optimizing SQL queries

 Unsophisticated corporate and small business users, who have very specific data needs, such as small marketing firms. These firms have little to no engineering support in their organizations and rely on reformatted data sets provided to them as a service by vendors. This data is often generated from freely available/ licensed web data.

 Institutional users such as researchers who work at universities, whose primary interest lies in data, and are not technologically inclied enough to use SQL themselves.

 Individual users who use products purely to explore, and learn features.

Competitive landscape: At this time the market for free-form text to programming language is nascent with no runaway market leader.

 Google is uniquely positioned to launch such products in the way that it already has products in the market where extension into SQL is a natural progression.

 It has a large user base that uses google analytics to measure the performance of their products, apps, websites, etc. These analytics are actively used by unsophisticated users such as marketing teams to derive insights. Giving these teams the power to fetch more complete and powerful data sets or to optimize their queries from standard queries to very targeted ones can be a game-changer. It can lead to even more efficient data pipelines for google analytics

 One more google product that comes to mind when I think of this is google colab. The success of google colab in democratizing python IDE is unmatched. Extending the same platform and allowing for use of SQL will only make the movement more powerful.

 People can write standalone code on colab, and users who are simply python users with basic SQL skills can still produce data insights seamlessly without having to worry about data pipelines and SQL code.

 Considering the above, if driving this program, I would do a soft launch of the product in the same environment as google collaboratory and invite users from each segment to participate in the beta test.

Each set of users can help generate different data on the ability of the program.

Sophisticated users can help understand how well the code works against user-written queries, and help perform a cost-benefit analysis, on investing in the software.

 Non-technical users (which to me seem the largest customer base for the product) can help understand ease of use, and see how well the product connects real-time across various services.

 Individual users might sometimes test the limit of the program both technically and in design.

 Taking the example of non-technical users:

–      We can get an understanding of how we’ll this query performs, by checking how many attempts they required before getting the data they needed.

–      We can check how often they reuse these queries to gain an insight into how they may shift the way they use analytics

–      By tracking how often the product is used in conjunction with other services such as colab, we can get insights on how well the product interacts with other products.

As is with most google services, I think this should be launched in a freemium model, and data collected in the beta stage can help fine-tune the pricing of the freemium model

Success metrics:

# Conversions from free to paid model

# Fully paying customers