We all want our roads in good conditions. Don’t we? But, the definition of a ‘good’ and a ‘bad’ road may vary a lot. This is the challenge that governments and companies run through in the process of road maintenance: assessment subjectivity.

RoadBotics was born to solve this and other problems regarding road inspections. Through the same technology used to make autonomous vehicles to “see” the road, the startup makes computers analyze road conditions.

In this interview, Mark DeSantis, cofounder of RoadBotics tells me about the early days of the startup, since the idea until it started gaining traction.

SHOW NOTES

Let’s understand the problem you’re solving and the solution RoadBotics is offering to solve that problem…

THE PROBLEM

Road inspection has been a staple of road maintenance for a long time.

There are millions and millions of miles of paved road in the world. So, the process of doing that manually around the world is expensive, it’s tedious. But the bigger problem is you’re using humans to look at the surface and make judgments about it. And everybody’s opinion about what is a good road or a bad road is different.

THE SOLUTION

Basically, you download an app into a cell phone, put the cell phone in the windshield of any kind of vehicle, camera pointed forward, turn the app on, records everything it sees. As soon as the cell phone hits a friendly Wi-Fi, all that data goes up to the cloud, and a deep learning platform that isolates the road in the image, then begins assessing the surface of that road pixel by pixel.

And what it’s looking for are about three to four dozen distinct patterns that show up on any kind of asphalt or concrete road—like alligator crack, block crack, edge crack.

So, we’re able to do that by using a standard cell phone, some deep learning and assess that road in a far cheaper, far more efficient and consistent way for roughly about 160 municipalities, counties and states in a dozen countries.

LOOK TO THE ROAD!

The idea happened not exactly in a garage, but inside of Carnegie Mellon University. Right?

Exactly. Carnegie Mellon (CMU) is famous for its AI program. I think most people would argue they’re probably the number one AI program in the entire world. And among the programs they have inside the AI program is the now-famous Robotics Institute.

Within that, they have a lab that focuses on transportation. In fact, the Uber Lab and the Argo Autonomous Vehicle Lab—both of which are based in Pittsburgh—were ultimately spun out of Carnegie Mellon.

That same group came up the notion: “We’re using image processing to move a vehicle around. Couldn’t we use the same data to assess the surface? Because after all, we’re looking at the road.”

So, the idea was born out of the autonomous vehicle lab.

INVESTIGATING THE PROBLEM, TESTING THE SOLUTION

What were the first practical steps you had to do in order to develop the startup?

We did over 100 interviews with people, either in the business of road assessment, road maintenance, who kind of lived that life. We made no mention of our AI platform. We didn’t talk about any solution or anything.

We simply talked about their problems. “How do you assess roads? How do you determine what is a good road and what is a bad road? How do you collect the data?” All those questions allowed us to really get deep into the world of the customer. And then once we collected it—maybe 75-80 interviews—we knew that what we could do addressed that problem.

The second step was to create an MVP. We were fortunate we had already started, because some of the core technology was developed at CMU, but it needed a lot of work to get its commercial grade.

All those questions allowed us to really get deep into the world of the customer. And then once we collected it—maybe 75-80 interviews—we knew that what we could do addressed that problem.

Parallel to our market discovery—the hundred interviews—we developed a basic working version of the product such that when people used it, they could determine of whether or not this thing really added value for them. It’s not so much a way to make money—and we charged for it by the way—but it was more a case of to get elicit a response to see what customers were really looking for.

It [the MVP] had a lower resolution. Let’s just say we couldn’t see as much detail; It didn’t have the user-friendliness that the current version has; It wasn’t able to see all the things that needed to see; It wasn’t exactly presented in the most useful way.

But for the most part, everything that’s in the current product showed up in some version in the MVP.

HOW ARE YOU DISAPPOINTED?

What were the customers’ reactions that told you: “we have evidence that this is going to work, we can accelerate and try to scale it?”

That’s a really good question. People don’t pay enough attention to the type of feedback. Reactions like “Hey, this is great.” or “This is really cool.” weren’t terribly useful.

In fact, what we wanted is them to critique it and tell us where it wasn’t useful. In other words, we typically would get a reaction something to the effect of “Wow, this really saves me time and money, and has reduced the hassle!”

RoadBotics screenshot 1. — Source: https://www.roadbotics.com/

But, we were not satisfied with that response. We would say “When you say ‘save time’…exactly how? How does this compare to how you did it before? What do you mean by time? What aspect of time is it? The tim...