The CTO of a procurement market intelligence company, shares how they went from 100% services to 74% product, with the help of Formcept platform.

‍

About:

• Domain: Procurement market intelligence
• Revenue: $100Mn+
• GTM: Sales-led
• Interviewed in: 2024

‍

The trigger:

As a procurement market intelligence company, Our job is to aggregate the data from multiple different sources, make sense of it and give it to the client in a meaningful way. Beroe's move to become a product company started in 2015. I joined just because of that. My responsibility was to transform Beroe from a services to product company.

We deal with a lot of data. And serve approximately 20 industries. It is extremely complex because data comes from many different sources. And multiple different formats. Different frequency, different velocity. Many times, certain data, we don't even know that we have it. Several complexities in data gathering, data relationships, and eventually the data dissemination. Plus, the additional complexity of certain user preferences and relevance. Every big data problem that you can think of. 

We also saw that historically, data resided in multiple different places. In different people's laptops. And sometimes, in people’s heads. Source one doesn't know about source two. But as we began working on multiple different products, it was absolutely important that we know the data relationships. This price is related to supply demand. The supply demand is related to the cost structure. You can only make sense of something when you have such relationships built. So how do you build these connections to eventually make sense of the data? So that was essentially the big problem.

“We deal with a lot of data. It is extremely complex because data comes from many different sources. And multiple different formats. Different frequency, different velocity. Many times, certain data, we don't even know that we have. And the data resided in multiple different places. In different people's laptops. And sometimes, in people’s heads. As we began working on multiple different products, it was absolutely important that we know the data relationships. This price is related to supply-demand. The supply-demand is related to the cost structure. So that was essentially the big problem.”

‍

The solution:

Initially we were using some MySQL and Elasticsearch kind of databases. Now, in a traditional RDBMS, it is all pretty coded and predefined. Once you build that connection, that is it.  There are two kinds of logical relationships within the data. One is a technical relationship. My Category ID is my primary key and foreign key. Second is the contextual relationship. My business and the decision logic. Like price gets impacted due to supply and demand. Maybe the supply is going to be less or maybe there is some event that has happened or maybe there is a logistics shipping problem. Such a contextual relationship has to be ever evolving. It cannot be on day one, you just figured it out. 

Let’s say, I'm supposed to give you an alert on corn, and a drought happening in Mexico, which is the largest corn producing region. Now, how do I associate everything? First of all, I need to know that you are looking at corn. Then I need to know there is a drought that is causing some problems in certain geography. And then I need to be able to give you this information because that is what you need to make your best next decision. If you have a standard database and web developers, they cannot solve that problem for you.

Moreover, subject matter expertise often does not live with a developer. Let's say I'm looking at price forecast data for a particular commodity. And it says the price is going to increase by 20%? Then you ask, why is it going to increase by 20%? Now, let's say I have another table which has supply demand. How do I really know that this price forecast is actually related to supply and demand? A pure tech developer on day one has got no clue. I don't know any tech developers or database developers who understand economics. So the developer is not going to build a table saying, whenever somebody asks why price is going to increase by 20%, go and check supply and demand tables. 

We needed some form of data mesh to capture such smart relationships within data. Therefore you need a layer on top of your database that is intelligent enough to understand the data relationships. 

One of our investors spoke about this company called Formcept. I had my first conversation with them on those challenges: Look, I have this problem. I heard about you guys. Can your software help?. 

“In a traditional RDBMS, it is all pretty coded and predefined. But contextual relationship has to be ever evolving. Like price gets impacted due to supply and demand. Maybe the supply is going to be less or maybe there is some event that has happened or maybe there is a logistics shipping problem. It cannot be on day one, you just figured it out. If you have a standard database and web developers, they cannot solve that problem for you. We needed some form of data mesh to capture such smart relationships within data.”

‍

The result:

Formcept essentially manages that entire contextual relationship and decision logic underneath and says: This data is related to this, that it is related to that and so on. 

We had done a trial and PoC initially. We have a gut feeling that this product is good. The first year, we basically said, okay, let's go ahead with it. At the end of year one, we thought that solution does what it, we were looking at. Formcept also gave us a better and a more efficient way to deliver the data to our end users. 

At that time, I also did not have a team very large to focus solely on this. There were budget constraints. We needed someone in that space who understands data. I had no expertise within my team. With Formcept we found that combination of product and expertise. This was more like joint problem solving. The way the Formcept team tries to understand our problem and always tries to find a solution actually worked really well. 

Just about, I think six weeks back, I was just telling my team, okay, let's sit with Formcept, they can do it. Let's do a two week project with them. Formcept was like, “Okay, I don't know whether it is two weeks, but we'll try to do it.” Can I do that with a Snowflake or Databricks? Probably not. So the value comes from that level of willingness as a team to solve a customer's problem.

Five years back we were like 100% services and 0% product in terms of our revenue strength. At this point, we are 26% services and 74% product. That's the transformative journey.

“Formcept essentially manages that entire contextual relationship and decision logic underneath. With Formcept we found that combination of product and expertise. This was more like joint problem solving. Five years back we were like 100% services and 0% product in terms of our revenue strength. At this point, we are 26% services and 74% product. That's the transformative journey. ”