The AI trap
Why it doesn’t make sense to go deep into the AI part of a new project too soon
A couple of weeks ago, I announced on LinkedIn that we, my co-founder and I, founded the start-up Netwerk AI. For the last few weeks, we’ve been working hard on a first iteration of our MVP (“Minimum Viable Product”): A company navigator for the Executive Search recruitment space.
As I mentioned in that earlier post, our goal is to improve the company research phase for executive search. We think that using Artificial Intelligence is necessary to solve this properly (detecting companies that do similar things, or have a similar culture, is something that requires building representations and learning similarities between them). However, instead of spending a lot of time on the AI at first, we decided to start building the interface first. AI is necessary, but not sufficient.
This might not seem like an obvious choice to some, so we wanted to explain our rationale here. In this post, I’ll walk you through the three main reasons:
- It’s about getting feedback
- It’s about showing rapid progress
- It’s about actually using AI
Getting feedback
An important reason for starting with a simple back-end implementation and actually focussing on the front-end first, is because it allows us to get feedback early on. Feedback is super relevant for products, and startups in particular. It drives the build-measure-learn loop, introduced by Eric Ries in his book Lean Startup. The front-end is a natural component to collect feedback, because it’s where a customer interacts with the product.
The most obvious type of feedback we are looking for is on the interface. It is the thing that they’ll interact with, so it needs to work relatively smoothly. And while this is still very much an MVP with rough edges, we want to know what works and what doesn’t.
More importantly, we want to collect feedback on how our customers will be using the product. With an interface, even if the results are not perfect yet, we can collect feedback on how the product can integrate in the research and recruitment process. We interact with our inner netwerk (our first launching customers) to understand how they intend to use the product, but also what kind of use cases they have and what they are missing in their current process.
Another piece of feedback that we are looking for is feedback on the results. As said in the previous paragraph, the results will not be perfect at first. So, having a mechanism to flag weird or incorrect results will help in getting a feedback loop going. This is important, since we believe in humans in the driver seat. Feedback on data will improve the results, but also allows us to learn what results are more relevant to a particular customer. And while some users feel right at home with sober-looking, developer-first interfaces, more often than not, a good interface helps to understand the intention and the data that’s being presented.
Showing rapid progress
Another big reason for starting with the interface is the need for rapid iteration and showing progress. As Marty Cagan wrote in Inspired, iteration is important to learn how much time it will cost to build something and, more importantly, how to provide a stable solution for the customers. Some quotes from the book that I found, ahem, inspiring:
“We can’t know how much money we’ll make because that depends entirely on how good the solution turns out to be.”
“Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers.”
“Good teams understand the need for speed and how rapid iteration is the key to innovation”
“[T]eams competent in modern discovery techniques can generally test on the order of 10–20 iterations per week.”
For us, an important reason for iterating quickly is that we want to adapt to our (changes in) understanding of the requirements. With an interface, it’s easier to understand how our product fits in their workflow, but also easier to observe and discuss with customers what works and doesn’t work. This again leads to quick changes allowing us to continue the conversation.
Actually using the AI
The result of our recommender system, is something that needs to be consumed; embedded in a workflow by one of our customers. As noted previously, some users feel right at home with a spartan interface with white letters on a black screen, but most often than not, people prefer to use something with a bit more polish. Furthermore, navigation of the results will be crucial, and for that good interaction is essential. This navigation works by allowing the user to very easily and intelligibly modify their search criteria, based on their own changes in understanding of a particular field. We also want to make the product a pleasure to use. Ines Montani, co-founder of Explosion, wrote in How front-end development can improve Artificial Intelligence on the importance of frontend development for AI:
“[…] the end goal is to use AI technology to power a product”
“If your tools are bad, the task will be boring and frustrating, and as a result, the workers’ input quality will be low”
We are committed to building an applied AI product, where the AI is used to solve a problem, and we need an interface for that. By building an iteration of the interface first, we make interpreting the results a bit easier, and therefore make it easier to work on the quality of the results. Plus, we can use feedback from the users on the data. By thinking about that early on (the first iteration is a simple “flag” that stores any weird result with the respective search parameters), we can collect data from eager contributors.
What AI we are applying now
Since we’ve wrapped up our first increment of frontend work, we are now starting to work on the AI-part of the product. At this time, search and comparison is done by relatively simple methods such as pre-trained word-embeddings and cosine distances. Now, we start to move towards improving the keyword extraction first, and representation and comparison of companies second. This is a necessity for a useful MVP: if our customers can’t find any relevant companies at all, they will not use the product.
After the first iterations though, we’ll start focusing on things like learning to rank and other methods for incorporating the feedback that we start collecting when we launch with our inner netwerk. Other things of interest are methods like neural retrieval and directly incorporating user feedback in personalised results. More on our AI process in a later article.
In conclusion, we are building our AI frontend first to learn quickly, iterate quickly, and collect quality data. It’s important to us to do these things to understand the needs, react to new use cases or new understanding, and to improve our models. It will also prepare us to be, dare I say it, agile in the future. Connect with us on LinkedIn, or join the Netwerk to get updates on our company navigator.
References
JP van Oosten (2021) LinkedIn Announcement of Netwerk AI https://www.linkedin.com/posts/jpvoosten_in-the-past-8-years-ive-had-a-few-different-activity-6843840226008276992-VMbl/
Minimum Viable Product (MVP) (n.d.) productplan.com. Retrieved October 21, 2021, from https://www.productplan.com/glossary/minimum-viable-product/
Eric Ries (n.d.) The Lean Startup Methodology. theleanstartup.com. Retrieved October 21, 2021, from http://theleanstartup.com/principles
Marty Cagan (2008) Inspired. See also https://svpg.com/inspired-how-to-create-products-customers-love/
Ines Montani (2016) How front-end development can improve Artificial Intelligence. Explosion.ai blog. Retrieved October 21, 2021, from https://explosion.ai/blog/how-front-end-can-improve-ai
