Back to resources

Building a Brand New Data Product

Engineering Processes
Working with Product Teams

26 March, 2021

Jérôme Basdevant
Jérôme Basdevant

CTO and Cofounder at Datamaran

Jérôme Basdevant, CTO and Co-founder of Datamaran, explains what it takes to build a pioneering data product and why having great data is not nearly enough.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

"You don't care about quality" A story of single metric bias

3 February

This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.

Productivity
Conflict Resolution
Working with Product Teams
Alex Shaw

Alex Shaw

Chief Technology and Product Officer at Hive Learning

V2 infrastructure project

21 December

Consideration for starting a multi year software infrastructure ( V2 ) project that involves hundreds of globally distributed engineers.

Stakeholder Management
Engineering Processes
Ahsan Habib

Ahsan Habib

VP Software Engineering at human

DevSecOps: Why, Benefits and Culture Shift

29 November

Why DevSecOps matter and what's really in it for you, the team and the organisation?

Leadership
Stakeholder Management
Engineering Processes
Building and Scaling Teams
Communication and Collaboration
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

Mindsets of High Performance team

14 October

Teams have tremendous impact on the products on they build. T.E.A.M definition - Together Everybody Achieves More is true. A collaborative and empowered team builds great product versus the good ones.

Leadership
Productivity
Engineering Processes
Building and Scaling Teams
Team Management
Strategy and Vision
Praveen Cheruvu

Praveen Cheruvu

Senior Software Engineering Manager at Anaplan

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Leadership
Stakeholder Management
Building and Scaling Teams
Communication and Collaboration
Working with Product Teams
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart