Building a Brand New Data Product

Problem

Our product is geared toward large corporations to help them identify and manage at the strategic level their non-financial (environmental, social, and governmental) risks. Traditionally, that is a job done by consultants, and we were the first to come up with software that could replace consultants.

The first thing we did was build a data engine and analytic platform that would enable us to collect and analyze data. Though we had some great data, and people could have insight into some things for the first time, we struggled to translate it into a powerful, scalable solution that people want to buy. We knew our model had a lot of potential, but it took us a couple of years to develop a pioneering, robust product.

Actions taken

We wanted our product to emulate consultants; they were our competitors, and we knew what they were capable of delivering. We set ourselves a challenge to get better results by using big data instead of interviews and other techniques applied by consultants. We tested our approach on three to five different clients -- again, similar to what consultants were doing -- and built a model that would embed the logic and analytics that would bring us desired results.

After completing those three to five projects with clients, I felt confident that we have the right recipe for building our product. We started to work on an MVP, and three months later, we could drive in our business model and make it into the software.

We conducted the exercise by working with clients in a low-tech environment using Excel sheets and building a simple model around it. That helped us quickly test out and get feedback both from our business experts and customers. We also benefited from working with a client who challenged us and our data, asking us to run some new simulations in the back, which allowed us to propel our product further.

Between developing the first version of our model and the second one, I realized that we had to distance ourselves from the initial approach of replicating the consultancy model. The consultancy model allowed us to move fast, zoom in on particular problems, and take shortcuts. However, that model would tell one story -- a story of a user who would buy our software --, and we wanted our software to be able to generate other stories as well. The game-changer for us was when we went for deconstruction. We were no longer focused on one story that we wanted to tell but on all the possible stories that could be derived from those data.

Lessons learned

• Unlike B2C, when you provide advanced services to a company, you should try to discover their underlying needs by doing a project a few times as a consultant. Deconstructing that approach and transforming it into a product is a great way to move forward quickly.
• As a CTO or product leader, I found how I could push back all the unreasonable requests I would get from the business. I would ask them to do it as consultants a couple of times, show me how they are doing it, and I will be able to include it into a product then.