In this special ROS Developers Podcast series, we will explain how to build a robotics startup. This series is dedicated to all that are thinking about creating a robotics startup, either about hardware or software, but everything related to robotics.

Step by step, we’ll explain how to create that robotics startup with real-world examples, including:

• How to select your co-founders and team
• How to look for investors
• How to test your ideas
• How to get customers
• How to reach your market
• How to build your product 

And everything starts from zero. So we’ll cover all the steps to building a successful startup. 

Who I Am

I’m Ricardo Téllez, CEO and co-founder of The Construct, a robotics startup that delivers the best learning for aspiring ROS developers on how to program robots with ROS. Our company is six years long. We are a team of 15 people working around the world. We have worked with more than 200,000 students and dozens of universities around the world. They use our online academy to provide a teaching environment for their students. We have bootstrapped our startup. That means that we haven’t had any business investors. We tried the ‘investors thing,’ but for several reasons, we chose not to go ahead with the investment. I will explain in later episodes. 

With all this experience, I will teach you how to build a startup. And we will demonstrate the process by creating another startup so that you can see the path to creating your own. So, you are going to witness the creation of a robotics startup. 

You can take this as advice, and whatever you consider incorrect or don’t like, just discard it. That’s okay.

Then we are going to go.

Why Do Robotics Startups Fail?

Unfortunately, most startups fail. And, it is more common for robotics startups to fail. 

There are several reasons that robotics startups fail (I will add a few links here on the podcast show notes where there are some posts that analyze this situation). But I would like to mention that one of the most common reasons robotics startups fail is because we are engineers. 

We fall in love with our robotics idea that nobody wants to buy. We look for investors. We add more time and more money. But, in the end, we have a robotics product that nobody wants to buy, either because it is expensive or, more often, because it doesn’t solve a real-world problem. Instead, it is a robot that interests engineers but is not interesting for the market – for the consumer.

We often forget that the goal of a startup must always be to create a business, not create a robotics product. Okay, the business must be about robots, but it has to solve a real problem. Coolness doesn’t matter. To have a successful robotics startup, the business is what matters. Otherwise, we run out of money and die.

Examples of failures include the Jibo robot, the  COZMO robot, and the BAXTER robot. All of them are cool robots, but nobody wants to buy them! The companies raised millions of dollars. They failed because they ran out of money because they didn’t have a sustainable business model.

In the world of startups, many people are interested in generating round after round of investment, until they die. In this podcast, we will not promote the search for investors for our crazy idea. We are not interested in having a fun ride until the money is over. Instead, we are interested in building a real business. We want to create a business that produces money, as much as possible. Or, at least enough to sustain the team and research lines.

We may need investors at some point. But, our goal is not to get as many investors as possible and then have the business die. Instead, our goal is to get the required investment, if any, and then build a business as scalable and profitable as possible. Of course, we aim at a multimillion value company, but let’s not go so fast that we lose control and crash.

Let’s start, step by step.

Decide On the Idea

First, decide on the business idea. This is what we are going to analyze in Episode 1. We will follow three steps:

Step 1 – Decide which problem to solve

In this Step 1, we will decide what problem we will solve with our startup. That’s always how it must start – by trying to solve a real-world problem. The best way to identify a problem is to look for a problem you experience and where robotics can provide a solution, with the current technology. It could be a problem in the robotics field (for example, a new communication bus for transferring large amounts of data), or a problem in the real world that can benefit from a robotics solution.

For example, The Construct identified a problem with learning about ROS. The ROS official Wiki tutorials are amazing. I personally learned by using those Wiki tutorials. But we wanted to speed up the process of learning ROS, and go faster than what the Wiki provided. In response to this problem, we built The Construct. The Construct provides courses in our academy that are based on online simulations. So you can get the meaning of the different parts of ROS very fast and very quick, because you are practicing. So this is a problem in robotics where we provided a solution. But there are other problems in the world that can be solved by using robotics. 

Here have two considerations:

1. Don’t try to put robots where they are not needed. Just because you work on robotics doesn’t mean you need a robotics solution. For example, robotics companies have been trying to put robots in supermarkets, so the robot can move around the shelves and make the inventory. Well, a couple of months ago, Walmart canceled their project with Bossa Nova Robotics, which included inventory robots, after finding that by doing the job with humans, the process was simpler and cheaper. So that’s my first consideration for deciding about a problem to solve. Don’t try to put robots where they are not needed.
2. Don’t get caught up in the hype. Be grounded about what you are going to build. Don’t promise things that are cold, and you know are not possible. You are creating hype that will not deliver.

Step 2 – Decide on hardware or software

You cannot decide to attack both things. Decide on hardware and software, unless you are rich and have a well-trained team. Even like that, it is still a call for failure.

Deciding to work on hardware means that you will develop the hardware that somebody else will use for a purpose. Somebody else will put the software on it (apart from the basic software drivers that will ship with the product). For example, you decide to build a quadruped like Boston Dynamics. Concentrate on building the best quadruped and assume that somebody else will use it for a very concrete application by putting the software on it. Or, assume that somebody else has already written the code for an application, and you only need to include it in your product by tweaking it. For example, you need the ROS navigation stack for your hardware product. That’s also okay because you are basically developing the hardware and the drivers for that, but then you are taking software that already exists and putting it in your product. You are making minor modifications, but you are not developing the software. You are not maintaining that software. Do you see the difference? I hope yes.

If you believe it is absolutely necessary to build the software for the hardware you create because otherwise, your product will not work. In that case, you have a huge problem. If this is your first startup, I would not recommend it. If you still want to go in that direction, partner with a software company to develop that for you. For example, one success story is that IBM partnered with Microsoft to provide an operating system for their PCs. However, Microsoft didn’t do that for their phone. Instead, they focused on both the phone’s hardware and the operating system. In the end, they failed, and no one remembers that phone.

If you decide to concentrate on the software side, you may be creating an application that runs on multiple robots that already exist out there. Or, another option is to ship your software with an existing robot. You sell the robot with your software.

Deciding on one or the other is not easy. Each one has its advantages and drawbacks.

Software is faster to develop and requires less investment. It is easy to scale and distribute. It is easier to provide value to a customer with software. On the other hand, almost nobody wants to pay for software. Everybody wants software applications for free. They see the value, but they think it should be free. That’s the world that we are in. To make a real business from that is going to be very difficult.

Everybody sees the value of hardware, so they have no problem paying for it. However, the robotic product must provide real value. It requires a lot of money, and it’s a slow process to develop hardware. It takes a long time to do every cycle, and if you make some mistake and only notice it weeks after you were done, printed, and built, then you have to go back all those weeks. So it’s harder to develop hardware.

As an example of the difference in public perception between software versus hardware, I would like to share my experience selling online courses, which is similar to selling software. We get calls from people saying they have bought a 10.000€ robot and want to learn to program it. However, when I explained that the courses were 39€, they didn’t want to pay. They are willing to pay for the 10.000€ hardware, but they think 39€ for a lesson is too much. Crazy world!

Finally, you must use ROS. Yes, or yes? ROS will save you time, so much more than you can imagine. Please, please do not develop your own framework. Instead, just ROSify your product. You will save countless months.

But I don’t know ROS! I heard this from the back of the room. Then, quickly go to our ROS Intensive Training and learn it. We provide the fastest method to learn ROS, including how to apply it to real robots. Learn ROS right now. It is your best investment of time.

Please, please, please do not try to build your own framework. It’s not going to work, and it’s too much work. The Jibo and the Cozmo did it (and I think the Baxter also, even if later they build a ROS mode), and you know how they ended.

Step 3 – Narrow the solution as much as possible

Now that you have your idea, reduce the scope. If you are like other passionate engineers, you are already thinking about all the marvelous things that your robotic product will do. You need to cut them by 90%. Just leave the essential 10%. You need to think about the very core of your application.

The reason is that you need to validate your idea as soon as possible. To validate your idea means testing to ensure that somebody is willing to pay for your product. And the only way to do that is to put your product on the market, as soon as possible, and convince people to buy it. Nothing more. And, you need to move fast; otherwise, you will spend all your money before you have something to sell. Also, you don’t know if your solution is required by the public. So, narrow the idea to the very core, the one that allows you to show the basic functionality. That is what you will build to show to the public and see their reaction.

Recap

See below a summary of the three steps:

1. First, decide which problem to solve without trying to put robots where they are not needed, and creating hype.
2. Second, decide that either you are working on producing a hardware or software solution.
3. Last, narrow that solution as much as possible. 

I know that the three steps were not what you wanted to hear. If you are like us, your idea is to build a master robot that will understand the human language under a lot of traffic noise, grasp anything from any place, and clean the house while moving the furniture. I do not mean you cannot do that, in the future. But now, start small. So cut, cut, cut. And then cut more! Cut your idea until you have the bare bones.

A Real Example: Our Startup Idea

Let’s decide on the startup that we will build during this podcast series:

1. Which problem will we attempt to solve?

I hate waiting in the queue for my coffee, especially when I decide to stay at the coffee shop table. So I want a robot that brings the coffee to the table directly from the barista. The idea is that we can order coffee from the table using a web app. The order goes to the barista, who prepares the coffee and provides it to a robot that then delivers the coffee to the table.

2. Hardware or software? 

We will concentrate on the software. We will use an existing mobile base that provides all the hardware functionality. We may need to build some covers for our own look for the robot, but that should be the only hardware thing that we do. The rest, we will dedicate to configuring the ROS packages necessary for it, providing the usage interface for the barista and the coffee shop customers.

3. Narrow the problem

The robot will only deliver coffee in standard cups with a lid. It is not possible to serve cups with no lid. No cakes, no sandwiches, no cans. Only coffees, teas, and frappuccinos are in standard cups with a lid. Of course, the robot doesn’t have any arm that manipulates the beverages. It only has the wholes where the barista will put the beverages and from where the customers will manually take the beverages. The robot doesn’t have any sensor that detects when the cups have been taken from it. Simpler, it waits for a fixed amount of time and then returns to the barista. The robot doesn’t auto-charge. So, when the battery is gone, it is gone.

This is the first version we have available. We have used this robot cafeteria in our Managing Fleets of Robots Summer School to test the market response.

As you can see, we are trying to build something for a very specific problem that we suffer and that we know, as roboticists, can have a robotic solution. We also restrict the problem to a very narrow case, and even like that, we’ll have a lot of problems.

As you will see in future episodes, this business is the point of departure for the startup. That doesn’t mean that we will end up with a company building those robots. Most likely not. This means that we will try this business and see how it works and quickly adapt our ideas if we see that it doesn’t work. So, don’t get too attached to your original startup idea because it is 80% sure to change. But that is the subject of another episode.

Also, you can find contact details in the show notes. Then with nothing else to say, I’ll see you in the next episode with a new lesson from the experts. Until then, keep pushing your ROS learning!

Related links

• Why robotics startups fail, the document made by Fresh
• Jibo robot
• Cozmo robot
• Baxter robot

Subscribe to the podcast using any of the following methods

• ROS Developers Podcast on iTunes
• ROS Developers Podcast on Stitcher
• ROS Developers Podcast on Spotify

Or watch the video

Podcast: Play in new window | Download | Embed

SUBSCRIBE NOW: RSS