My team and I created FieldFinch, an app driven by the purpose of connecting academic experts with other academics outside of their own network. The sources we have investigated revealed that connecting people with a specific required skillset can be hard and very time consuming. So, we started by examining the problem and trying to find value that we can offer to solve this pain point for our future customers.
Our project started with a broad idea: an app that connects all kinds of professionals with each other, inspired by functionalities from the Tinder app, as swiping and matching profiles. Including both academics and business-related professionals we tried to keep our potential customer base as wide as possible. But early in the project we received feedback that our customer segment was too vague and needed to be narrowed down. This first pivot seemed not as big of a deal at first, but throughout the project I realized the extent of the influence it had. Narrowing down our target group to a specific user had many upsides, such as being able to describe a concrete problem, identify direct competitors and differentiate. More importantly, it enabled us to find data relevant to this user group, implement and test our AI model more efficiently. Instead of generalizing our end user to serve a bigger market, we got to focus more on the user specific problem, identifying key matching requirements that aren’t offered by competitors.
My main responsibilities were the prototype and the competitive and ecosystem analyses. The strategic decision taken at the start of the project was reflected in the complementors and dependencies as well as in the platform position and defensibility.
Working as a team on a project consisting of nine components that are interdependent made coordination as important as content. The dependency between the different components created threats as well as opportunities. Some parts could not be started until the previous part was finished, but finished parts could serve as inspiration or information for the next part. The idea of another team member to use single sign-on to verify that our users are active within the academic field, made me think of other institutions to complement our core workflow. This is when I came across the idea to use ORCID data to prefill accounts to start traction on our platform. Collaboration with team members made me more aware of the valuable information that could be hidden in the works of others. And how from one perspective a component could seem like a threat and from the other perspective it could be an opportunity.
Many of my decisions in the ecosystem analysis were direct reactions to choices made in other parts of the project. When we decided that universities must pay for institutional licensing, university login became a dependency instead of an extra feature. Without single sign-on through SURFconext we couldn’t sell institutional licensing. This choice made grant offices a relevant complementor, because they work from within the universities we want to actively search for partners for grant applications. After working this out, I looked for grant offices outside of the Netherlands and found EARMA. This European network of research support offices could serve as a way to reach grant offices across Europe and expand our cross-border activities.
The most surprising result came from our evaluation. Our AI search found five times more experts from other fields than keyword search, but no method could find the person the researcher had actually collaborated with. When we tried to focus the model on finding more cross-field results the relevance dropped to zero, so we kept the first version. We also did not manage to test the prototype with real users because it is a clickable demo. These results were not what we had hoped for, but they did make our recommendation stronger. Rather than proposing a full launch, we propose starting with a small pilot at one research office with clear go and no-go targets.
Before this project I assumed the implementation of AI would bring a competitive advantage. But throughout the project I started to realize that AI on its own does not. I already knew this from the course literature and lectures, but working on the project in practice made it fully sink in. The generative AI models and the data we would use are open to everyone, so any competitor could build the same thing or expand their current value offering. As I worked on the competitive and ecosystem analysis, I started to learn how the defensibility lies in what is built around the AI. The interaction data from ratings after each match and embedding university workflows are the main factors that could offer a sustainable and competitive advantage for FieldFinch. I now understand how language models behave as an amplifier that strengthens assets such as unique data and customer relationships, but without those it amplifies nothing that competitors could not copy. The biggest threat is not a bigger and better algorithm, but a company like Elsevier, which already owns the data and the users, and could easily extend their current operations to include our service within their own platform.
In future projects, I would spend more time analyzing the problem before choosing a solution. We used this principle for this project, but I think I would spend more time using it. In this project, we started primarily with an app idea and then looked for ways AI could fit into it. As I learned in this course, next time, I would first investigate a problem in depth: who has it, what causes it and where exactly the bottleneck lies. Only then would I look for the model or application that best solves it.
