Episode 60 – Robotic Process Automation with Antti Karjalainen, Founder / CEO of RoboCorp

Intro

Michael: Hello and welcome to Open Source Underdogs! I’m your host Mike Schwartz, and this is episode 60 with guest, Antti Karjalainen, a co-founder and CEO of RoboCorp.

RoboCorp is a vendor in the RPA or Robotic Process Automation software market. It’s a type of software that allows businesses to automate repetitive and routine tasks typically done by humans through the use of software bots or robots. These tasks can include things like data entry or customer service interactions. If you’ve ever gone to a website and a chatbot pops up – that might be powered by RPA.

As you can imagine this software market is growing rapidly as more businesses are looking to automate their processes and improve efficiency. RoboCorp is a newer business than I thought at first, given how thoroughly they’ve established a leadership position in this very competitive market. Antti has a lot of great insights, so without further ado, let’s cut to the interview. Antti, welcome to the Underdogs podcast.

Antti: Thank you, Mike.

Origin

Michael: So, no founder interview is complete unless we hear the origin story. I take it as a young undergraduate student, you probably didn’t predict your career in RPA. So, how did you get into the industry and how did RoboCorp get its activation energy?

Antti: Yeah. I mean, that’s a long path obviously when we talk about these kind of founding stories. It all started with me just by doing software engineering work after graduating. And I ran a small consulting company around software engineering. And with that, we used to do a lot of Q&A test automation with a project called Robot Framework. It is a python-based keyword-driven test automation framework. I got into that community while using it. It is based out of – well, the project came out of Nokia, so that’s why the Finnish roots.

I got into the community, started doing things around the open-source project, hosting events, stuff like that, and then, I bumped into RPA, which is starting to emerge and take off around 2016 and 2017. And I thought immediately that that has a lot of commonalities with the test automation. In test automation, you obviously drive a system to validate it, and in RPA, you drive a system to perform a business process. So, I thought that maybe Robot Framework could become the leading open-source community for RPA and started on that path eventually after my first company got acquired.

So, a few years later, I’m looking at the market and there’s this big competition emerged, raised a bunch of money, started growing really rapidly, and RPA was the fastest growing segment and Enterprise software for like three years in consecutive.

So, I thought that somebody needs to build an open-source solution for that, and I didn’t see any other person having the right connections to do it, so I decided to start on that path myself and that sort of lead into RoboCorp. I felt that I had to do it in a way.

Product

Michael: What are the products that RoboCorp sells?

Antti: We sell one product, which is the Control Room. That’s the proprietary component in the stack. That’s the orchestration platform as we call it in RPA. That’s how you deploy the bots, manage them, govern them and manage user rights and so forth. So, it’s really a central piece in how RPA works and how the bots actually get to execute work.

And then, we have a bunch of other components in the stack. You know, namely the code open-source stack, which allows you to build a bot and run it. And then, obviously all the automation libraries that enable you to connect to various applications, from browsers to mainframes, to ERP systems. And then, we have the developer tooling on top of that which creates a good developer experience. So, anything really outside of the core control room platform is open source with us.

Low Code Strategy

Michael: One way that RoboCorp has been innovative I think is through the use of Low Code. And why do you think that Low Code is so critical in your market?

Antti: In RPA, you deal with different sorts of developer personas. Some are very technical, come from a developer background, others might come from a accounting background for instance. So, when RPA got popular, it was marketed as something that anyone can really use to build these bots. But then, as it got adopted into the Enterprise, it sort of went into more complex use cases, more mission-critical use cases. So, it became a automation professional domain.

We started out with the automation professional in mind and built this Robot Framework and Python-based tools for them and got initial success with them, but we soon realized that it’s too different for the developer persona to be targeting.

They expected to have a drag-and-drop interface in front of them. So, we started thinking, okay, how can we innovate and create something that’s actually meaningfully different in that space. And so, we built a local layer on top of our open-source stack, which allows you to create a local solution, but it generates code in the back end. So, we call it “Code Native Low-Code”.

So, you work on this drag-and-drop interface, you build the automation from individual steps, which might be like opening browser, clicking elements, etc., and in the backend it’s converting that real-time in the code. And back, if you edit the code, you’ll see it in the local as well.

So, that was just the market expectation, and we wanted to sort of not be an outlier there to be perceived as more difficult than the competition, while in real life it really isn’t.

But coming from a background where RPA developer might not have actually written a line of code, presenting them with a VS code editor is just too jarring of an experience. But I think we balanced it the right way, where we can still keep the both worlds next to each other, low-code and then pro-code, as we call it here.

And it has been a pretty interesting journey to build something that hasn’t been built before that way.

Community

Michael: Can you tell us a little bit about the community? You mentioned you started with an open-source project in Python – were you able to bootstrap that community into the RoboCorp community? And how is it going building that community out?

Antti: The Robot Framework Community is pretty extensive. I think the project gets around 1.5 million downloads a month from Python package index. So, it’s used extensively in end-to-end testing in Q&A. And initially, what we took out of that was all the integrations that had been built over the years.

So, we get to leverage this massive base of all these libraries that integrate into various systems that Robot Framework was used to test, started out building our own tooling. And sometimes, the test automation community doesn’t really overlap with the RPA community, so we had to start building our own community as well. Sometimes they do overlap. We have customers who are now consolidating their test automation engineering, first with the RPA engineering, for instance.

We have customers who are coming into our products because they know Robot Framework already, and so they’re experienced with the tech and have confidence in it. So, to a decree, this overlap in those communities, it feels like we are building these two parallel communities that overlap in parts – it’s like a Venn diagram in a way.

How Low-Code Impacts Onboarding

Michael: One of the areas I feel RoboCorp is doing a really good job is by reducing the friction to onboard people into both your community and also into the commercial engagement with RoboCorp. And I wonder if low-code is maybe a gateway for people who go into the pro-code area. But can you talk a little bit about how that journey works from getting newbies and getting them in to be RPA professionals and customers?

Antti: Yeah. For sure, low-code isn’t a big enabler there. You’re not staring at like a blank screen, but you have all these capabilities listed as actions that you can start dragging on a canvas. So, it’s something that pretty much anyone can start doing, and you don’t have to have an in-depth tutorial or training to be able to do that. So, it’s a big enabler.

And also, by the way, we see the test automation community now starting to leverage the automation studio, the local tool as well. It is definitely excitement – low-code. And for good reasons. I mean, you can frame out some solution that you have in mind in minutes rather than learning the syntax from scratch.

And then, when you want to refine the solution, you can go into the code and start customizing it, maybe building custom Python in the creations, Python keywords and so forth. It is actually something that I prefer to use even with my developer background. If I start a new project, I start it with the low-code tools frame it out, get the structure right, and then might go in the VS code and I finish it up. But it’s such a big step up in the ease of getting started that you don’t really need to install Python, bunch of libraries, figure out your Dev environment, all of that – that just goes away. That just gets easy, but both sides of the community, pro-code people and the local enthusiasts like to use it.

Cloud Native Impact

Michael: So, one last technology question. Cloud Native has been a really – I mean, for me at least, it’s felt like a monumental shift in sort of how the customers deploy and operate. And I’m wondering if you’ve seen something similar in the RPA market, where Cloud Native has impacted or open new opportunities for delivery?

Antti: Yeah, definitely that’s a big part of what we do. The Control Room itself that the orchestration platform does, some Cloud Native SaaS solution – that’s something that you can just few minutes click into it and get an account going. That’s a great way to deploy RPA across a number of organizations, a number of different companies if you are a service provider, for instance. Building obvious solutions, you sort of have this single pane of glass that you can operate across.

Now, with RPA is also a double-edged sword. It sort of comes with benefits and the negatives as well. RPA is typically something that you do with applications that might be inside corporate firewalls, inside private Cloud environment. So, the bots actually need to operate typically in on-prem environments. And still, we use a Cloud Native solution to deploy them. And there’s a lot of architecture and engineering questions that we had to solve to make it as secure and robust as possible, to make it happen and be seamless for even the largest Enterprises to be able to adopt it.

Obviously, the benefit is that you get a single version deployment, you don’t have to go through installing a lot of infrastructure to get it started. You don’t have to update versions, you don’t have to maintain databases and so forth, but I think, especially with RPA, since it’s dealing with quite sensitive business processes typically, it deals with sensitive data as well user information, healthcare information, financial information, the security questions around that information are significant, and also compliance. So, that’s one key part of how we architected the Cloud Native products from the beginning, to be able to service on-premise use-cases.

Customers

Michael: Who are the customers of RoboCorp today?

Antti: We serve a number of different types of customers. First, starting with the Enterprise, we have a number of large Fortune 500s and Global 2000s in the customer base. Some of the public references are companies like Emerson Electric, Ally Financial in the US, and there’s a lot of Enterprise customers that are still not public referenceable. But then, additionally, we have a large base of implementation partners – they have different business models, so they might offer a managed service on top of RoboCorp, where they build business process automation and deploy that across customers. It might be healthcare specific automations, it might be insurance – really any vertical, you name it – and then, there’s the system that created community who offer services on and around RPA.

We cover from mid-market customer base, in broad range of verticals and geographies and all the way to the highest Enterprise tears.

Segmentation

Michael: It’s interesting to hear you say that you had partners who are maybe developing business specific vertical solution and then marketing them – is that a strategy for segmentation or are you trying to identify, my guess, markets that you can deliver business value into and partners who can deliver that?

Antti: Really, it boils down to direct Enterprise customers, and we do get some mid-market customers that are good with us. But then, the partner strategy is really in the core of the company. The opportunity with RPA is so vast, so you can basically imagine any kind of company and they will have use cases for RPA. So, it comes down to whether the customer has a team of their own around business process automation. They might be using API-based solutions, all kinds of intelligence document processing, and together with RPA, to build end-to-end solutions inside a corporation.

Or then, when we go into the mid-market and below, it becomes a use-case driven segment. So, that’s where you need to know the specific ins and outs of, let’s say, mortgage origination. Their partners are better off to serve their own sort of expertise area. It is basically we sell directly to sort of teams inside Enterprise, and then, we have the partner ecosystem to serve on a use-case basis. That’s how we think about it.

Partners

Michael: Are these partners globally distributed?

Antti: Yes, definitely. We basically have partners across all the continents. It is really distributed right now, and there’s different categories of partners as well. Some of them might offer business process outsourcing services, some of them are automation pure-play vendors as we call them. So, they specifically focus on automation services. And then, they are the big force, the accounting companies, so they will typically also deploy RPA with their customer base.

It’s really wide range of different kinds of partners. And within that base, there’s different kinds of business models that they deploy. Everything from reselling into consulting, into system integrator work, into managed services.

Team Pricing

Michael: Is the RoboCorp team similarly globally distributed?

Antti: Oh, yeah, for sure. We are right now, I think, in nine different countries, about 50 or so people at the moment, adding headcount right now. But we are fully remote company and we’ve been like that from the beginning. So, engineering, typically, is around Europe. And we do have a big base in Finland for engineering, but it is also distributed as a product engineering design. And then, our partner operations are right now led from Europe, and then, the broader go-to-market team is in the U.S. so, sales marketing customer success.

Michael: I always warn founders about how hard pricing is. There are a number of strategies to price I saw in the RPA market – what is a RoboCorp strategy and how long did it take you to get there? Did you get it right the first time and where are you today?

Antti: Oh, man. I mean, pricing is really difficult, it goes across everything really. When I got started with RoboCorp, I started kind of building the vision for the company. Now, we knew that we wanted to be the open-source standard for RPA for sure. We wanted to innovate around how do you build bots, how do you operate and manage them at scale, deploy them at scale, all of that stuff, make it more robust and resilient and faster, all of the technical attributes that you want to have for solution like this.

But then, the second big innovation there was around pricing itself and the business model. RPA traditionally has been really complex in license, and you can imagine this like a large Enterprise pricing scheme, every item has their own price tag, starting from a developer license to a test license, to an orchestrator, to a bot license, to an attended bot license, and you name it.

We wanted to make it really simple. We sort of went back to first principles and started thinking about, “Okay, what is the best proxy for value in RPA?” Traditional RPA will be pricing bot licenses.

So, essentially, you have a bot license that allows you to run one bot at a time. If you want to run two bots at a time, you purchase another license or so forth. And if the bot isn’t doing anything, you are still paying for the license. We thought that the better capture for value is going to be around consumption, and namely the working time of the bot. So, whenever your bot is working, you’re producing value, and so that’s the proxy.

We were the first one to build a consumption-based pricing model. And we did it from the beginning and started building the whole platform with that in mind, that we wanted to get rid of the concept of a bot license and go to consumption. And that still works, people love it. And they like the sort of flexibility of it, they don’t need to know how many licenses they need to purchase in advance. People will have peak demand loads at the end of the month or end of the year, end of the quarter, they will run reports that the bots will do. And those can demand hundreds of these bots working at the same time.

So, it really allows them to think of the processes from the best engineering perspective rather than thinking from a licensing perspective. That was my good starting point, but then comes all the details, like all the small details. Okay, you’re running a bot that needs to work 24/7 with a minute best price that becomes really expensive. So, we needed to add billing caps on a process-by-process level to cap the value at some point.

You want to do parallel execution, these kind of things – there’s different ways to really make it work. When you go into the Enterprise, you get into these conversations of, you know, we are ramping up, we have all these plans for RoboCorp, but we don’t know how much we’re actually going to consume.

If they’re coming from a legacy RPA platform, we are typically two to three times faster to execute, but they really cannot know in advance. So, we need to make provisions for first year, onboarding, ramp up, all that stuff. So, pricing is really, really difficult even though we try to come up with the most simple and elegant pricing scheme possible. And it’s still an ongoing process – we are actually redoing some of the pricing right now as we speak.

Value Prop Evolution

Michael: From the day you started, you had a certain value proposition in mind. And what are the most important parts of that value proposition today that maybe differ from where you originally started?

Antti: You know, we thought out that we will have this more of a bottom-up approach to RPA, where you can simply just download tools, explore them, build something, and then get it into use, into production as a self-service motion. And we thought that that would take us into a growth path.

So, we built the product in a way which allows you to do like full self-service, but then, over time, we realized that in RPA, you typically have a different buyer than the technical user is. And the buyer is very non-technical. So, we needed to start adding a lot of this sort of top-down aspect to the product itself and into the selling motion itself.

You know, in the recent years, I realized aspects of the value prop that we even didn’t fully understand ourselves, things around being able to store the bot code in GitLab and GitHub and user version control, now, the typical low-code solution doesn’t do that for you – it is all a proprietary XML-based model that you operate with, so that really isn’t a facilitate versioning.

When we went in first time and did like larger financial institutions, they told us that, “Hey, we chose you for one reason: because we can actually audit the bots, we can put code review processes around these bots.” And not for the reason of validating that the code is good quality, but actually, validating that the digital worker doesn’t go rogue, doesn’t do things it wasn’t intended to do.

So, the fact that we can do proper version control actually meant proper governance and controls and compliance for our customers – that was a new thing that we discovered some time ago. As we’ve gone into the Enterprise, and we got really good success stories there, things like reusable components across the bots, so you can share code between the bots and build asset libraries that you can leverage in future bots that you build. You don’t need to re-implement all the functionality again and again, like you would do in a more traditional local platform. You know, these things have become more and more valuable over time to ask on the customers.

Advice For Open-Source Entrepreneurs

Michael: I guess, as we tie this interview up, I wanted to get your thoughts on the open-source industry maybe more head large. As a successful founder, what do you think are some of the challenges that other entrepreneurs who want to use open source as part of their business model are facing today?

Antti: Yeah, that’s an interesting question. Now, open source does have many different kinds of business models around it, I think. First of all, understanding what you can do around whether it’s an open core model, whether it’s a support model, or Cloud-enabled model. That’s the choice that you have to make kind of early on as you start building.

Sometimes, open source can be a one-way door. You put something out there in the public domain, you don’t get it back. So, realizing that and being mindful of what you actually put in the open-source side of your business – what’s proprietary, how do you monetize, how do you do that, it’s an important decision. And you know, we’ve seen companies in the last decade or so, going to open source and potentially give out too much of the value prop.

I think Docker has been a good example of that. Now, they’ve actually turned around and doing great, but for a while, insiders I’ve heard saying that we gave out too much, that we didn’t capture the value. So, being mindful of what the customer wants to pay and trying to make it meaningful. You don’t want to build artificial gates.

For instance, whenever somebody’s using our purely open-source stack in a large Enterprise, we’re super happy about it because that’s still using us instead of the competition.

I encourage everyone to use RoboCorp even though you wouldn’t be paying for us – that’s all-net positive to us – but just being kind of mindful of where are the gates around paid, what the value is that you’re delivering. It might be things that are sort of not obvious for technical people, like myself, where it’s around governance and compliance, which is a huge hassle for a larger Enterprise customer.

So, understanding what the intended buyer is willing to pay for is one key part of it. And second is, is there really a open-source flywheel that you can leverage, is there a community building on top of your product committing directly to your product, are you willing to take in those contributions as they come in, how do you control a community roadmap for instance? Or is it more like building a component that then gets integrated into other open-source – I mean, there’s so many different pathways that you can explore and kind of plan for us as you go forward.

Closing

Michael: Antti, thank you so much for sharing these thoughts with our audience, and I wish you guys the best of luck in the future.

Antti: Thank you. It was great being here.

Michael: Thanks to RoboCorp for reaching out and the Gluu team for helping me pull this episode together. Cool graphics from Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

If you’re interested in open source, especially if you are based in Europe, you should check out the State of Open Source Conference in London, February 7th and 8th – I’ll be there. I’m even recording a podcast live at the event.

So, until next time, this is Mike Schwartz. You are listening to Open Source Underdogs. Thanks for listening.

The post Episode 60 – Robotic Process Automation with Antti Karjalainen, Founder / CEO of RoboCorp first appeared on Open Source Underdogs.