Shieldcast: Episode 013

Richard Mabey is co-founder, CEO at Juro - the all-in-one contract automation platform.

Richard trained as a corporate lawyer with Freshfields before an MBA at INSEAD and a product role at LegalZoom.

He's a Fellow of the RSA, an alum of the Georgetown Leadership Seminar and a Non-Executive Director of Bright Blue.

Learn more about Juro: 

Website: www.juro.com 

 LinkedIn: Juro

 Twitter: @GetJuro

Richard contributed to our recent Transaction Management eBook. You can read his insights on how document formats will change in the future by downloading the book here. 

Geoff: On today's show, we welcome Richard Mabey, a former transactional lawyer, and now co-founder and CEO of Juro. Welcome Richard.

Richard: Thank you for having me.

Geoff: Richard started life as an M&A lawyer at Freshfields. He left to attend the prestigious business school INSEAD and completed his MBA then worked arguably for one of the leading tech companies at the time or legal tech companies, Legal Zoo, and co-founded Juro the all-in-one contract automation platform, which I'm pleased to say Shieldpay is a delighted customer.

I'm very pleased to have you on the show today. And I really look forward to talking to you more officially about the business of Juro and more about your ideas and your thoughts around transaction management, that life cycle, contract management, and really your perspectives on where you think we will be in time.

But to begin with, please could you give us the elevator pitch of Juro and where it all came from?

Richard: Awesome. Yeah, well, I'm very happy to be here.

I was a transactional lawyer, so my founder story is a relatively standard one in that I've spent my entire life working on contracts in one way or another. I realised that there was a problem and I set out to build a solution. For me, the primary problem felt like spending four hours a day in Microsoft Word navigating red lines. This didn't feel like the best use of my time. It felt inefficient. It felt like I was bogged down in a low value process work as opposed to the high value complex problem solving that I wanted to be doing.

At Juro, we have this opinion that the root cause of this issue is actually the file type itself. So, using static desktop technology invented in 1983, as MS Word is, you're using a technology which is desktop based, unstructured, and fundamentally it was never designed for legal contracts.

So, when we set out to build Juro, we found that in-house legal teams were processing generally high volumes of contracts, sometimes high complexity, sometimes low complexity, but universally in the language of Microsoft Word. And we found a universe of companies like Shieldpay, who were looking for a more collaborative documentation format.

We're now five years into the journey and we've gone away from being purely an in browser native editor for contracts to being an all-in-one contract automation platform. So that means we cover the process of generating, approving, electronically signing, tracking contracts, querying your data, and ultimately renewing them. And increasingly we're used as a system of record for legal data by in-house legal teams.

Geoff: Oh, it's a, what a journey through all of those stages and fascinating development of the product. One of the things that I find that you do so well is your continuous improvements of the product. You’ve developed the product so much over these years, where does that come from? From your in-house teams internally, or where did you get inspiration for those changes?

Richard: Yeah, it's a really good question. I think honestly, Pavel and I (Pavel is my co-founder), we are fairly obsessive people, so we're very into product design. We're very, very interested in building incredibly and deceptively simple products, which is of course much harder than building complex products. And it takes, I think just a certain mindset of obsession to keep iterating.

Where does it come from? Well, I mean, we spend an awful lot of time talking to customers and we get the whole team to do that. So, engineers talk to customers, of course our customer success team talks to customers, salespeople, designers. We spend a lot of time trying to be absolutely clear on what problems our prospects and customers are trying to solve. So, what exactly is it with this Microsoft Word document that's troubling you? Is it that you have to save versions on your desktop? Is it you have to run red lines manually? Is it that you get annoyed by the functionality of tracked changes? These are all radically different problems and have radically different solutions.

Once you're clear on the problem, and you validated that, I think that's where everything becomes a little bit easier. For us, we still consider ourselves early in the roadmap, even though we're a feature rich product, and iterating, I think, is just part of the Juro DNA now.

Geoff: And so how far from that initial, conceptual MVP that you had in your head are you at? And there must be so much more to come, but that first MVP, you know strip back all of that information to that first initial use case, is it where you expected it to have gone in this timeframe, or less or more?

Richard: I guess every business pivots a little bit, sometimes the pivots are gentle, sometimes the pivots are very severe. We got fairly lucky in that our early customers are generally speaking people at tech businesses, like Shieldpay. So really early customers like, you know, Deliveroo and Babylon Health, we were led by them, right? We went to see these general councils and they said, we have a business critical bottleneck in contract workflow that is causing essentially real problems internally and we want to solve it. And we had the pilot customers when we had built basically nothing. We followed that and we developed real expertise in an absurdly narrow customer segment, which was two-sided marketplaces with one B2B side processing more than 20 contracts per month. This is a ridiculously narrow segmentation. We just became great at it. And we didn't know anything about building in contract products for anyone else. So that, that I think helped us to keep super, super focused.

I think probably the changes to our product, not being in terms of the customer segment or the value we deliver, but actually in the breadth of the products. So, we've built now quite a lot of stuff - things like native e-signature is actually kind of product in itself. Things like being able to query and interrogate contracts from a contract management standpoint is a product in itself. The value proposition of being all in one, um, which is sort of undeniable value - you don't have to buy five tools, you can have one and there's various data advantages to that, also requires a hell of a lot of bills. And so, yes, we absolutely made mistakes that we had to iterate, we had to scrap. But it was never a severe pivot away from the kind of the core mission of what we were doing.